Lists Home |
Date Index |
Michael Champion wrote:
> Reasonable people can disagree over how many cases there are where a
> well-defined ontology exists; after all, the SNOMED folks just
> formalized the ontology implicit in medical theory and exploited
> nomenclature widely used in practice. That took a couple hundred
> (thousand?) years to get to its current state, and human physiology
> and (to a lesser extent) pathology hasn't evolved all that much during
> that time, so knowledge wasn't rendered obsolete every generation or
Perhaps this can serve as a model though. The reason SNOMED is
successful (and SNOMED is not the only medical ontology for that
matter) is that it does not *impose* anything on doctors, rather is a
written definition of the terms that doctors use. My beef with SNOMED
is that they try to license it -- sort of like if Webster's dictionary
were to attempt to license the English language -- but that is an
entirely different topic -- just don't anyone assume that if I use
SNOMED as an example that I am happy with the state of affairs.
In any case if UBL becomes successful it will be because it doesn't try
to invent anything new, rather codify current business language. I
don't have enough expertise to know if this is the case. From a brief
look it appears that the UBL model is more akin to the HL7 model and
while HL7 has achieved popularity in certain healthcare IT systems it
is not useful to doctors in the same way that SNOMED is. More below.
> My second epiphany about this stuff came more recently -- it became
> brutally clear that internet, XML and web services technologies had
> done a lot to remove the mechanical barriers to data interchange, so
> exchanging well-understood document, data records, and service
> invocations across platforms is no longer the painfully labor
> intensive proposition it was even a decade ago. Now that the plumbing
> is in place, however, it is clear that the barriers to effective
> communication lie more in what the data *means* than in what format it
> is in or what protocol will be used to exchange it.
Right on. Of course human understandable semantics is hard enough
(that's why we have so many lawyers and courts to interpret contracts)
but machine understandable semantics is even harder. If only all the
semantic naysayers would be so critical of the English language every
time there were a trial!
> One might hope that industry-wide working groups will sort out the
> differences for each vertical.Wwheeooooffff [sound of dope smoke being
> inhaled ;-) ] One might hope that people will value interoperability
> more than inertia and adopt something like UBL [Kumbaya .... Kumbaya].
> One might anticipate that some Omnipotent Entity such as the US
> government, WalMart, or Microsoft will just enforce uniformity [could
> happen, but the proles tend to resist such attempts by Big Brother].
There certainly is value in having common document formats for common
things like purchase orders and such. My concern is that stuff like
ebXML is *way* to complicated as have most of the web services
protocols. The original SOAP actually started out as something simple.
On the other hand, WS has already achieved a huge adoption and if some
complexity is the price of uniformity, then oh well, memory and CPU and
network prices are falling.... what is sort of scary is that the way
things are going I am still not sure if this is only an April fools
joke http://www.x-cp.org/index.html :-/
> One might much more plausibly believe, IMHO, that a) individual
> organizations can formalize what *they* mean by various terms,
> namespaces, etc. by reference to concrete documentation that describes
> them or software components/database fields that implement them; and
> b) that these private ontologies could be shared and mapped-between by
> those needing to exchange data across organizational boundaries.
> Maybe someday those will evolve into shared ontologies such as SNOMED,
> we shall see, but we don't need to believe in such things to use OWL,
> etc. to formalize and manipulate the private taxonomies/ontologies
> that are in actual use.
Right. And realize that what is unique about OWL is that it was
*designed* to allow little patches of shared semantics to be stiched
together into a semantic feltwork. This is the quilt approach to
semantics rather than the Big Brother approach to semantics.
This is my take on the situation: OWL does not actually depend on
RDF/XML as a presentation syntax (that is an ontology can be developed
in other formats). For example Guus Schreiber had originally suggested
the mapping from UML (which UBL is developed in) to OWL, e.g.:
and more on UML and OWL:
see "Semantic Web support" at
That is to say that UML can be seen as a development technique for OWL
ontologies (certain ontologies (e.g. OWL Lite) can be serialized as UML
rather than RDF/XML).
so we see that UML and OWL can play quite nicely together. UML can be
seen as a subset of OWL (which is one of the purposes of having the OWL
The "problem" is that OWL/RDF does not *yet* work well with 'arbitrary'
XML (that is XML which does not fit into the RDF/XML syntax) and so
it's not clear what part of the XML document should be interpreted as
objects vs. properties. So *if* we were to develop a consistent
mechanism to map XML to RDF (i.e. interpret XML as a graph).
More just below ...
> The objection from the "XML is all you need" contingent seems quite
> well taken to me: At the end of the road, it comes down to bits on
> the wire that are being matched and manipulated. It may be that one
> can effectively cut out the ontological abstractions and deal directly
> with the syntax patterns and transformations (as XQuery and XSLT
> support quite well) in your domain of choice. My guess is that there
> is enough useful higher-level structure in natural language and the
> real world to give the exercise of building taxonomies/ontologies some
> real value in a lot of application domains now that there is a bit of
> a network effect around the "semantic web" [lower case!] tools that
> will make these things useable by ordinary programmers and human end
Well, it turns out that *if* the XML schema has been developed as UML
and since we can map UML to OWL, then it should be straightforward to
generate an XSLT that allows the XML instance document to be parsed as
RDF triples. Voila!
I had started work on these topics for the WebOnt WG
http://www.openhealth.org/WOWG/IssueStructuredDatatypes.html but WebOnt
basically ran out of time to deal with this issue and there are
problems integrating OWL and XSD that depend on the ability to generate
a URI for XSD schema particles (not yet solved by the XSD WG). Hence
the issue got postponed by WebOnt (not dealt with).
I think that the approach via UML should not have these problems i.e.
it should be possible to automatically generate an XSLT that can
convert UBL into RDF and consequently allow UBL and OWL to
[Note to self.... find some time in 2006 to implement this :-)) ]
> The OWL Guide begins: "The World Wide Web as it is currently
> constituted resembles a poorly mapped geography. Our insight into the
> documents and capabilities available are based on keyword searches,
> abetted by clever use of document connectivity and usage patterns. The
> sheer mass of this data is unmanageable without powerful tool support.
> In order to map this terrain more precisely, computational agents
> require machine-readable descriptions of the content and capabilities
> of Web accessible resources" I guess I've stopped worrying about the
> grandiosity of this vision (and the fact that we're muddling through
> with all sorts of little things like Google and WSDL fairly nicely),
> and learned to respect the value of machine readable descriptions of
> local resources, and the potential this has for reducing the
> complexity exposed to developers and users. We shall see ...
Concrete steps along the way are the only sensible way to get things
done. The problem is trying to get everyone walking in the same
*general* direction (e.g. +/- 90 degrees :-)