RE: Cutting the Patrician datatype knot

> > Why not let text nodes be tidy if they don't map to any
> > values? I.e. if they don't themselves denote a resource,
> > then why worry if they have other interpretations in
> > other contexts? They're just strings in this case, right?
> > so go ahead and tidy them up.
> 
> Precisely to leave the door open for a better handling of 
> them.  This is
> why I injected my comment into rdf-core-wg quite a while 
> ago---the model
> theory was making literals tidy, which prevented any 
> possibility of having
> the lexical-to-data mapping of a literal depend on its type.

Fair enough.
 
> > Unfortunately, this isn't legal RDF/XML. ...
> > ...
> 
> I'm proposing making it legal.

OK. Fair enough. Though that wasn't 100% clear. Thanks
for making it so.

> > which gives us the graph:
> > 
> >      s --p--> _:1 --xsi:type---> "foo:du"
> >                 |
> >                 ----rdf:value--> "x"
> > 
> > So essentially, this is the DAML idiom (and very similar
> > to the DC idiom) but using xsi:type instead of rdf:type, 
> > right?
> 
> No.  I'm proposing that the end result be much more like
> 
> 	s --p--> xsd:du:x

Ahhh...  A URV. OK. No objection from me there ;-)

But if we're going to end up with a URV in the graph, why
not just use one in the serialization? After all, it's
less typing and expresses the same knowledge... 

I.e.    <p rdf:resource="xsd:du:x"/>

> > Though, why use xsi:type rather than rdf:type? Are we saying
> > that a typed literal resource is a different kind of resource
> > than a typed non-literal resource, and hence the typing is
> > declared differently? Are we sure we want to say that? And
> > are we adopting the full semantics attributed by the XML Schema
> > spec to xsi:type? What are the implications for broader statements
> > about XML Schema constructs in general in RDF if we use it for
> > typing literal resources?
> 
> Because the xsi:type plays a much different role than rdf:type.  Yes,
> yes. Yes.  Maybe, although all you need for this to go through is to
> understand the primitive (and, maybe, the built-in) XML 
> Schema datatypes.

OK. I follow you, though I need to chew on this one
for a bit... I'm still wondering about the implications
of having essentially two typing mechanisms, one for
literals and one for non-literals...
 
> I'm not aware of any problems with the rest of XML Schema.  You should
> still be able to use xsd:integer as a class, for example.
> 
> > What is the difference between:
> > 
> >      <p xsi:type="foo:du" rdf:value="x"/>
> >      <p rdf:type="foo:du" rdf:resource="foo:du:x"/>
> > 
> > I.e. why would a literal resource be typed by an xsi:type property
> > when a non-literal resource is typed by an rdf:type property? In
> > both cases, it is the resource denoted by the node that bears
> > the typing property, so why not use the same mechanism? Do we
> > then also need to add an xsi:range in addition to rdfs:range?
> 
> Because literals are, indeed, different from non-literals.   
> Because the
> typing of literals also provides the lexical-to-data mapping.  No,
> rdfs:range works fine to type the object position of a 
> property, it just
> does not have any lexical-to-data mapping implications, which 
> are what are
> causing the current problems.

I'm not fully convinced that there are problems relating
to the lexical-to-mapping. The data type (e.g. xsd:integer)
defines the lexical and value spaces. If a literal is paired
with a data type, then one should presume that the data type
defines a lexical space as well as a value space. But keeping
both data types with lexical representation and data types
without lexical representation in the same playground allows
us to draw inferences about relations between them.

I.e., I'm not sure the extra machinery is really needed.
(maybe it is, but I can't see it yet) 

> > ...
> 
> Note that I *am* extending the syntax of RDF/XML, so *I* get 
> to say how
> this extended syntax maps to RDF graphs!

Fair enough. That just wasn't clear from your examples, so I
guess it was fair to assume you weren't trying to extend the
syntax.
 
> > If we use rdf:type instead of xsi:type, we get something
> > perhaps more consistent, both insofar as literal and
> > non-literal resources are concerned, as well as in the
> > treatment of type values as URI Refs by the RDF parser:
> > 
> >      <p rdf:type="foo:du" rdf:value="x"/>
> >      <p rdf:type="foo:du" rdf:resource="urn:foo:x"/>
> > 
> > 
> >      s --p--> _:1 --rdf:type--------------|
> >      |          |                         |
> >      |          ----rdf:value--> "x"      |
> >      |                                    v
> >      ----p--> <foo:du:x> --rdf:type--> <foo:du>
> > 
> > Both objects of the 'p' property are nodes denoting
> > values and both value nodes are typed, and the literal
> > resource value node has the extra information about
> > its lexical form, which is needed for literal resources
> > but not for non-literal resources -- but otherwise, it
> > is a consistent representation and consistent treatment
> > of data typing for both literal and non-literal resources.
> > 
> > Eh?
> 
> But, again, literals are different from non-literals.  For example,
> consider the following
> 
> 	<foo> 
> 	  <rdfs:range rdf:resrouce="xsd:integer"/> 
> 	</foo>
> 
> 	<Person rdf:about="John">
>           <foo xsi:type="xsd:decimal">7</foo>
>         </Person>
> 
> This is perfectly fine.

I'm not sure it is, but I'll defer comment for the moment...

> Using rdf:type gets into the problems with clashing mappings.
> 
> For example
> 
> 		 ----rdf:type----->[string union integer]
> 		 |
>       s --p--> _:1 --rdf:type----->[integer union string]
>                  |                        
>                  ----rdf:value--> "7"     
> 
> results in uncertainty over whether s's p is 7 (the integer) 
> or ``7'' (the
> string).

But such a union would not constitute a valid data type per
the (presumably) agreed definitions such that, for any lexical
form, there is a mapping to one and only one value in the 
value space.

I'm not suggesting that the data type is any union of two
data types that itself does not constitute a valid data type.

The above is not the same as the following

  		       ----rdf:type----->[string]
  		       |
        s --p--> _:1 --rdf:type----->[integer]
                   |                        
                   ----rdf:value--> "7"     
   
Here, there are two assertions, and two pairings

     ("7",string)
and 
     ("7",integer)

and each pairing denotes a value in the value space of 
the particular data type of the particular pairing

A combination of locally defined data type and range defined
data type do not result in a union of both data types but
in two separate assertions/pairings.

> [..]
> 
> > > 
> > > Well, the ability to provide the lexical-to-data mapping 
> once, as in
> > > 
> > > 	<Property rdf:about="age">
> > > 	  <rdfs:range rdf:resource="xsd:integer">
> > > 	</Property>
> > >
> > > and the related ability to do anything useful with
> > > 
> > > 	<Person>
> > > 	  <age>10</age>
> > > 	</Person>
> >  
> > How so? Since type is being ascribed to the object of a statement,
> > and thus to the node (not the literal), why doesn't rdfs:range 
> > work as expected?
> 
> Because text has no type.  Text is text.  Text is not string. 
> Text is not
> integer.  

I'm not saying that the literal alone denotes a value. It is
the pairing of literal plus data type. That pairing can occur
in more than one way:

1. local typing (DAML,URV,etc)
2. global typing (rdfs:range)

If you don't have a pairing of literal and data type, you can't
map the literal to a value, even if you know that a given node
in the graph denotes "some" value.

> > Thus, the two idioms (DAML/DC and P respectively):
> > 
> > 1)    X PROP [ rdf:value "LIT" ; rdf:type "TYPE" ] .
> > 
> > 2)    X PROP "LIT" .
> >       PROP rdfs:range TYPE .
> > 
> > are semantically synonymous.
> > 
> > They both define the pairing ("LIT",TYPE) which is
> > (I believe) the agreed denotation of a value in the
> > value space of a given data type for a lexical form
> > (literal).
> 
> If the datatyping scheme cooperates, then the rdf:type 
> solution works well.
> If it doesn't, then you probably need some other mechanism 
> for providing the
> lexical-to-data map.

If the data type does not define a lexical space, then
no mechanism is going to work. Either there's a defined
mapping from lexical form to value or there isn't. It
is therefore enough to identify that pairing of lexical
form (literal) to data type (URI) in order to denote the
value.

If a pairing ("LIT",TYPE) can't be resolved to a value
because the TYPE doesn't "cooperate" by defining a lexical
space and a corresponding mapping to its value space, then 
you're out of luck anyway, no matter what mechanisms you
try to introduce. All that counts is the pairing. Once
that's known unambigously you're done.

Both of the above (currently used) idioms (and also the
URV encoding) provide for such unambigous pairing.

> > > However, some of both of these can be regained by employing 
> > > XML Schemas,
> > > i.e., taking any XML Schema information in an XML document 
> > > and using that
> > > to determine the actual datavalue for literals.
> > 
> > I'm not sure we'd like to have to do that. It could be (rightly)
> > seen as an unreasonable burden on an RDF system to have to use
> > an XML Schema parser/component just to be able to make sense of 
> > typed data literals, especially if the system wishes simply to 
> > make inferences about type relations and never interpret the 
> > literal values' lexical forms themselves.
> 
> I am totally mystified by this comment.  First, one could just say
> that only the primitive and built-in types are supported for 
> now.  Second,
> so what?  XML Schema is a W3C Recommendation.  Is RDF, and, certainly
> RDF/XML, not part of the World-Wide Web.  Is the RDF Core WG 
> not chartered
> to ``build upon XML Schema datatypes to the fullest extent 
> practical and
> appropriate''?  

Sure. And I fully support that. The issue is what is meant
by "build upon" as well as what is considered "appropriate".
 
> ...
> your argument is ... in my view, 
> counter to the
> RDF Core WG charter.

You appear to have misunderstood my meaning. I am only interested
in seeing that the RDF treatment of data typing is not bound too
tightly to any particular data typing scheme. This is beneficial
not only for RDF but also for XML Schema.

I point out that Graham appears to have a better understanding 
of my position, which does not conflict with the charter, see his message:
http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Nov/0336.html
 

> > > Also, if anyone comes up with an acceptable (i.e., 
> acceptable to both
> > > Pat and Patrick :-) as well as others) method for working 
> > > with text, i.e.,
> > > text nodes that do not get a type from XML Schema 
> > > information, then it can
> > > be added to the proposal.
> > > 
> > > 
> > > What is gained?
> > > 
> > > Better conformance with XML and XML Schema!
> > 
> > Seems like the P+DAML dual idiom approach has equal "conformance"
> > to XML and XML Schema (or maybe I've missed something, again ;-)
> 
> No.  The DAML+OIL approach is somewhat similar, but does not 
> fit as well into
> XML and XML Schema documents.  

I'm not sure that the goal of supporting XML Schema data types
is quite the same as using XML Schema serialization forms for
pairing literals to data types. Maybe it is, but I think that
would need to be clarified.

Cheers,

Patrick

Received on Friday, 23 November 2001 13:57:40 UTC