ontolog-forum
[Top] [All Lists]

Re: [ontolog] RE: [ontolog] Ambiguity and URIs

To: ontolog@xxxxxxxxxxxxxxx
From: MDaconta@xxxxxxx
Date: Fri, 1 Nov 2002 06:46:32 EST
Message-id: <41.2604a2f0.2af3c398@xxxxxxx>
Hi Mike,

In a message dated 10/31/2002 4:58:46 PM US Mountain Standard Time, michael.f.uschold@xxxxxxxxxx writes:
I agree if point is that using a URI to say what you mean by “tank” makes it clear that you are talking about the tank that is defined by that URI, and not another tank which might be defined by say: www.physics/hydraulics-glossary/#Tank.  This removes any ambiguity, say if someone knew about both of these URIs, because you declare which one you are talking about.



Exactly.


My point is merely that no matter how hard you try, it will nearly always be possible for someone to misunderstand the intended meaning of a concept.  If you have URIs for inherently ambiguosus notions such as www.emotions/#Love or www.theuniverse/#God, that does not suddenly give everyone a clear idea of exactly what you mean by these things.


While there is always the potential for misunderstanding. I think the
best example of this is the dublin core elements (www.dublincore.org). 
The URI must always be backed up by a definition in some dictionary.  It is that definition you are agreeing to when you use the URI. 
So, if I use dc:creator -- I am agreeing that "creator" means whatever
the dc definition is of it and no other.

I believe we will see both an explosion and ensuing shakeout of
agreed upon terms/URIs.  In essence, creating a new language
where each term has only one definition.  This is what agents
need for their dictionaries.

A URI is just a name, a string of characters.

that might or might not correspond to a URL
that URL might or might not contain further descriptive information about what a “tank” really is;
that descriptive information may be:
a picture
a powerpoint presentation
in a sloppily put together text description
in a carefuly crafted text definition, relating explicitly to other defined terms say from a glossary
in formal axioms in a logic-based KR/ontology language.  
Any/All of the above 

I hope we can all agree on this.


Yes, at this point ... all you get from a URI is some unique name.
However, I think it is acceptable to assume that the responsibility for
interpreting that name starts with the document (or context) it is
discovered in.  While this cannot be enforced, good practice would dictate
that the document offer at least a link to the governing context in the
form of a link to a schema or namespace document.  I am personally
in favor of a namespace pointing to a namespace document (like
RDDL).  In other words, I believe we need to create the semantic chain
from the source document to one or more layers of semantic knowledge
leading all the way back to SUMO.


 
The reason for yattering on, is to stress the importance of knowing that there will be ambiguities in any attempt to capture the meaning of something—and one must be careful to know which ones are tolerable, and which ones are removed.


I would agree there is always some ambiguity ... the lesson learned from
that is we need to start standardizing specific terms and leave general
notions until we know how to describe them.  I don't think the class
hierarchy is the last word on ontological description.  I also see a distinct
gap between RDF assertions and OWL classes.  A Class, by current
design, involves some implicit relations that RDF assertions would prefer be
modeled via explicit predicates.  The rdf-interest group has had some tension
over this in some of the recent threads.  Specifically, some OWL creators
griping about the "triples-are-king" mentality of RDF'ers.  I personally side
with the "triples-are-king" folks as we desperately need to establish that
beach-head before moving on.

Best wishes,

- Mike
----------------------------------------------------
Michael C. Daconta
Director, Web & Technology Services
www.mcbrad.com
<Prev in Thread] Current Thread [Next in Thread>
  • Re: [ontolog] RE: [ontolog] Ambiguity and URIs, MDaconta <=