Re: DAML ObjectProp vs DatatypeProp

   > 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.

   [peter patel-schneider] 
   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'm amazed.  Where in the DAML+OIL spec does it say implementers have
to do something like that?  I didn't think it put any constraints on
implementations at all, just on the syntax and semantics of the
language. 

   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.

But we also have

   [dan connolly]
   I view both cases:
      Attributes:   <tag name="Smith"> .... </tag>

      Elements with no markup inside:
		    <name>Smith</name>
   as the same formula:
	   (PropertyValue name ?x "Smith")
   i.e. I regard (most*) RDF literals directly as
   KIF strings. (or more accurately: Java strings,
   since KIF doesn't include Unicode characters
   in its string literals.)

I think this reflects the ambiguity I mentioned in my previous
message.  If an RDF literal is a KIF string, is that a purely
syntactic claim, or do you mean that the RDF literal *denotes* a KIF
string?

   I'm not even sure I understand the DAML+OIL design myself...

If and when I meet someone who claims to, I'm sure I can straighten
him out....

Dan further reacts to Peter's proposal above thus:

   I don't know what you mean by that; The mapping from
   syntax to semantics is specified by DAML+OIL in this case,
   no? i.e.

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

   is RDF 1.0 abbreviated syntax for

     <rdf:Description>
       <rdf:type resource="..XMLSchema..#integer"/>
       <rdf:value>13</rdf:value>
     </rdf:Description>

   which can be seen as formula ala
	   (exists (?x)
		   (PropertyValue rdf:type ?x xsd:integer)
		   (PropertyValue rdf:value ?x "13") )

   i.e. ?x is the integer whose lexical representation
   is the two-character-string "13";

I side with Peter here.  What I read Dan as trying to do is make
everything work properly in a world where strings are the *only*
datatype with literal representations.  That being the case, I of
course can't say <age>13</age>, because I would be implying that
someone's age is a string.  But if I simply stipulate that "13" is the
literal representaiton of the integer thirteen, the problem goes
away. 

                                             -- Drew McDermott

Received on Thursday, 17 May 2001 11:26:25 UTC