Dear Matthew, (01)
Your example shows that we need to clarify the meaning of
'interoperability'. The interpretation I have in mind is the one
that Tim Berners-Lee emphasized in his DAML proposal of Feb 2000: (02)
The three terms that he used repeatedly throughout that proposal are
diversity, heterogeneity, and interoperability. Following are some
> The Semantic Web is primarily a tool for interoperability.
> complex applications can interoperate by exchanging information with
> a basis in high level logic and well-defined meaning...
> the crucial step is to gain added value from interoperability
> at the semantic level...
> interchange between components can be embedded in a sufficiently general
> language to ensure that virtually any components have the potential
> to interoperate over the Semantic Web...
> The heuristic models of haystack will be able to interoperate with
> the organizational management systems...
> Ultimately, the test of the Semantic Web--and the applications that
> we build for it--will be the extent to which applications built
> by others interoperate with ours. (05)
As an example, I cited the Amazon.com database schema, which is highly
underspecified. But it enables vendors around the world to interoperate
with the Amazon software in describing, selling, and shipping a wide
variety of products. (06)
But the semantic information about the products is limited. Details
that buyers want to know are contained in character strings that the
computer ignores. (07)
> I don't know what you mean by "underspecified". If you mean it should
> not be over constrained, I would agree, but that is true of any ontology at
> any level. In my experience it is the most common cause of problems. So when
> you put a constraint into your ontology you had better be sure that it is
> not just true in this context, but always and everywhere. (08)
Yes, but the qualifier "always and everywhere" needs more qualification
according to the *purpose* of the interactions. Amazon interoperates
with independently developed, heterogeneous systems, but only for very
specific purposes. They only require a limited amount of semantics. (09)
> When you have a team approach you need to have a development paradigm
> that consists of commitments, rules, and choices that as far as possible,
> and this is what the upper ontology needs to provide. It defines the
> paradigm so that the mid and lower level ontologies are developed
> consistently. The key requirements are that:
> 1. It allows you to say anything that is valid.
> 2. It provides just one way to do it. (this means it might be over specified
> in some areas to eliminate options).
> 3. It is sufficient, clear and accessible not to require guru intervention.
> 4. It is accessible at different levels of expertise. (010)
These are constraints on the *components* of a single system developed
by a *team* that works on a single, very large project. You need that
level of detail for designing an airplane or a large software system.
But you can't expect much detail about heterogeneous systems scattered
across the WWW. (011)
I cited the very underspecified Schema.org and GoodRelations Ontology
as examples of the minimal detail needed for typical web applications.
That level is a good beginning, which can be extended as needed for
applications that require more detail for specific purposes. (012)
This gets back to the point you made in an earlier note that evaluation
must be determined by "fitness for purpose". For diverse independently
developed systems with highly restricted purposes (e.g., selling
through Amazon.com), the semantic detail may be very limited. (013)
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2013/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2013
Community Portal: http://ontolog.cim3.net/wiki/ (015)