[tdwg-tag] RE: tdwg-tag Digest, Vol 22, Issue 5
Éamonn Ó Tuama
eotuama at gbif.org
Fri Oct 12 07:59:23 CEST 2007
I did wonder about region too but then assumed that both it and
associatedTaxon - 'where' and 'what' - were key properties of an
InfoItem that could be concisely defined. The main 'what', of course,
being the 'aboutTaxon'. All that was missing was a 'when' property.
But Roger's model below is even more simple - I like this. He is right
that we should keep our prime use case in mind -
"The use case we started with was blocks of text that describe a
particular aspect of a taxon in a particular context. "
- the simpler the model, the more likely the uptake, and if we can make
use of the popular Dublin Core then lots of clients should be able to
understand our tagging system.
Éamonn
Roger Hyam wrote:
> 2+ thoughts.
>
> Why is region/geography a special case and not covered like any other
> kind of context with a subjectTag? It could point to a polygon or TDWG
> geographic region or whatever.
>
> The same could be argued for associatedTaxon. (I prefer
> associatedTaxon to organismInteraction - the two taxa concerned may
> not interact we may just be saying they occur in the same habitat or
> that Taxon A has some shared characteristic with taxon B - though of
> course every atom in the universe does interact with every other in
> some way I suppose.)
>
> What is the difference between tagging something with a geographic
> region and tagging it with a taxon?
>
> If this is boiled down far enough we don't need the InfoItem as a
> container and can use common vocabularies (DublinCore) for most of
> this stuff.
>
> <tdwg:SpeciesProfile rdf:about="http://my.guid.could.be.lsid.org">
> <tdwg:aboutTaxon rdf:about="urn:lsid:of:some:taxon" />
> <tdwg:associatedTaxon rdf:about="urn:lsid:of:some:other:taxon" />
> <dc:description>
> This is some text about how good this is to eat and other stuff.
> </dc:descriptiono>
> <dc:subject
> rdf:about="http://my.controlled.list.of.terms#cooking" />
> <dc:subject rdf:about="http://my.controlled.list.of.terms#Brazil" />
> </tdwg:SpeciesProfile >
>
> If we want to express Taxon-Taxon interactions Kevin Richards and I
> already came up with something to use for the HerbIMI LSID Authority
>
> http://rs.tdwg.org/ontology/voc/TaxonOccurrenceInteraction
>
> Note that this defines interactions between *occurrences* not taxa and
> the occurrences provide the context. I am not sure that this is the
> place to get into defining interactions other than in the most general
> way.
>
> I feel we a washing around without the metric of a use case to test
> these ideas against.
>
> The use case we started with was blocks of text that describe a
> particular aspect of a taxon in a particular context. That can be done
> really simply perhaps with just DublinCore and only a couple of our
> own predicates but we seem to be getting off the path and to be
> starting to over complicating things.
>
> If you look at the DublinCore definition of "subject" it says: "The
> topic of the resource. Typically, the topic will be represented using
> keywords, key phrases, or classification codes. Recommended best
> practice is to use a controlled vocabulary. To describe the spatial or
> temporal topic of the resource, use the Coverage element." The
> coverage element says "Spatial characteristics of the intellectual
> content of the resource."
>
> Could SPM just boil down to a "controlled vocabulary" for DublinCore
> metadata tags on chunks of text plus a predicate to indicate the taxon
> we are talking about? We could just do an applicability statement on
> how to tag them in HTML!
>
> Roger
>
>
>
> On 11 Oct 2007, at 16:28, Eamonn O Tuama wrote:
>
>> Gregor's wrote:
>> "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."
>>
>> I don't really mind what we call our terms but if they are coming from a
>> non-hierarchical, controlled vocabulary (a class?)
>> (http://rs.tdwg.org/ontology/voc/SPMInfoItems.rdf) don't we leave
>> open the
>> possibility that these may eventually be arranged into an OWL ontology?
>>
>> Gregor's wrote:
>> "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."
>>
>> So, both Gregor and Marcus are suggesting reducing the number of
>> properties
>> for an InfoItem to the following four (related properties in
>> parentheses):
>>
>> - organismInteraction (associatedTaxon)
>> - subjectTag (category, context, contextValue)
>> - region (contextOccurrence)
>> - info (hasContent, hasValue)
>>
>> I like the simplicity and do not think we are losing too much.
>>
>> Éamonn
>>
>>
>>
>>
>> -----Original Message-----
>> From: tdwg-tag-bounces at lists.tdwg.org
>> [mailto:tdwg-tag-bounces at lists.tdwg.org] On Behalf Of
>> tdwg-tag-request at lists.tdwg.org
>> Sent: 10 October 2007 12:00
>> To: tdwg-tag at lists.tdwg.org
>> Subject: tdwg-tag Digest, Vol 22, Issue 5
>>
>> Send tdwg-tag mailing list submissions to
>> tdwg-tag at lists.tdwg.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://lists.tdwg.org/mailman/listinfo/tdwg-tag
>> or, via email, send a message with subject or body 'help' to
>> tdwg-tag-request at lists.tdwg.org
>>
>> You can reach the person managing the list at
>> tdwg-tag-owner at lists.tdwg.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of tdwg-tag digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: RE: tdwg-tag Digest, Vol 22, Issue 2 (Gregor Hagedorn)
>> 2. Re: RE: tdwg-tag Digest, Vol 22, Issue 1 (Gregor Hagedorn)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Wed, 10 Oct 2007 09:48:47 +0200
>> From: "Gregor Hagedorn" <g.m.hagedorn at gmail.com>
>> Subject: Re: [tdwg-tag] RE: tdwg-tag Digest, Vol 22, Issue 2
>> To: tdwg-tag at lists.tdwg.org
>> Message-ID:
>> <5ebbead70710100048v4de595sf594cd36a3f4830d at mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>>> http://www.w3.org/TR/swbp-vocab-pub/
>>> Gregor will especially like it. :-)
>>
>> :-)
>>
>> Indeed, the document convinced me that http+purls+content negotiation
>> (which is the chosen protocol for the semantic web!) would have been a
>> better choice than LSIDs. The document is referenced on several Wiki
>> pages, e.g.
>> http://wiki.tdwg.org/twiki/bin/view/GUID/CommunityPracticesForHttp-basedGUID
>>
>> s;
>> it helped me understand why the semantic web can be based on http at
>> all and that the perceived problems, that initially lead us to opt for
>> LSIDs, probably do not exist.
>>
>> Gregor
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Wed, 10 Oct 2007 10:00:20 +0200
>> From: "Gregor Hagedorn" <g.m.hagedorn at gmail.com>
>> Subject: Re: [tdwg-tag] RE: tdwg-tag Digest, Vol 22, Issue 1
>> To: tdwg-tag at lists.tdwg.org
>> Message-ID:
>> <5ebbead70710100100j13d6a70ctd177ea11527fe30d at mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> On 10/10/07, Eamonn O Tuama <eotuama at 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 at lists.tdwg.org
>> http://lists.tdwg.org/mailman/listinfo/tdwg-tag
>>
>>
>> End of tdwg-tag Digest, Vol 22, Issue 5
>> ***************************************
>>
>>
>> _______________________________________________
>> tdwg-tag mailing list
>> tdwg-tag at lists.tdwg.org
>> http://lists.tdwg.org/mailman/listinfo/tdwg-tag
>
>
More information about the tdwg-tag
mailing list