[
Lists Home |
Date Index |
Thread Index
]
I believe the notion behind the semantic web is many fairly small,
intersecting ontologies. As described in TBL underground map:
http://www.w3.org/2003/Talks/0922-rsoc-tbl/slide23-0.html. Each colored line
in this diagram corresponds to an ontology. No single line visits all the
stations; but several stations are visited by more than one line.
Information is shared within one ontology to interoperate between, say, the
address book and events. Another ontology interoperates between events and
photos. The result is interoperation of addresses and photos. This is done
without requiring all stakeholders to agree upon a single interlingua that
covers all information silos at once.
I can't really see how one ontology could be practical even in much smaller
environment than Sem Web - such as a single company or a single department
within a company. Often, even a single application will require multiple
modular ontologies.
In theory, the modularity of ontology models should provide the flexibility
needed to accommodate different contexts. One could also only reference/use
part of an ontology - parts one can "agree with" - without committing to the
entire ontology. In practice, we are still figuring out how this will all
work.
Regards,
Irene Polikoff
Executive Partner, TopQuadrant
www.topquadrant.com
-----Original Message-----
From: Bullard, Claude L (Len) [mailto:len.bullard@intergraph.com]
Sent: Tuesday, November 09, 2004 2:16 PM
To: 'Jeff Rafter'
Cc: xml-dev@lists.xml.org
Subject: RE: [xml-dev] Issues with XML and Semantic Web ?
The problem is it isn't contract, but contracts.
RFP by RFP. It is great if they can all reference one ontology, but for
that to work, that ontology has to be the sum of their requirements;
whaddaygit?
Another bloated specification. Just whining, here.
It isn't that the ontology drifts: it is that meaning drifts. Will I accept
a noise ratio
of 5 to 1? Sure. Sobriety rules. One can't
count on a large non-local community being sober all the time in all of the
places where they
make their decisions. So not just sober choice,
but well-considered application. That is as good as it gets and why many
said that frictionless computing was/is nonsense, so YMMV.
Don't get me wrong. We're very happy to get standards for the codelists we
use. Stuff them into an enumeration and let us suck them via an XMLReader
right into the database, then to the dropdown. Very happy indeed. But the
real trick is to in near real time detect that a user in a particular
context chose the wrong value from that list. This is when the semantic
stuff starts to have more value.
len
From: Jeff Rafter [mailto:lists@jeffrafter.com]
> Do the best you can but no one
> can make time or meaning stand still. YMMV.
Sure they can, in the form of contracts. Essentially that is what OWL is for
right-- a contract about the nature/meaning of a particular piece of
information? Sure, those considerations will change over time but that is
what versioning is for?
Semantic drift is to be expected, and I'll grant that it is a problem but
that doesn't mean it makes the whole process useless. I know that the
fidelity of an MP3 recorded from a CD and an old cassette are two wildly
different things. I know that converting the MP3 to another format and back
will likely involve some loss-- but it doesn't mean that the information is
useless, I just have to approach soberly.
Code lists are great, shared code lists are more great-- but for each level
you go out you have to keep in mind that there will be some lossiness. Fine.
Still, sign me up-- if I have a program that can auto map 1800 out of 2000
fields reliably, I'll use it.
-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an initiative
of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://www.oasis-open.org/mlmanage/index.php>
|
