[
Lists Home |
Date Index |
Thread Index
]
From: jborden@attbi.com [mailto:jborden@attbi.com]
>Take at look at http://www.daml.org and a few sample ontologies for starters. There are pointers to a number of examples.
>I'd say that for the examples given, its alot easier to express the intended relationships and classes than in, e.g. XML
>Schema which isn't designed for this in specific.
One can argue that an element type is a class (some do). One can argue that containment relationships (HAS-A)
can be inferred. Still, yes, DTDs and Schemas are not that good for inferring relationships; just types.
>To be more specific, there are already industrial strength ontologies e.g. SNOMED which are created under the 'description
>logic' (DL) formalism that DAML+OIL has captured. There are also industrial strength, as well as open-source/free DL
>classifiers e.g. Classic, FaCT etc. that already work with such ontologies.
Perhaps a more specific distinction between an "ontology" and a "schema" is needed here. Please?
>So you might ask the same question from the other perspective e.g. "Well I already have a good relational database system,
>that already has a data definition language, so why do I need DTDs or an XML Schema?"
To which I have to answer, for 99% of my work, I don't. I work mostly in a closed system where the local relational
schema plus documentation is sufficient. On the other hand, when exchanging with another closed system of the same general class, that falls apart quickly. Other than validation of instances exchanged, as a means to formally define what is exchanged, and when being clever, as a source for generating GUI data, it isn't as useful as I like. On the other hand, a schema can tell me what I can query for, but not a lot about the relationships. For these, I have to augment the documentation with child parent table relationships and common expressions. This of course, is what makes the
data dictionary systems like Crystal Reports popular, but since they lack standards for exchanging their data, one ends up building SQL generators (ad hoc query engines) based on the local definitions (one of the things one can feed a schema to).
> In the case of OWL, suppose I want to express something like: "If you are the father of me, then I am the child of you".
> Piece of cake for OWL, but how would you say that in XML Schema, or a DTD?
I have to go to Schematron or something like it.
>On the semantic web, we'd like our system to figure out these braindead sorts of things, rather than miss the information
>that is staring us in the face, just because it was coded in the wrong column etc.
I'd argue:
1. This isn't braindead stuff. This is precisely the kind of thing we need our brains to determine. Once
determined, we can write our opinions down in something like RDF or Topic Maps.
2. This is the kind of stuff one needs yetAnotherSystem to describe. That is why I contest
TimBL glossing over two-level systems as unnecessary. RDF/TopicMaps is a sort of second level system (SLS)
being applied over data to help interpret it from the point of view of the SLS author.
I think we got into confusion by making the URI be the word instead of a pointer to the word. I think
that is exactly what the neverending threads revolve around. Instead of separating the notion of a
unique item in a range and the coding agreement by which we interpret that item, we nailed them
together in URIness. System IDs and PublicIDs separate these distinct notions of Is-ness.
Point a radar system at incoming aircraft. Acquiring an object gives it identity meaning, you can
track it. Naming an object classifies it meaning you can make decisions about what to do about it.
If you fire on acquisition, you take risks.
len
|
