W3C home > Mailing lists > Public > www-rdf-logic@w3.org > May 2001

Re: DAML ObjectProp vs DatatypeProp

From: Dan Connolly <connolly@w3.org>
Date: Wed, 16 May 2001 11:39:51 -0500
Message-ID: <3B02AD57.B4C0CAF0@w3.org>
To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
CC: drew.mcdermott@yale.edu, www-rdf-logic@w3.org
"Peter F. Patel-Schneider" wrote:
> 
> From: Drew McDermott <drew.mcdermott@yale.edu>
> Subject: DAML ObjectProp vs DatatypeProp
> Date: Wed, 16 May 2001 10:19:55 -0400 (EDT)
[...]
> > Anyway, can someone point me to the authoritative source on literal
> > data in RDF/DAML?

Unfortunately, no; a number of related issues were
not nailed down in RDF 1.0; they were postponed
until XML Schema datatypes came along. A number
of issues have been raised; the RDF Core WG
is chartered to address them, but I'm not sure when;
for example:

http://www.w3.org/2000/03/rdf-tracking/#rdfms-xmllang
http://www.w3.org/2000/03/rdf-tracking/#rdfms-literalsubjects
http://www.w3.org/2000/03/rdf-tracking/#rdfms-literals-as-resources

In the design of DAML+OIL, we tried to come up
with our own interpretation, but as you've
seen, it's not entirely satisfactory.

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

[*Except in the case of rdf:parseType="Literal" in
which I regard the value as an object structured
per the XML Infoset spec. But that's another story...
cf
http://www.w3.org/2000/03/rdf-tracking/#rdfms-literal-is-xml-structure
]


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

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

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 say "the integer" rather than "an integer" because
DAML+OIL imports from the XML Schema spec the fact that
lexical representation is unambiguous over each
primitive datatype (in this
case, the decimal datatype from which integer is derived).

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

I also don't understand that; you suggested earlier that
it's achieved through some trick in the model-theoretic
semantics. I haven't managed to figure it out yet.
Which part of the model-theoretic semantics provides the hook?

Er... trying to convert the above to KIF formulas
confuses me; the first looks like

	(PropertyValue age ?x "37")

but in the second one, "age" is in the type position, not
the property position; so it looks like:

	(PropertyValue rdf:type ?x age)
	(PropertyValue rdf:value ?x "37")

I don't think that's what you meant; I think you perhaps
just meant to show the use of the age property
as an XML attribute:
	<rdf:Description age="37"/>



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

What does "If/when the typing information is available" mean?

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

I don't see any interaction with existing DAML+OIL files.

I don't think I understand the second method.

> Strange constructions, like
> 
>    <xsd:string rdf:value='"13"'>
> 
> should be a string with 4 characters.
> Similarly
> 
>     <xsd:integer rdf:value='"13"'>
> 
> would be invalid.

I agree with these.

> > Anyway, can someone point me to the authoritative source on literal
> > data in RDF/DAML?

Unfortunately, no; see above.

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

That would be one way to do things. It's not consistent
with the way folks are used to using XML, but
it would make the distinctions syntactically evident.

I'm loath to add yet-another-layer of quoting, though.

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

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Wednesday, 16 May 2001 12:40:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:45:37 UTC