W3C home > Mailing lists > Public > www-archive@w3.org > December 2001

Re: W3C Web Ontology WG: Content Interoperability Use Case discussion

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Mon, 10 Dec 2001 14:30:17 -0600
Message-Id: <p05101036b83ac752b86f@[]>
To: Leo Obrst <lobrst@mitre.org>
Cc: Pat Hayes <phayes@ai.uwf.edu>, Dan Connolly <connolly@w3.org>, Herman ter Horst <herman.ter.horst@philips.com>, Mike Dean <mdean@bbn.com>, Deborah McGuinness <dlm@ksl.stanford.edu>, www-archive@w3.org
>Welcome! I have condensed what I saw mentioned concerning content
>interoperability so far and list it below. As you can see, these are
>very sketchy working points so far.
>Let's send mail among our group to try to elaborate the use case, define
>our terms, e.g., is "content interoperability" the same as "semantic
>interoperability". I noticed in Jim Hendler's more recent message, that
>he weakened/loosened the use case to be simply "Interoperability",
>something I think we need to address immediately. I personally prefer
>"content interoperability" as our focus, and largely equate this with
>"semantic interoperability". But let me know what you all think.

I would like to see some short (paragraph length) statements of what 
these terms are supposed to mean. I feel like we are just tossing 
two-word phrases around.

>1) USE CASE: Content Interoperability (a/k/a/ agent markup) (compiled
>from WOWG messages)
>- RDF has advantage over XML

Bad way to say this. After all, XML is purely syntactic and RDF is 
expressible in XML syntax; and the point is not to contrast RDF in 
particular with XML, but rather to say that one needs some kind of 
agreed semantics in order to even address interoperability, right?

>in allowing easy merging of content found
>on different sites/resources,

Does RDF in fact do that? Seems to me that RDF just ducks the issue. 
If two different websites use incompatible terminology, RDF has no 
way to fix, or even to detect, the problem. DAML+OIL hasn't either , 
of course.

>and the use of the combined sources.
>DAML+OIL may offer additional advantage. Use cases include linking of
>databases (DB schemas), coupling data to  pages, linking instance data
>to ontologies.  Also allows linking of  ontology to ontology for mapping
>of vocabulary, etc.

That is what these languages conspicuously lack, seems to me. How 
would one state a vocabulary mapping in DAML or RDF ? Eg suppose that 
one ontology treats 'parent' as a property, but another treats it as 
a class. There is no way to state the relationship in DAML+OIL (is 

>In general, the issue of semantic mapping.
>- Adapation of content to user/device. The content exists in some form
>(ontology), and needs to be translated to another form (ontology) for
>use by a different user or device.
>- Finally, the notion of condradiction/inconsistencies: when we
>integrate heterogeneous content, then we need a means for detecting and
>resolving inconsistencies.

Not clear that we should be talking about 'methods' here; and this 
seems to come with the semantics pretty much automatically, right?

Different point, though: there may be other kinds of ontological 
incompatibility than outright inconsistency. Eg if you use two 
different names in DAML+OIL for the same the same entity, that is 
consistent but may suggest the need for a vocabulary mapping.

>2) This is a message I sent out recently to the X318-news@nist.gov
>group, who are interested in terminology standards, among other things,
>suggesting one definition of "semantic interoperability". Specifically
>the requester was working on the draft ISO standard on Requirements for
>Electronic Health Records Architecture and referred to the 11179/3
>standard which defined semantic interoperability as (paraphrased):
>"ensuring that the receiver understands the data as intended by the
>sender" -- which I do not like at all.

I agree, that is completely useless for ontologies, unless we are 
allowed to redefine what 'understands' means.

>One obvious issue is whether the
>semantics will be machine intepretable or just a human agreement (as
>most standards up to now have been).
>My reply:
>We did a study of semantic interoperability in 1999 and defined it (from
>the perspective of interoperating object-based systems) in our paper:
>       Obrst, L., G. Whittaker, A. Meng. Semantic Interoperability via
>Context Interpretation, submitted to Context-99, Trento, Italy, April,
>1999, invited poster session.
>A related and shorter paper is:
>       Obrst, L., G. Whittaker, A. Meng. Semantic Context for Object
>Exchange, AAAI Workshop on Context in AAI Applications, Orlando, FL,
>July 19, 1999.
>>From the 1st paper:
>Semantic interoperability is defined as the enablement of software
>systems ... to interoperate at a level in which the exchange of
>information is at the enterprise [or community] level. This means each
>system (or object of a system) can map from its own conceptual model to
>the conceptual model of other systems, thereby ensuring that the meaning
>of their information is transmitted, accepted, understood, and used
>across the enterprise [or community]. We argue that the primary way by
>which semantic interoperability can be realized is by defining a notion
>of context which includes the object to be exchanged and its internal
>state, its interpretation with respect to both the source and the target
>system object models, and the particular use of and intent for the
>object in both the source and target systems.

Not to knock your work, Leo (BTW, are those papers online?), but I 
would be very unhappy at any kind of ontoweb standard that referred 
to a notion of 'context' without being EXTREMELY precise about what 
it means. That word has almost more baggage than 'model' or 'system', 
and it is used by people to refer to almost anything and everything. 
There are enough  social thinkers waiting to pounce on the ontoweb 
that it would be dangerous to use this term without having it very 
tightly battened down first.


IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Monday, 10 December 2001 15:30:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:42:03 UTC