[tdwg-tag] RE: tdwg-tag Digest, Vol 22, Issue 5

Eamonn O Tuama eotuama at gbif.org
Thu Oct 11 17:28:38 CEST 2007


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
***************************************





More information about the tdwg-tag mailing list