[tdwg-tag] RE: tdwg-tag Digest, Vol 22, Issue 1
Eamonn O Tuama
eotuama at gbif.org
Tue Oct 9 16:47:42 CEST 2007
Hi Roger,
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 agree that it is restrictive to let a transport protocol dictate our data
model but, in any case, there was a suggestion (from Donald I think) that
we could make the category approach work by doing an inventory call first.
SKOS allows the constructing of full blown ontologies but I take it you are
suggesting that we restrict ourselves to just flat vocabulary lists. I like
your idea of having OWL as an optional add-on to reason over our categories.
É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: 08 October 2007 13:53
To: tdwg-tag at lists.tdwg.org
Subject: tdwg-tag Digest, Vol 22, Issue 1
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. SPM Categories or Subclassing - again. (Roger Hyam)
2. Re: SPM Categories or Subclassing - again. (Donald Hobern)
----------------------------------------------------------------------
Message: 1
Date: Mon, 8 Oct 2007 11:51:11 +0100
From: Roger Hyam <roger at tdwg.org>
Subject: [tdwg-tag] SPM Categories or Subclassing - again.
To: tdwg-tag at lists.tdwg.org
Message-ID: <89F4B714-003E-4512-BCF3-8EA68BF0230E at tdwg.org>
Content-Type: text/plain; charset="us-ascii"
Hi All,
I'd like to re-ignite a debate we had over the summer in the light of
what was discussed at Bratislava and things I am thinking about now.
The original way the Species Profile Model was structure was to have
something like the attached UML diagram tagging.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tagging.png
Type: image/png
Size: 5540 bytes
Desc: not available
Url :
http://lists.tdwg.org/pipermail/tdwg-tag/attachments/20071008/2ea945b8/taggi
ng-0001.png
-------------- next part --------------
We didn't define a class "Category" but just left it as being any
valid URI in the RDF style of doing things.
Markus and several others pointed out that this would not work with
TAPIR very well as all the InfoItems will look the same. Something
like this:
<SpeciesProfileModel>
<hasInformation>
<InfoItem>
<category rdf:resource="some.resource.org/123" />
<....>
</InfoItem>
</hasInformation>
<hasInformation>
<InfoItem>
<category rdf:resource="some.resource.org/124" />
<....>
</InfoItem>
</hasInformation>
<hasInformation>
<InfoItem>
<category rdf:resource="some.resource.org/125" />
<....>
</InfoItem>
</hasInformation>
</SpeciesProfileModel>
The xpaths to the data represented by <...> would all be the same.
They suggested something like the next diagram:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: subclassing.png
Type: image/png
Size: 7381 bytes
Desc: not available
Url :
http://lists.tdwg.org/pipermail/tdwg-tag/attachments/20071008/2ea945b8/subcl
assing-0001.png
-------------- next part --------------
Where info item is subclassed. This allows RDF to be serialized like
this:
<SpeciesProfileModel>
<hasInformation>
<Ecology>
<....>
</Ecology >
</hasInformation>
<hasInformation>
<Behaviour>
<....>
</Behaviour>
</hasInformation>
<hasInformation>
<BehaviouralEcology>
<....>
</BehaviouralEcology>
</hasInformation>
</SpeciesProfileModel>
The xpaths to the <...> are all different and the model becomes TAPIR
friendly.
At the time I wasn't too bothered either way because I saw this as an
artifact of serialization. The same thing could be written.
<SpeciesProfileModel>
<hasInformation>
<InfoItem>
<rdf:type rdf:resource="some.resource.org/Ecology"
/>
<....>
</InfoItem>
</hasInformation>
<hasInformation>
<InfoItem>
<rdf:type rdf:resource="some.resource.org/Behaviour"
/>
<....>
</InfoItem>
</hasInformation>
<hasInformation>
<InfoItem>
<rdf:type
rdf:resource="some.resource.org/BehaviouralEcology" />
<....>
</InfoItem>
</hasInformation>
</SpeciesProfileModel>
With more or less that same meaning and looking just like a tagging
example.
This was a mistake on my part because of course it isn't the same
meaning just a similar serialization - an RDF type really needs to
point to a class and can't point to any old vocabulary that it could
if it was treated like a tag.
I have just added the category property back into InfoItem for
discussion purposes.
I am concerned about going down the subclassing route for a few reasons.
1) Building a class hierarchy is difficult. The discussions we had in
Bratislava highlighted this. The examples put together in the current
vocabulary sparked a debate as to how things should be organized.
There are issues with the diamond problem in multiple inheritance -
if contradictory semantics occur in multiple inheritance routes to a
class which has priority? If we don't have multiple inheritance how
do we have InfoItems that are about both Ecology and Behaviour for
example or any other two subjects such as Dispersal and Asexual
reproduction.
2) If a class hierarchy is required for analysis/inference it can be
superimposed on a tag based transfer protocol using OWL necessary and
sufficient properties. In fact this is arguably a better way of
approaching the situation than building a class hierarchy a priori.
3) The motivation for going down the subclassing route is largely so
it will work with the transport protocol - which sets alarm bells
ringing for me.
4) It precludes us from using something like SKOS to build our
categories.
"SKOS or Simple Knowledge Organisation System is a family of formal
languages designed for representation of thesauri, classification
schemes, taxonomies, subject-heading systems, or any other type of
structured controlled vocabulary. SKOS is built upon RDF and RDFS,
and its main objective is to enable easy publication of controlled
structured vocabularies for the Semantic Web. SKOS is currently
developed within the W3C framework." (http://en.wikipedia.org/wiki/SKOS)
I would really like to be able to say to "domain experts" that they
"just" need to build a SKOS vocabulary for the terms used in their
domain and then use the URIs of these terms for tagging information
that is passed between providers than specify that they need to
construct a more formal ontology of classes. I appreciate that one
could argue that SKOS terms are like classes but they form part of a
structure that is specifically designed for having the debates that
TDWG needs to have around the vocabulary part of the standards
(rather than the exchange parts).
I would be grateful for peoples thoughts and criticisms.
All the best,
Roger
------------------------------
Message: 2
Date: Mon, 08 Oct 2007 13:53:00 +0200
From: Donald Hobern <dhobern at gbif.org>
Subject: Re: [tdwg-tag] SPM Categories or Subclassing - again.
To: Roger Hyam <roger at tdwg.org>
Cc: tdwg-tag at lists.tdwg.org
Message-ID: <470A1A1C.2060501 at gbif.org>
Content-Type: text/plain; charset="us-ascii"
An HTML attachment was scrubbed...
URL:
http://lists.tdwg.org/pipermail/tdwg-tag/attachments/20071008/ca343d0f/attac
hment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 5540 bytes
Desc: not available
Url :
http://lists.tdwg.org/pipermail/tdwg-tag/attachments/20071008/ca343d0f/attac
hment.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 7381 bytes
Desc: not available
Url :
http://lists.tdwg.org/pipermail/tdwg-tag/attachments/20071008/ca343d0f/attac
hment-0001.png
------------------------------
_______________________________________________
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 1
***************************************
More information about the tdwg-tag
mailing list