Re: DAML ObjectProp vs DatatypeProp

From: Drew McDermott <drew.mcdermott@yale.edu>
Subject: DAML ObjectProp vs DatatypeProp
Date: Wed, 16 May 2001 10:19:55 -0400 (EDT)

> 
> When the latest DAML+OIL draft came out, there was some discussion of
> the separation between ObjectProperty's and DatatypeProperty's.  I
> have reviewed it, but I am still puzzled by the distinction.

The reason for the distinction between ObjectProperty and DatatypeProperty
is so that DAML+OIL doess not have to worry about (inverse) properties of
datatype values.  If you could create properties from datatypes, you could
state things like ``the number 3 is related to at most 5 people by the
inverse of family-size''.  This would require collecting the people with
family-size 3, a very annoying burden on implementers.  There are even much
worse examples that can be generated.

> I agree that there is a need for concrete datatypes in DAML (as in RDF
> and XML).  I am somewhat puzzled by exactly how to go about providing
> them.  The problem is that DAML has inherited from the SGML/XML
> tradition this vagueness about exactly what the leaves of the tree are
> in a marked-up document.  

Agreed, there is a vagueness in XML here.  DAML+OIL has tried hard to
overcome this vagueness.  In essence, every thing that is not
an RDF resource belongs to the DAML+OIL datatype domain.  There are two
ways of writing datatype values:

1/ Use an explicit datatype:
	
	<xsd:integer rdf:value="13"/>

   This refers to the integer 13.  The mapping from syntax to semantics is
   controlled by the XML Schema ``reader'' for integers.

2/ Use an RDF literal without an explicit datatype:

	<age>37</age>

   or

	<age rdf:value="37">

   This should eventually refer to a single datatype value, but that
   determination can only be made when (and if) the typing information for
   the property ``age'' within whatever object the above syntax occurs.
   If/when the typing information is available, the mapping from syntax to
   semantics is made as above.  If no typing information is available, then
   the meaning of the above is rather murky.

The first method is preferred.  In fact, the second method was only added
under duress, and so that existing DAML+OIL files would remain valid.



Strange constructions, like

   <xsd:string rdf:value='"13"'>

should be a string with 4 characters.
Similarly

    <xsd:integer rdf:value='"13"'>

would be invalid.


> Anyway, can someone point me to the authoritative source on literal
> data in RDF/DAML?  If there isn't one, I would be inclined to
> recommend:
> 
> a) That literals occur *only* as attribute values.  Text in elements
> is just too unconstrained.  The notion of "markup-free text" is rather
> wobbly (probably deprecated by the Authorities); it's not clear even
> how to handle whitespace.
> 
> b) That there be a unambiguous syntax for literal data, so that one
> would *not* have to declare the intended datatype of every attribute
> value.  The convention that "Smith" sometimes refers to "Smith" and
> sometimes to Smith should be done away with.  If a string is intended,
> there should be a syntax for specifying strings, either '"Smith"',
> "'Smith'", "\"Smith\"", or ""Smith"".  (That last one is kind of
> cute.)
> 
> c) If someone writes <shoesize value='"Smith"'/>, the RDF validity
> checker notes that the provided literal violates the rdfs:domain
> constraint on shoesize, and issues an error message.  
> 
>                                              -- Drew McDermott

I hope that my comments above have helped.

Peter F. Patel-Schneider
Bell Labs Research

Received on Wednesday, 16 May 2001 11:01:51 UTC