W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > August 2002

RE: What the #@&*$(!@ is going on here?! (was RE: N-Triples for proposed xsi:type [was Re: xsi:type test case ]

From: <Patrick.Stickler@nokia.com>
Date: Wed, 7 Aug 2002 15:21:57 +0300
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B5FBA72@trebe006.NOE.Nokia.com>
To: <Jan.Grant@bristol.ac.uk>, <dave.beckett@bristol.ac.uk>
Cc: <w3c-rdfcore-wg@w3.org>, <Graham.Klyne@MIMEsweeper.com>, <jjc@hplb.hpl.hp.com>

> -----Original Message-----
> From: ext Jan Grant [mailto:Jan.Grant@bristol.ac.uk]
> Sent: 07 August, 2002 14:39
> To: Dave Beckett
> Cc: Stickler Patrick (NRC/Tampere); w3c-rdfcore-wg; Graham.Klyne; jjc
> Subject: Re: What the #@&*$(!@ is going on here?! (was RE: 
> N-Triples for
> proposed xsi:type [was Re: xsi:type test case ] 
> On Wed, 7 Aug 2002, Dave Beckett wrote:
> >
> > >>>"Patrick.Stickler" said:
> > > [lots]
> >
> > Don't read into a proposed N-Triples syntax change more 
> than I wrote.
> > I could have put it has datatype(decimal, "2.0") or somesuch.
> > Specifically don't read that as qnames but evocative of how XSD is
> > used in XML; similar how the xsi:type is being used in this 
> > a special attribute.
> >
> > But I'm still waiting for the triples for these RDF/XML + xsi:type
> > examples.  Which is hard to do if they have no n-triples syntax.
> > I'll create a better N-triples if needed when I'm clear what (if
> > anything) has changed in the graph.  Catch 22.
> What's changed in the graph is that the space of "literals" has
> expanded; that is that
> 	jenny age "10" .
> and
> 	jenny age number(10) .
> are distinct triples, but that
> 	jenny age number(10) .
> 	bob age number(10) .
> indicates that jenny and bob really do have the same age.

Thus, 'number(10)' is just an alternative expression of a URI,
since it globally and unambiguously denotes a value resource.

I.e. one can also say that

   Jenny age <val:(http://www.w3.org/2001/XMLSchema%23integer)10> .
   Bob age <val:(http://www.w3.org/2001/XMLSchema%23integer)10> .

mean that Jenny and Bob have the same age.

Now, I'm all for TDLs being formally recognized, as I've
long seen them as the very kernel of how RDF datatyping
works, but...

1. You're not going to have 'number(10)' in the graph. You'll
have something like


and then you'll have to define most of the qualities that URIs
have for tidyness, etc. for these new components of the graph,
and every single parser and every single triples store will have
to change to support the new, mostly redundant in nature, typed
literal node.

I simply don't see the benefit over just using a URL. RDF won't
be able to tell you *anything* more about what number(10) means
than about what val:(http://www.w3.org/2001/XMLSchema%23integer)10
means. An external application is going to have to do that
anyway -- and external applications parse URIs all the time for
many different reasons.

2. Also, can the new typed literal be a subject? Can you say

    (DDD)10 rdf:type <DDD> .


You *can* already say

        rdf:type http://www.w3.org/2001/XMLSchema#integer .

I don't see anything new or beneficial here. Only more work
for the WG and more questions to be answered in the final
stages of what has been a very long process.

> As to how much it has expanded: this proposal seems to be capable of
> going two ways:
> 1. the space of literals is expanded by a small set of other literal
> types to provide a sufficient foundation for datatyping to be built
> upon. That a small set can be sufficient is indicated by the success
> people have in using RDBM systems, I suppose. This proposal would then
> need guidelines as to what to do with other "datatypes": eg: 
> factor out
> units in property values; use uri-labelled resources for enumerations
> and taxons; use graph-structure to express compound types.

Er, kinda like using rdf:type, URIs, bnodes and RDF classes?

There is nothing new here.

> This reading means that the RDF parser must have a transform from some
> serialised form to the appropriate value, but that the values are what
> are present in the graph. In this case, the "hook" for that 
> transorf is
> the xsi:type attribute. 

The rdf:type attribute would be a more optimal and correct choice, IMO.

Taking vocabulary terms from XML Schema is both unnecessary and 

> The space of literals is not 
> extnsible by third
> parties.

I don't know what that means.

> Presumably for datatyping and range constraints, etc, rdf:Literal
> (rdfs:Literal? I forget) is subclassed into numbers (or ints 
> and reals),
> strings, langstrings, whatever.

Ummm, and where are those number classes defined?
And are all datatypes then number types?

> That literals are essentially self-denoting entities is 
> obvious in this
> setup.

No, a graph node such as


is *NOT* a literal. It is something else. And even if
tidy literals were adopted where such actual literals
(sans any datatype) would be self-denoting, such
typed literal constructs as above would not be self-denoting
but would denote a member of the value space of the 
datatype -- otherwise, what's the point?!

They would not be self-denoting anymore so that a URI
would be self-denoting. Both are globally unambiguous
names for resources.

> 2. the space of literals is arbitrarily expandable by users, 
> and literal
> nodes in the graph are of the form <type, thing> where a 
> "thing" may or
> may ont be a lexical form. Treatment of compound, union, 
> intersection of
> types is unclear in this system.

It's not unclear in the stake-in-the-ground proposal.

> In this case the proposal is effectively "drawing a circle" around the
> construct from one of the other datatyping proposals that uses
> node-and-arc constructs, and calling the whole contents of that circle
> "the literal"

And what then is "10" in 

   Jenny age "10" .


Received on Friday, 9 August 2002 06:45:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:59 UTC