|
Paul,
I understand, but aren't you creating a schema that covers a set of
documents? What if you had another set of documents covered under a different
schema? Would you union the schemas or create another schema that somehow
modeled what both individual schemas did? Would you step back and think:
what do these schemas really mean, or what is the real meaning behind those
schemas? What is the meaning of these things independent of any document
or data (yes, often more a vision than a reality)? If you move along this
path, then you are moving towards defining an ontology. Why? Because you
are thinking in terms of what things mean, rather than how they will validate
incoming documents (where the semantics of those field names are in the
minds of humans reading them, rather than explicitly represented in a way
that a machine could interpret). A fine point, perhaps. Why should you
care about how documents are structured? Shouldn't you be interested in
what they mean -- of course, I'm speaking as the ontology devil's advocate
here.
However, one issue that might illuminate the distinction: how would
you query your document collection? Or document collections that might
have the same meaning?
Thanks,
Leo
"Murray, Paul" wrote:
Woops
sorry, that got sent off before I was finished:And
here is a small document that validates against that schema:<?xml
version="1.0" encoding="UTF-8"?><assembly
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="C:\Documents and Settings\murraypx\Desktop\example.xsd"
name="Bicycle">
<part
name="Front Wheel"/>
<part
name="Back Wheel"/></assembly>
-Paul Murray.
Hi,
By way of example,
here is a tiny xml schema for parts and assemblies:<?xml
version="1.0" encoding="UTF-8"?>
<!--W3C Schema generated by XML
Spy v4.4 U (http://www.xmlspy.com)--><xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="qualified">
<xs:attribute name="name" type="xs:string"/>
<xs:attributeGroup
name="core">
<xs:attribute ref="name"/>
</xs:attributeGroup>
<xs:element
name="part">
<xs:complexType
mixed="true">
<xs:attributeGroup
ref="core"/>
</xs:complexType>
</xs:element>
<xs:element
name="assembly">
<xs:complexType
mixed="true">
<xs:choice
minOccurs="0" maxOccurs="unbounded">
<xs:element
ref="part" minOccurs="0" maxOccurs="unbounded"/>
<xs:element
ref="assembly" minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
<xs:attributeGroup
ref="core"/>
</xs:complexType></xs:element></xs:schema>
*Note: changed to ontolog-forum@xxxxxxxxxxxxxxxx in above cc line (was
incorrect).
I am unclear as to how the XML Schema constraint addresses a real world
object.
Also, note that the structures on the semantics side are based on set
theory. So these are structured mathematical objects.
"Murray, Paul" wrote:
"A constraint
in an XML Schema is a constraint on the structure or form of a document,
not on the meaning of a real world object as in an ontology."Not
necessarily true, a constraint in an XML Schema (say the parent/child element/attribute
relationships) can also translate to a constraint on a real world object
as in the "part-of" relationship. But I guess this is a nit. I
think an important statement here is:*However,
we all know that structure is the mother of meaning too, that in fact no
semantics is possible without it, and that the formal objects on the "semantics"
side to which the syntax/structures map (in model-theoretic semantics via
an interpretation function) and which we take to "stand in" for the real/possible
world entities whose semantics we want to capture, are themselves structured
(probably because we want those objects to have certain formal properties,
ordering relationships, etc.)
-Paul Murray.
We've recently been discussing a variant of this question internally (in
MITRE) across two communities, the database and the ontology folks. I.e.,
data modeling vs. ontology engineering. I think our point of departure
was the SIGMOD paper from last year:
Data Modelling versus Ontology Engineering. P. Spyns, R. Meersman, M.
Jarrar, Special Section on Semantic Web and Data Management, V. 32:4, December,
2002. http://www.acm.org/sigmod/record/issues/0212/SPECIAL/2.Meersman.pdf.
Note the above requires a login account.
I think the short answer is that database schemas and XML Schema are
a way of structuring data/document collections for some generally local
purpose, e.g., to satisfy an application (or set of applications) or, in
the case of XML Schema, for some generally local exchange of documents/messages.
So, in general, schemas are focused on structure rather than the meaning
of constructs that define that structure. And ontologies address a more
"global" view, in terms of real world semantics.
*However, we all know that structure is the mother of meaning too, that
in fact no semantics is possible without it, and that the formal objects
on the "semantics" side to which the syntax/structures map (in model-theoretic
semantics via an interpretation function) and which we take to "stand in"
for the real/possible world entities whose semantics we want to capture,
are themselves structured (probably because we want those objects to have
certain formal properties, ordering relationships, etc.)
That said, maybe the shortest answer is: A constraint in an XML Schema
is a constraint on the structure or form of a document, not on the meaning
of a real world object as in an ontology.
Leo
"Uschold, Michael F" wrote:
It is not usual for someone to show me an XML shema
and say, "Hey, what do you think of my ontology?", or: "Gee, we are using
an ontology now, but everyone's using XML, so maybe we should use an XML
Schema instead?". Indeed, some people have the impresson that
XML Schema and ontologies** are similar animals and one can use one or
the other for a given problem.
Where does this impression come from?
For SOME problems, ontologies and XML Schema seem for all practical
purposes, to be alternatives. One can create an ontology and a data set
conforming to that ontology, or one could create an XML schema and pass
data conforming to that schema. There would be a clear mapping between
classes and attributes in the ontology and elements and attributes in the
XML schema.
However, I believe that for MOST problems ontologies and XML schema
are not appropriately seen as alternatives, indeed they are quite different
animals for quite different purposes, and can be used to good effect together
complementing each other.
Can anyone resolve this paradox? One great way to answer the question
is like this:
If properties p1, p2, ... pn hold for a given situation, then
for most practical purposes, XML schema and ontologies can be viewed as
alternatives. This is because <now explain how properties p1-pn
make this so, and why when those properties do not hold, the situation
changes and how.>.
What are the properties? I would guess that one has to do with the intended
purpose of the ontology/schema. Related to this would be inference requirements.
Thanks,
Mike Uschold
** For now, lets say by ontology I mean a simple language like OKBC
or even RDFS that one can use Protégé for.
--
_____________________________________________
Dr. Leo Obrst The MITRE Corporation
mailto:lobrst@xxxxxxxxx Intelligent
Information Management/Exploitation
Voice: 703-883-6770 7515 Colshire Drive, M/S H305
Fax: 703-883-1379 McLean, VA 22102-7508,
USA
--
_____________________________________________
Dr. Leo Obrst The MITRE Corporation
mailto:lobrst@xxxxxxxxx Intelligent
Information Management/Exploitation
Voice: 703-883-6770 7515 Colshire Drive, M/S H305
Fax: 703-883-1379 McLean, VA 22102-7508,
USA
--
_____________________________________________
Dr. Leo Obrst The MITRE Corporation
mailto:lobrst@xxxxxxxxx Intelligent Information Management/Exploitation
Voice: 703-883-6770 7515 Colshire Drive, M/S H305
Fax: 703-883-1379 McLean, VA 22102-7508,
USA
|