Dear John, (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:
>
> http://www.w3.org/2000/01/sw/DevelopmentProposal
>
> The three terms that he used repeatedly throughout that proposal are
> diversity, heterogeneity, and interoperability. Following are some
> quotations:
>
> TBL
> > 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. (02)
MW: That is broadly what I understand by interoperability too. However, I
see interoperability at two levels, which I will describe as weak
interoperability and strong interoperability. (03)
MW: Weak interoperability is when each system that is interoperating is
completely independent, and interfaces are negotiated between systems that
need to operate on a one-to-one basis, and may involve extensive mapping
between different coding systems. The problem with weak interoperability is
its fragility. If any system changes, its interfaces to other systems may be
impacted. In a medium to large network of systems (say 20+) this can be very
costly. However, this is what TBL seems to be advocating. (04)
MW: Strong interoperability replaces this point-to-point approach with a
hub-and-spoke approach. So, you still have independent applications, but now
there is a central hub (which may be virtual) with an overarching ontology
and a single coding system. Interfaces are now just to and from this central
hub, and preferably, all the systems use the same coding system. This
dramatically reduces the cost of maintaining interfaces, and results in a
much more stable and reliable environment. This is the approach taken by ISO
15926.
>
> 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. (05)
MW: I would not describe this as underspecified, just focussed. I think you
will find it is quite precisely specified in things like delivery addresses,
credit card details, product pricing, delivery charges, product names, etc.
>
> But the semantic information about the products is limited. Details that
> buyers want to know are contained in character strings that the computer
> ignores. (06)
MW: Of course it does not need to put the specs in logic, they are not going
to be read by a computer, but by a human (though some comparisons and
searches might be easier with a bit more detail).
>
> MW
> > 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.
>
> 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. (07)
MW: Indeed, but if those limited semantics are not true always and
everywhere there will be occasions when their systems cannot be used (or
fudge/false data will have to be used to make them work).
>
> MW
> > 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.
>
> These are constraints on the *components* of a single system developed by
a
> *team* that works on a single, very large project. (08)
MW: If you want to achieve strong interoperability across an industry, that
is exactly what you need. (09)
> 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. (010)
MW: Then you can't expect much useful interoperability. (011)
MW: It seems that one of the differences between us may be about where we
think the utility of ontology is in the business world. For me it is not in
developing applications that use reasoners, but in developing strong
interoperability between systems at an enterprise or industry level. My
estimate is that this gives/will give rise to over 95% of the potential
benefit of using ontologies.
>
> 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)
MW: If we are talking about people reading stuff, and things being tagged,
then I agree this is fine. You have people mediating. However, it's not good
enough for things like exchanging design data for aircraft, or financial
data about financial instruments that are going to be computer processed
perhaps without human intervention.
>
> 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)
MW: Yes. But detail (scope here) is different from how specified that scope
is. Most applications are highly specified in the area of their focus, and
underspecified in areas at their periphery (and that is how it should be).
It's how they are in their core that counts, and over a number of systems,
it is the sum of all those constraints that counts. Problems can arise when
there are conflicts in the constraints that may be in different systems if
it is in an area of overlap. If any constraints that are stated are true
always and everywhere, that will not happen. (014)
Regards (015)
Matthew West
Information Junction
Tel: +44 1489 880185
Mobile: +44 750 3385279
Skype: dr.matthew.west
matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx
http://www.informationjunction.co.uk/
http://www.matthew-west.org.uk/ (016)
This email originates from Information Junction Ltd. Registered in England
and Wales No. 6632177.
Registered office: 2 Brookside, Meadow Way, Letchworth Garden City,
Hertfordshire, SG6 3JE. (017)
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
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/ (018)
|