Re: Semantic Web permathread, iteration n+1 (was Re:
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 Mary hasEyes color:blue shape:round 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 Mary hasEyes (something of unspecified type) color:blue shape:round 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 - Mary eyes color:blue shape:round 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. Cheers, Tom P
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format