RE: [tdwg-tag] RE: tdwg-tag Digest, Vol 22, Issue 1
Can't we keep the model simple and mandate that we are offering a faceted classification, similar to a general tagging system like folksonomies? So a particular InfoItem might have content which pertains to both genetics and ecology and when tagged with those two categories, the only inference that can be drawn is that the content is relevant to both. In a search, that InfoItem would be returned for either of those categories, but is also very likely to be appropriate to someone interested in "ecological genetics" who would search on the categories "ecology + genetics" or vice versa.
I think an aggregator could do either of the following: 1) list an InfoItem under each of its categories - so it will appear multiple times 2) list InfoItems just once under concatenated categories (e.g., ecology+genetics)
In either case, I find it hard to see how anything useful can be derived from such aggregations without human interpretation, e.g., someone preparing a species page for EOL might harvest multiple InfoItems and arrange/edit them as appropriate. Just being able to harvest data through the SPM is surely helpful. In certain cases, where the domain might be restricted (an invasive species group), the community may achieve more automated aggregation by agreeing on how to use certain categories, e.g., I can see benefit in being able to list multiple distributions of a particular species one after the other, especially if biologists are tracking this over time and the information is being continually updated.
Éamonn
-----Original Message----- From: Gregor Hagedorn [mailto:g.m.hagedorn@gmail.com] Sent: 09 October 2007 17:49 To: Eamonn O Tuama Subject: Re: [tdwg-tag] RE: tdwg-tag Digest, Vol 22, Issue 1
I can see that it will be very difficult to come up with a set of hierarchical terms that everyone will agree with. The subclassing
approach,
unless we restrict it to one level (all classes are direct children of InfoItem) is thus problematic. Is it possible to simply assign multiple categories to an InfoItem? Something like the following statement - This InfoItem has category "dispersal" and has category "asexual reproduction".
I wonder whether allowing multiple class or topic-categories is a good idea. It would allow a wealth of expressiveness, but it may be very difficult to interpret. Are "biology + reproduction" or morphology + reproduction" a subclass or intersection statement? By external knowledge I would assume the first is generalization, the second intersection, but this would be difficult to know. "Ecology + genetics" could be either aspects of both mixed, or precisely ecological genetics.
Also: would the order be significant or not? Is "ecology + genetics" different from "genetics + ecology"?
I wonder whether multiple topics per infoitem would not forfeit the purpose of SPM in relation to taxon page creation. It is unclear to me how in practice aggregators would deal with this.
Gregor
On 10/10/07, Eamonn O Tuama eotuama@gbif.org wrote:
Can't we keep the model simple and mandate that we are offering a faceted classification, similar to a general tagging system like folksonomies? So a particular InfoItem might have content which pertains to both genetics and ecology and when tagged with those two categories, the only inference that can be drawn is that the content is relevant to both. In a search, that InfoItem would be returned for either of those categories, but is also very likely to be appropriate to someone interested in "ecological genetics" who would search on the categories "ecology + genetics" or vice versa.
That may be an excellent idea indeed. But then we should call it a "tag" and not "category" or "class", and make clear that adding multiple tags will remain uninterpretable - other than as you indicated.
What worries me is that too much seems to be desired in terms of using the vocabulary, i.e. we have been discussing what the category (and also the context...) could all be used for, and as I tried to show in my talk, sometimes the semantics of what subclasses or modifies what seem to be reversed already in the examples. My goal is to make this clear.
The question remains what SPM is for. As you explain, it is more for finding information than algorithmically aggregating information. I understood the EOL/other taxon page use case to be about automatic aggregation.
In either case, I find it hard to see how anything useful can be derived from such aggregations without human interpretation, e.g., someone preparing a species page for EOL might harvest multiple InfoItems and arrange/edit them as appropriate. Just being able to harvest data through the SPM is
But that would be a one-time copy process. I think it would be important to clarify whether this is the use case or not. If it is, I am completely in favor of Eamonns "tagging approach".
surely helpful. In certain cases, where the domain might be restricted (an invasive species group), the community may achieve more automated aggregation by agreeing on how to use certain categories, e.g., I can see benefit in being able to list multiple distributions of a particular species one after the other, especially if biologists are tracking this over time and the information is being continually updated.
I think it would be beneficial to define specific kinds of infoitems for these use cases (especially distribution and organism interaction), to make it clear how the information is to be interpreted, and how it is extended.
That would mean an InfoItem = tagged free-form text, and a Distribution and OrganismInteraction class, which could be similar, but don't have to be, and may grow into different directions.
Essentially, this would allow to add further classes, which have even stronger differently structure for higher-structured data (categorical or quantitative data).
How about that?
Gregor
I am OK for changing the property name to 'tag' if that makes things simpler but feel it is a little uninformative. How about 'subjectTag' ?
Would this make it clearer that we can have multiple tags to an InfoItem?
This doesn't answer the question of what the URL for the tag resolves to (could be a SKOS concept or an OWL instance or and OWL class or web page!). It could be any or all of these I guess. If we are taking a tagging approach the way the "subject concepts" are managed is up to the manager of these concepts and it might change through time or be the result of some form content negotiation surrounding the resolution mechanism.
Roger
On 10 Oct 2007, at 09:00, Gregor Hagedorn wrote:
On 10/10/07, Eamonn O Tuama eotuama@gbif.org wrote:
Can't we keep the model simple and mandate that we are offering a faceted classification, similar to a general tagging system like folksonomies? So a particular InfoItem might have content which pertains to both genetics and ecology and when tagged with those two categories, the only inference that can be drawn is that the content is relevant to both. In a search, that InfoItem would be returned for either of those categories, but is also very likely to be appropriate to someone interested in "ecological genetics" who would search on the categories "ecology + genetics" or vice versa.
That may be an excellent idea indeed. But then we should call it a "tag" and not "category" or "class", and make clear that adding multiple tags will remain uninterpretable - other than as you indicated.
What worries me is that too much seems to be desired in terms of using the vocabulary, i.e. we have been discussing what the category (and also the context...) could all be used for, and as I tried to show in my talk, sometimes the semantics of what subclasses or modifies what seem to be reversed already in the examples. My goal is to make this clear.
The question remains what SPM is for. As you explain, it is more for finding information than algorithmically aggregating information. I understood the EOL/other taxon page use case to be about automatic aggregation.
In either case, I find it hard to see how anything useful can be derived from such aggregations without human interpretation, e.g., someone preparing a species page for EOL might harvest multiple InfoItems and arrange/edit them as appropriate. Just being able to harvest data through the SPM is
But that would be a one-time copy process. I think it would be important to clarify whether this is the use case or not. If it is, I am completely in favor of Eamonns "tagging approach".
surely helpful. In certain cases, where the domain might be restricted (an invasive species group), the community may achieve more automated aggregation by agreeing on how to use certain categories, e.g., I can see benefit in being able to list multiple distributions of a particular species one after the other, especially if biologists are tracking this over time and the information is being continually updated.
I think it would be beneficial to define specific kinds of infoitems for these use cases (especially distribution and organism interaction), to make it clear how the information is to be interpreted, and how it is extended.
That would mean an InfoItem = tagged free-form text, and a Distribution and OrganismInteraction class, which could be similar, but don't have to be, and may grow into different directions.
Essentially, this would allow to add further classes, which have even stronger differently structure for higher-structured data (categorical or quantitative data).
How about that?
Gregor _______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
I would vote for simply "tag" or "subject" as the SPM syntax is hidden from humans anyway.
Personally I would chose OWL as the document format this tag points to, but it seems we are better off to leave this decision to the provider or developers of the data exchange network. Lets wait and see what proves better. It would be good though if SPM provides already a basic vocabulary to get started with.
I very much like Gregors idea of providing some distinct InfoItem class. I would maybe just add another tagged class which uses controlled terms as values instead of free text:
a) tagged free text b) tagged controlled term incl term/vocabulary source c) tagged organism interaction d) (tagged?) distribution data
These are the most prominent use cases and we would not need to be so super-generic that no client would understand any message.
Markus
-----Original Message----- From: tdwg-tag-bounces@lists.tdwg.org on behalf of Roger Hyam Sent: Wed 10/10/2007 12:08 PM To: Gregor Hagedorn Cc: tdwg-tag@lists.tdwg.org Subject: Re: [tdwg-tag] RE: tdwg-tag Digest, Vol 22, Issue 1
I am OK for changing the property name to 'tag' if that makes things simpler but feel it is a little uninformative. How about 'subjectTag' ?
Would this make it clearer that we can have multiple tags to an InfoItem?
This doesn't answer the question of what the URL for the tag resolves to (could be a SKOS concept or an OWL instance or and OWL class or web page!). It could be any or all of these I guess. If we are taking a tagging approach the way the "subject concepts" are managed is up to the manager of these concepts and it might change through time or be the result of some form content negotiation surrounding the resolution mechanism.
Roger
On 10 Oct 2007, at 09:00, Gregor Hagedorn wrote:
On 10/10/07, Eamonn O Tuama eotuama@gbif.org wrote:
Can't we keep the model simple and mandate that we are offering a faceted classification, similar to a general tagging system like folksonomies? So a particular InfoItem might have content which pertains to both genetics and ecology and when tagged with those two categories, the only inference that can be drawn is that the content is relevant to both. In a search, that InfoItem would be returned for either of those categories, but is also very likely to be appropriate to someone interested in "ecological genetics" who would search on the categories "ecology + genetics" or vice versa.
That may be an excellent idea indeed. But then we should call it a "tag" and not "category" or "class", and make clear that adding multiple tags will remain uninterpretable - other than as you indicated.
What worries me is that too much seems to be desired in terms of using the vocabulary, i.e. we have been discussing what the category (and also the context...) could all be used for, and as I tried to show in my talk, sometimes the semantics of what subclasses or modifies what seem to be reversed already in the examples. My goal is to make this clear.
The question remains what SPM is for. As you explain, it is more for finding information than algorithmically aggregating information. I understood the EOL/other taxon page use case to be about automatic aggregation.
In either case, I find it hard to see how anything useful can be derived from such aggregations without human interpretation, e.g., someone preparing a species page for EOL might harvest multiple InfoItems and arrange/edit them as appropriate. Just being able to harvest data through the SPM is
But that would be a one-time copy process. I think it would be important to clarify whether this is the use case or not. If it is, I am completely in favor of Eamonns "tagging approach".
surely helpful. In certain cases, where the domain might be restricted (an invasive species group), the community may achieve more automated aggregation by agreeing on how to use certain categories, e.g., I can see benefit in being able to list multiple distributions of a particular species one after the other, especially if biologists are tracking this over time and the information is being continually updated.
I think it would be beneficial to define specific kinds of infoitems for these use cases (especially distribution and organism interaction), to make it clear how the information is to be interpreted, and how it is extended.
That would mean an InfoItem = tagged free-form text, and a Distribution and OrganismInteraction class, which could be similar, but don't have to be, and may grow into different directions.
Essentially, this would allow to add further classes, which have even stronger differently structure for higher-structured data (categorical or quantitative data).
How about that?
Gregor _______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
_______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
participants (4)
-
Döring, Markus -
Eamonn O Tuama -
Gregor Hagedorn -
Roger Hyam