<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Roger,<br>
<br>
Your analysis (and the four points) seem perfectly correct to me. I
prefer a plain tagging approach and am particularly dubious about the
long term benefits of subclasses which represent multiple inheritance
because this would seem to place a greater burden on consumers.<br>
<br>
However I am not so sure that the tagging approach does prevent the use
of TAPIR. Surely the user is expected to be searching for InfoItems
and each InfoItem will include a relative path
"./category/@rdf:resource" which could be searchable. In other words
you could search for InfoItems where the concept identified by
"./category/@rdf:resource" has the value "some.resource.org/123".
Won't that work? Won't it return any InfoItem which has any
combination of category elements provided at least one is identified to
the given resource? <br>
<br>
Of course searching for InfoItems like this may prevent us from using
search elements outside the scope of the InfoItem - would this stop us
from using a ScientificName specified against the SpeciesProfileModel
element? In other words, would it be better to move the aboutTaxon
down to the InfoItem?<br>
<br>
Donald<br>
<br>
Roger Hyam wrote:
<blockquote cite="mid:89F4B714-003E-4512-BCF3-8EA68BF0230E@tdwg.org"
type="cite">Hi All,
<br>
<br>
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.
<br>
<br>
The original way the Species Profile Model was structure was to have
something like the attached UML diagram tagging.png
<br>
<br>
<br>
<hr size="4" width="90%"><br>
<center><img src="cid:part1.06060207.08080700@gbif.org"></center>
<p><br>
We didn't define a class "Category" but just left it as being any valid
URI in the RDF style of doing things.
<br>
<br>
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:
<br>
<br>
<SpeciesProfileModel>
<br>
<hasInformation>
<br>
<InfoItem>
<br>
<category rdf:resource="some.resource.org/123" />
<br>
<....>
<br>
</InfoItem>
<br>
</hasInformation>
<br>
<hasInformation>
<br>
<InfoItem>
<br>
<category rdf:resource="some.resource.org/124" />
<br>
<....>
<br>
</InfoItem>
<br>
</hasInformation>
<br>
<hasInformation>
<br>
<InfoItem>
<br>
<category rdf:resource="some.resource.org/125" />
<br>
<....>
<br>
</InfoItem>
<br>
</hasInformation>
<br>
</SpeciesProfileModel>
<br>
<br>
The xpaths to the data represented by <...> would all be the
same.
<br>
<br>
They suggested something like the next diagram:
<br>
<br>
</p>
<hr size="4" width="90%"><br>
<center><img src="cid:part2.01030805.00090901@gbif.org"></center>
<p>Where info item is subclassed. This allows RDF to be serialized
like this:
<br>
<br>
<SpeciesProfileModel>
<br>
<hasInformation>
<br>
<Ecology>
<br>
<....>
<br>
</Ecology >
<br>
</hasInformation>
<br>
<hasInformation>
<br>
<Behaviour>
<br>
<....>
<br>
</Behaviour>
<br>
</hasInformation>
<br>
<hasInformation>
<br>
<BehaviouralEcology>
<br>
<....>
<br>
</BehaviouralEcology>
<br>
</hasInformation>
<br>
</SpeciesProfileModel>
<br>
<br>
The xpaths to the <...> are all different and the model becomes
TAPIR friendly.
<br>
<br>
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.
<br>
<br>
<SpeciesProfileModel>
<br>
<hasInformation>
<br>
<InfoItem>
<br>
<rdf:type rdf:resource="some.resource.org/Ecology" />
<br>
<....>
<br>
</InfoItem>
<br>
</hasInformation>
<br>
<hasInformation>
<br>
<InfoItem>
<br>
<rdf:type rdf:resource="some.resource.org/Behaviour"
/>
<br>
<....>
<br>
</InfoItem>
<br>
</hasInformation>
<br>
<hasInformation>
<br>
<InfoItem>
<br>
<rdf:type
rdf:resource="some.resource.org/BehaviouralEcology" />
<br>
<....>
<br>
</InfoItem>
<br>
</hasInformation>
<br>
</SpeciesProfileModel>
<br>
<br>
With more or less that same meaning and looking just like a tagging
example.
<br>
<br>
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.
<br>
<br>
I have just added the category property back into InfoItem for
discussion purposes.
<br>
<br>
I am concerned about going down the subclassing route for a few
reasons.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
4) It precludes us from using something like SKOS to build our
categories.
<br>
<br>
"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."
(<a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/SKOS">http://en.wikipedia.org/wiki/SKOS</a>)
<br>
<br>
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).
<br>
<br>
I would be grateful for peoples thoughts and criticisms.
<br>
<br>
All the best,
<br>
<br>
Roger
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</p>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
tdwg-tag mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tdwg-tag@lists.tdwg.org">tdwg-tag@lists.tdwg.org</a>
<a class="moz-txt-link-freetext" href="http://lists.tdwg.org/mailman/listinfo/tdwg-tag">http://lists.tdwg.org/mailman/listinfo/tdwg-tag</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
------------------------------------------------------------
Donald Hobern (<a class="moz-txt-link-abbreviated" href="mailto:dhobern@gbif.org">dhobern@gbif.org</a>)
Deputy Director for Informatics
Global Biodiversity Information Facility Secretariat
Universitetsparken 15, DK-2100 Copenhagen, Denmark
Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480
------------------------------------------------------------</pre>
</body>
</html>