Comments inline...
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?
- There is a class 'none'. Why? (It doesn't have a definition either. It
seems to be used to indicate that some properties don't have a domain, but if that's true why not simply not provide a domain for those?)
Shouldn't be a class 'none'. I'm removing it.
- 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?), then there really should be another attribute for this commentary. I just didn't want to have to make one if it wasn't necessary.
- There are two classes with label 'Taxon' (but different URIs).
Intentional?
I see only one. What are the URIs?
- 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? Is it intentional to have the? Yes. It is directly a consequence of the versioning mechanism.
- Many classes and all object properties that aren't a subProperty have a
date suffix in their identifier. Why, and if there is a good reason, why not all? Is term versioning the motivation? If so, are there so many updates expected that versions couldn't be handled by ontology releases (i.e., versioning through the ontology namespace, such as in http://purl.org/dc/elements/1.1).
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.
The date suffix will become part of the element name in OWL instance documents:
dwcterms:Taxon-2008-11-29 dwcterms:ScientificName-2009-01-21 Ictalurus punctatus </dwcterms:ScientificName-2009-01-21> </dwcterms:Taxon-2008-11-29>
Or am I missing something?
No, you aren't missing anything. You're right. So, what is lacking in the rdf is a set of current term names without date suffixes, such as dwcterms:Taxon and dwcterms:ScientificName that can persist despite versioning. That was the whole point of the persistent URIs for the terms - so that dwcterms:ScientificName would persist despite the details of its attributes. My automated construction of the rdf document doesn't take this into account. 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?