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> |
---|---|---|
|
Next by Date: | Re: [ontolog] Welcome to new members, MDaconta |
---|---|
Next by Thread: | Re: [ontolog] Welcome to new members, MDaconta |
Indexes: | [Date] [Thread] [Top] [All Lists] |