- From: <Patrick.Stickler@nokia.com>
- Date: Wed, 7 Aug 2002 15:21:57 +0300
- 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 > RDF/XML - > > 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 (http://www.w3.org/2001/XMLSchema#integer)10 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 <val:(http://www.w3.org/2001/XMLSchema%23integer)10> 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 risky. > 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 (http://www.w3.org/2001/XMLSchema%23integer)10 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" . ??? Patrick
Received on Friday, 9 August 2002 06:45:38 UTC