Steve, Pete,

Id like to draw your attention on a basic DarwinCore design pattern. Dwc has the goal of being technology independent by simply providing a list of abstract terms one can use in various arenas such as xml, rdf, xhtml, csv etc. And even within those there might be various ways of using them (e.g. we have a normalised and a simple flat xml schema), thats why we should have a guideline for each of them on how to use them. We are missing such a guideline for rdf currently, hence this debate.

Whether scientificName is a literal string or some complex object shouldnt matter - its defined to be a scientific name. Such a dwc rdf property could either hold a literal string or a url to some name rdf:resource (potentially with a rdfs:label).

With the introduction if many ID terms we have diluted that idea a little already in my mind. We could have as well used scientificName in xml to hold some identifier for that name. All URNs tell you what they are by their urn prefix (not necessarily how to resolve them), so you can easily detect a UUID, LSID, http(s) url, ftp, doi and apply the conventional resolution mechanism. The hardest problem are the local ids and other plain identifers. For those mainly we created the ID terms (at least in my mind). I am feeling rather uncomfortable discussing the introduction of specific dwc terms for each type of id. Maybe we should remove all id terms in dwc and use the specific guidelines to specify these? At least if you really think having all those id terms for rdf is a good thing I would feel much more comfortable going down this route instead of diluting dwc by adding more and more rather redundant terms. The abstract concept is key to a dwc term, not the actual data type fo

rced by the technology you are using it with. Would you want several date terms for various date formats? In fact we do that already to some degree (eventDate, eventTime, year, month, day, verbatimEventDate) and I always felt this is not a good idea. There are also a number of verbatimXXX terms in dwc which also contradict this pattern. 

Talking about new dwc terms - in the examples given properties like "hasScientificName" is not strictly the correct dwc term, which is simply scientificName. I think it would be fine to have the convention in the rdf guidlines to use hasDwcTerm instead of dwcTerm, this is exactly what an rdf guideline is for. On the flip side I am sure this only applies to some terms, recordBy for example is likely to remain as it is. Its unclear to me what is best to do really. Always stick to the original dwc terms? Refine them through some rdfs or owl schema and define the relation to the original term? Should we still use the same namespace in this case?

As an rdf beginner even after a few years exposed I wonder if we cant simply stick to the non ID terms and use them either as literals or with a uri pointer. As in the rdf world a resolvable http is really required for resource relations to work, why not simply mandate this in the guidelines? If you only happen to have non resolvable uris like lsid or dois the guidelines should be asking you to use proxied versions, knowing it will break rdf frameworks and lod conventions otherwise. On the resolving side one could always include such urns with owl:sameAs (or sth alike) I believe. But how many non resolvable ids with no matching http counterpart are really out there yet?

- Markus

On Oct 6, 2010, at 9:02, Peter DeVries wrote: