Hello All,
I posted the below on the semantic web forums, but i'm not sure how much cross reading there is buti'd like to get feedback from the ontolog community as well. I apologize if what i've written is obvious...
Post pasted below: **** Hi Michael,
Part of my thesis necessitated creating an architecture for ontology repositories, and while this subject wasn't its primary focus, i have spent some time thinking about this topic, spurred by your question.
I think the question points to a more fundamental question of how might networked ontologies interoperate. I have many thoughts on this (particularly, the need for a semi-formalized meta-ontology), but in this post i'll stick to the question at hand.
In my mind, there are two issues: One of data provenance, and one of semantic changes.
I'll start with that of semantic changes. Changes to an ontology via the definiton of a term constitute A being transformed to A'.
The question then becomes identifying the type of change that occurs. Particularly, the mapping A-> A' will need to be recognized in a (semi)-formal way for true interoperability. At the very least it will need to be made explicit in some way.
To wit, in a semi-formal way, i can think of several possible relations one can use to represent this change (these issues came up in another form my thesis...).
A -> A' can be a change of:
meta-level change (i.e. you changed [natural language?] comments about a term)
conservative extension non-conservative extension (henceforth referred to as NCX) non-monotonic change
These are all second-order (or at least metalevel) logical concepts, so they clearly wouldn't be represented in the ontology under consideration. There may be a distinction here too, depending on whether A refers to a particular axiom or to a module (as defined in Common Logic), more on this later.
What the above suggests is the need for some sort of meta-ontology akin to the proposed versioning/change management.
An open research question would then be - what are these relations (there must be more than the four i listed)? And more importantly, how do they affect choices in URI and UID?
On this thread some discussion has occured regarding changing the term name as opposed to only the URI. In this case of non-monotic change (it was referred to implicitly), you have suggested that the term name should stay the same, but the URI should differ. I agree.
Similarly, it's also been suggested (implicitly) that a non-conservative extension (NCX), A' of A would necessitate a new term name. (I'm not convinced about this).
However, I think we can develop a rudimentary policy from this simple analysis.
If we were to deflate URI's and UID's, they would function (loosely) analogously as Classes and Instances do.
Let A be the set of all versions of A, this is the URI of A. Let the A_i {belong to} URI of A, be different UIDs, where the A_i are the different paritcular versions of A.
When someone now refers to concept A (or since I'm immersed in the Common Logic framework, module A) , they would point to a pair URI and a policy for determining UID, depending on their resource needs.
The policy for UID determines which A_i the resource selects from A. It is here that the data provenance is required.
Let A_1 be the original / initial definition of A.
Every A_i is linearly ordered according to time.
For each change A_m to A_n where there is no A_p in between, there is a "revision function" which corresponds to the type of change that occurs, as noted above. (see gardenfors - knowledge in flux - for some discussion on possible revision functions)
So if my resource demands the most up-to-date version of A, I would select the A_i ordered highest in time. If my previous date of alignment with A was A_k not immediately before A_i, then i need to construct the chain to A_k, and consider my resource policy for each R that links A_k-A_m until A_i as noted above.
This again brings us back to the open research problem of what are these revision functions "R"?. Subsequently, what should the resultant policies look like?
In terms of changes where R = non-monotonic change, i would suggest something akin to Gardenfor's revision function.
Which points to the second research problem only alluded to above -- what are the guidelines for proper meta-ontology management.
This issue is left another email/post/(paper?) i believe :P
Ali Hashemi
MASc Candidate Semantic Technologies Laboratory University of Toronto
<quote author="Michael F Uschold"> On Wed, Oct 29, 2008 at 3:53 PM, Michael F Uschold <uschold@xxxxxxxxx>wrote:
> Currently there is no accepted practice on how/whether to migrate to new > URIs when a new version of an ontology is published. This is largely due to > the fact that there is no good technology for managing versioning, and the
> W3C consciously (and probably sensibly) decided not to address the issue. > Versioning information is meant to be placed on a version annotation. > > However the current situation is like the wild West, and everyone will be
> doing different things, resulting in a mess. > <b>... (snip)</b> > Another question is what to do if the original standard is belived to be > incorrect, and the new one is the fixed one. Can one then keep the same URI?
> Again, the answer should be informed by the impact on applications. The > same problems will occur if you change the semantics and keep the same URI > even if you are fixing a mistake. The URI with the wrong semantics must
> keep its original unique ID. > > Michael Uschold >
</quote>
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (01)
|