Lists Home |
Date Index |
Elliotte Rusty Harold wrote:
> At 9:56 PM -0400 6/4/04, Thomas B. Passin wrote:
>> Right, an arbitrary piece of xml does not carry enough information to
>> let you automatically distinguish between elements that represent
>> things and those that represent properties. A person generally has to
>> work that out. But when you do have a properly striped format, it can
>> be easy to turn into rdf (it's usually just about there as is).
> Why is there a distinction between "things" and "properties"? Isn't a
> property a thing? Can't a property have properties of its own?
In RDF, a Property is a kind of Resource, and you can in fact make
statements about it. However, apparently, this kind of practice
prevents many kinds of logical reasoners (or maybe all, I am not expert
enough to know) from being "sound" and /or "complete", so most of the
restricted logics (like various forms of Description Logics) restrict
the kinds of constraints you can place on properties (which is in effect
restricting what you can say about them). The goal of such restrictions
is to make sure that a reasoner can complete any assignment in a
reasonable time (such a polynomial time as opposed to, say, exponential)
and be sure that any answer is correct.
As an experiment, a few weeks ago I made some OWL-like statements about
a property and fed them to the Vowl OWL validator. It warned me that
making a statement about a property implied that it was a Class, but
that it had been declared to be a property. So it seems that OWL, for
one, doesn't want you do that.
In Topic Maps, you can say anything you like about either a property
type or a propety instance (of course, they are not actually *called*
properties in topic maps, they are either occurrences or associations or
roles in associations, depending on just what you have in mind).
However, the original question about properties having properties is not
usually what the xml files in question - quasi-striped files - are
doing. If I say
we as people understand that just fine. But in RDF terms, we are not
trying to say something about the property hasEyes. Instead, we want to
say things about Mary's *eyes*, but the element (or node) for those eyes
is implied, not actually present.
To make this work as rdf syntax, we have to tell the rdf processor that
"hey, there is an implied node right here", because otherwise it can't
tell what we have in mind. We can do that without actually inserting
the node into the document by adding the attribute
"rdf:parseType='Resource' to the element "hasEyes".
To the processor, this is the same as
(something of unspecified type)
Now the fragment is properly striped. You could also add an rdf:type
property so that the intepolated node would not be unspecified.
If we change the examples like this -
then we are missing the implied property hasEyes (or something like
that), so it still doesn't work as is for rdf.
Sorry that was a bit long-winded, but I hope it was helpful.