On Apr 22, 2009, at 3:09 PM, Duane Nickull wrote:
The problem is that there are no namespace qualifications for these so I want to introduce that into my work. I was planning on just using the root URL’s for each work however there are versions possible in some of the work.
I would like this to be in the firm of <upper_ontology_identifier>+<version_or_instance>+<uuid> as a classifier followed by the term label such as “transitive”. I will probably use URI’s for the UUID.
Question:
Has anyone ever come across a similar problem and if so, how did they solve it?
We came across two similar problems, I think. We are republishing vocabularies, so it is I believe analogous. Some questions for you that you have, I imagine, thought about, then my own contributions.
1) I am not sure what your '+' means -- I assume it is a literal? And what does 'as a classifier' mean -- everything that comes before the 'term label'? More specifics would be helpful here, unless everyone else understands already.
2) By 'uuid' I assume you mean the UUID for the original term. Is it definite that all the ontologies have a clearly usable UUID for each of their terms? (For example, if the UUID is constructed with a fragment syntax ('#'), your URL will get a bit weird, won't it? And I *think* some references to URLs within URLs (whether URL#1 is your UUID) can require some ugly expansions in some http circumstances, but I haven't had to master that myself yet.
3) I am a little lost as to the value of adding the label, if it is the label of the term identified by the UUID. This makes me worry I may have misunderstood your goal.
My thoughts in response:
In one of our scenarios we had to deal with people who want URNs instead of URLs, while we always wanted to have a URL for all our terms. A quasi-solution we found is to embed the URN, as a sort of literal code, inside the URL, so that part of your model seems at least consistent with what we came up with.
In our whole world of use cases we had to deal with versioning. While in theory we could have supported any style of version, we ended up making an ISO8601 look-alike, that goes into as much detail (days, hours, milliseconds (!)) as required to ensure uniqueness from previous submissions. This provided useful visual context and avoided considering weird versioning labels that might have been URL- or user-unfriendly. So the notion of the version is consistent too.
The one thing about versions is that they are pretty consistent if you can align them with the moment a resource is submitted. But if you are trying to capture the version of an external resource, you'll have to decide what you mean by 'version' of that resource, considering (a) they may not version, (b) you may not have the ability to inspect their version transitions -- either when they happen or what the change was, and (c) you'll have to decide what relation you want between uniqueness and version ID (different term guarantees different version, vice-versa, or both?). Ick.
Details are buried in various documents associated with our semantic framework [1], I can provide specific pointers to our URL construction notions (or you can search on the site) if you want them.