Fwd: submission from [[email protected]]

From: Joseph Coffman ([email protected])
Date: 11/26/01


>From: [email protected]
>X-Recipient: <[email protected]>
>Date: Thu, 22 Nov 2001 07:30:50 -0500 (EST)
>X-Authentication-Warning: mail.daml.org: majordom set sender to 
>[email protected] using -f
>To: [email protected], [email protected], [email protected]
>Subject: BOUNCE [email protected]:    Non-member submission 
>from [[email protected]]
>
> >From majordomo-owner Thu Nov 22 07:30:49 2001
>Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
>         by mail.daml.org (8.10.2+Sun/8.10.2) with ESMTP id fAMCUmK07824
>         for <[email protected]>; Thu, 22 Nov 2001 07:30:49 -0500 (EST)
>Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com 
>[172.21.143.34])
>         by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id 
> fAMCS9A16264
>         for <[email protected]>; Thu, 22 Nov 2001 14:28:09 +0200 (EET)
>Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com
>  (Content Technologies SMTPRS 4.2.5) with ESMTP id 
> <[email protected]>;
>  Thu, 22 Nov 2001 14:27:28 +0200
>Received: by esebh25nok with Internet Mail Service (5.5.2652.78)
>         id <XCKLP9ZX>; Thu, 22 Nov 2001 14:27:28 +0200
>Message-ID: <[email protected]>
>From: [email protected]
>To: [email protected], [email protected]
>Cc: [email protected]
>Subject: RE: Cutting the Patrician datatype knot
>Date: Thu, 22 Nov 2001 14:27:19 +0200
>MIME-Version: 1.0
>X-Mailer: Internet Mail Service (5.5.2652.78)
>Content-Type: text/plain;
>         charset="iso-8859-1"
>
>
>
> > -----Original Message-----
> > From: ext Peter F. Patel-Schneider
> > [mailto:[email protected]]
> > Sent: 21 November, 2001 20:34
> > To: [email protected]
> > Cc: [email protected]
> > Subject: Cutting the Patrician datatype knot
> >
> >
> > Hi:
> >
> > Here is my Thanksgiving turkey for you all. :-)
>
>
>I think the WG is already "stuffed" with DT proposals ;-)
>
>
> > Suppose one decided that nodes in an RDF graph were one of
> >       1/ URIs
> >       2/ blank nodes
> >       3/ data values
> >       4/ text (untidy)
>
>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.
>
> > and that interpretations mapped
> >       1/ URIs into resources [as before]
> >       2/ blank nodes into ... [as before]
> >       3/ data values into themselves!
> >       4/ text into arbitrary literal values!
> >
> > Then a datatype scheme for the model theory is quite simple,
> >
> >       Let DT be a collection of datatypes.
> >       For d in DT let DTC(d) be a set, the extension of d.
> >
> > The model theory for datatypes is also quite simple.
> >
> >       For d in DT  ICEXT(d) = DTC(d)
> >       For d in DT  ICEXT(rdfs:Literal) >= DTC(d)
> >
> >
> > An RDF/XML serialization of an RDF graph element of the form
> >       < s , p , v > for v a data value
> > is of the form
> >       <... s ...>
> >         ...
> >         <p xsi:type="du">x</p>
> >         ...
> >       </...>
>
>Unfortunately, this isn't legal RDF/XML. It'd have to
>be something like:
>
>      ...
>      <p xsi:type="du" rdf:value="x"/>
>      ...
>
>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?
>
>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?
>
>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?
>
>Also, the xsi:type attribute value will be interpreted as a literal
>not a URI Ref by an RDF parser. I.e. for the above you get
>
>      s --p--> _:1 --xsi:type---> "foo:du"
>      |          |
>      |          ----rdf:value--> "x"
>      |
>      ----p--> <foo:du:x> --rdf:type--> <foo:du>
>
>Note that in this case, the type value of xsi:type is treated
>as something different than the value of rdf:type (then again,
>maybe this is what you are trying to do...?)
>
>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?
>
> > Thus in the serialization we need access to the
> > lexical-to-value mapping,
> > but not in the model theory.
> >
> > An RDF/XML serialization of an RDF graph element of the form
> >       < s , p , t > for t some text
> > is of the form
> >       <... s ...>
> >         ...
> >         <p>t'</p>
> >         ...
> >       </...>
> > where t' is the appropriate XML version of t.
> >
> >
> > What is lost?
> >
> > 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?
>
>I.e., the range constraint as defined above *implies* the
>following knowledge
>
>    <Person>
>       <age rdf:type="xsd:integer" rdf:value="10"/>
>    </Person>
>
>even if it is not defined as such in the explicit statement.
>
>Right?
>
>And the actual assertion of implied statements based on rdfs:range
>constraints could result in a modification of the graph itself
>to accomodate the expanded, explicitly typed idiom.
>
>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).
>
>
> > 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.
>
> > 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 ;-)
>
> > Fewer messages on rdf-core-wg!!!
>
>Let's hope!  Where's that wish-bone...?  ;-)
>
> > PS:  The name of this proposal is PFPS (or, if you really need to save
> >      bits, PS).
>
>Fair enough.
>
>And the name of the revised P+DC+DAML multi-idiom proposal as
>outlined immediately above should probabably be PFFTTTHT!!!
>(or just '!' for short ;-)
>
>Happy Turkey Day Y'all!
>
>(not that it means much here in Finland...)
>
>Cheers,
>
>Patrick
>
>--
>
>Patrick Stickler              Phone: +358 50 483 9453
>Senior Research Scientist     Fax:   +358 7180 35409
>Nokia Research Center         Email: [email protected]

Joseph Coffman
703 284 8624
703 486 4567
BBN Technologies
A Verizon Company  


This archive was generated by hypermail 2.1.4 : 04/02/02 EST