On Feb 23, 2009, at 5:55 PM, John R. WIECZOREK wrote:
On Mon, Feb 23, 2009 at 8:29 AM, Hilmar Lapp hlapp@duke.edu wrote:
Thanks John - this now works and loads into Protege. Great!
A couple of random comments from a first inspection:
- There are lots of individuals that seem to correspond to classes
and object properties (and seem to be replaced by them, which sounds odd). Is this by intention?
I don't know what you mean by this. Can you give me an example?
As far as I can see the replaces relationships to classes have gone away. For object properties, an example is AcceptedTaxon:
<rdf:Description rdf:ID="AcceptedTaxon"> <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property "/> <rdfs:domain rdf:resource="http://rs.tdwg.org/dwc/terms/Taxon%22/%3E <rdfs:replaces rdf:resource="http://rs.tdwg.org/dwc/terms/AcceptedTaxon-2008-11-19 "/> </rdf:Description>
This seems fine.
BTW note that unless I'm missing something the base URLs http://rs.tdwg.org/dwc/terms/ and http://rs.tdwg.org/dwc/rdf/dwcterms.rdf result in different URIs for concepts (hence making them effectively different) for what you may want to be the same (the URLs seem to be used interchangeably - but maybe the idea behind this is different?).
[...]
- seeAlso often has the value 'not in ABCD', which is probably the
wrong kind of value for this annotation.
None of those values is technically very useful, as they are references to xpaths in a schema. As such, "not in ABCD" is no different functionally speaking from any of the other values. If seeAlso is not appropriate for this type of content (where is the reasoning for that?)
According to the RDF Schema spec, rdfs:seeAlso is "[...] used to indicate a resource that might provide additional information about the subject resource." The value of the property is supposed to be a rdfs:Resource (i.e., a URI to/for a resource).
See http://www.w3.org/TR/rdf-schema/#ch_seealso
[...]
- There are two classes with label 'Taxon' (but different URIs).
Intentional?
I see only one. What are the URIs?
Now there are actually three:
http://rs.tdwg.org/dwc/rdf/dwcterms.rdf#Taxon http://rs.tdwg.org/dwc/rdf/dwcterms.rdf#Taxon-2008-11-19 http://rs.tdwg.org/dwc/terms/Taxon
All three have label "Taxon", and are classes, and there is no asserted relationship between them.
- Same properties and some classes have the date suffix in their
label. Intentional?
Every one of them has a date suffix in its label as far as I can see. What are the exceptions?
There are no classes anymore now with a suffix in the label, but many of the properties have it. For example:
SamplingEvent-2008-11-19 LivingSpecimen-2008-11-19 PreservedSpecimen-2008-11-19
For those there seems to be another term without the suffix.
[...] Again, all of them have the date suffix as far I I can see. Yes, term versioning is the motivation. They are all in the one document so that the entirety of the documentation, including history, can be produced from it. It isn't so much that there are a lot of updates expected as that there is a lot of historical nonsense to resolve unequivocally. Here it is all in one place.
Maybe it would be worth producing two versions - one with the history that allows the maintainers to resolve issues, and one for public consumption that has the cruft removed?
[...] The solution, I think, is to add each base term without version information and give these terms rdfs:replaces with the value of the term with the version number. This would give a complete progression for any term up to the one currently in use. I have done that in a copy of the file just committed. Does that solve the problem adequately? Does it create any new ones?
Looks a lot better now - thanks!
BTW note that the server returns the ontology with mime-type text/html rather than application/rdf+xml. Not a big deal, just the browser will try to display it rather than downloading.
-hilmar