Hi Steve,
Thanks for taking the time to work through my example.
(I'm not used to the Turtle serialization but managed to translate it into XML which is the way I "think" about RDF).
[ Everyone has their favorite tools, but in case anyone is looking for RDF tools, I really recommend:
- Emacs, with n3-mode by Hugo Haas for writing Turtle, and nXML for working with RDFXML - Redland's http://librdf.org/ rapper for turtle-to-rdfxml and roqet for SPARQL queries - Rapper also converts turtle to dot files, and dot from the graphviz library can make jpegs of the network ]
Q2-4. If the "token" is separated from the Occurrence, then dwc:recordedBy is a property of the Occurrence and dcterms:created and dcterms:creator are properties of the token (if it's a create-able thing).
Is there any benefit to specifying both OccurrenceX dwc:recordedBy PersonY and TokenX dcterms:creator PersonY? If not, which is the more `natural' home for the information? I think it would be TokenX dcterms:creator PersonY.
- After considerably thought, I've decided that I don't want to use
direct access URLs for images as their identifying URIs.
This is an important point - but does of course make things a bit more difficult from a programming point of view.
... if we can use them in this way, it greatly reduces the number of new terms that would have to be created to express DwC in RDF (i.e. we don't need to make up dwc:hasOccurrence). The downside to this is that few (none?) of the relationships that could be expressed by xxxxxxID terms have inverse properties defined. I made up a few in the sernec: vocabulary, but the need for such terms would have to be discussed at some point in a future RDF task group.
I'd actually be in favor of coining new terms like dwc:hasOccurrence, because a term xxxxxxID seems to imply that the object of the triple is not the URI of the resource itself, but some additional identifier.
I don't know enough about how semantic clients work to know if just providing the properties in one direction would be good enough for the client to infer the inverse relationship and make use of it as necessary.
I think the inverse relationships would be put into the OWL ontology that officially specified all the TDWG RDF terms, along with domain and ranges, etc.
Best,
Cam