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

> -----Original Message-----
> From: ext Jan Grant [mailto:Jan.Grant@bristol.ac.uk]
> Sent: 09 August, 2002 14:09
> To: Stickler Patrick (NRC/Tampere)
> Cc: dave.beckett; 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 ] 
> 
> 
> 
> Pat, I mooted this ages ago with a pointer to
> http://ioctl.org/rdf/literals; but...
> 
> 
> On Wed, 7 Aug 2002 Patrick.Stickler@nokia.com wrote:
> 
> > 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.
> 
> Mine won't; it supported this from the beginning, because 
> properly typed
> literals seemed to be the natural way to support datatypes in 
> RDF. (this
> is, however, 3 1/2 years old)
> 
> > 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.
> 
> 
> You're right in identifying that the resources and literals are both
> categories of "entity" for want of another overloaded term. However,
> there are two things that mean that you don't want literals to just be
> URI-labelled things:
> 
> 1. Conceptually, everyone agrees on the denotation of literals; at
> least, I think that's a fundamental notion with this 
> proposal. That is,
> that all interpretations ought to give the same interpretation for a
> literal (at least, that's the literal'resource distinction as far as I
> see it here)

I certainly don't agree with that. I consider literals to have
context dependent meaning. Literals are not global constants,
and even saying that in the RDF MT literals "denote themselves"
is simply pushing the untidy semantics of literals outside of
RDF -- but they *still* have untidy semantics! You can't escape
that.

"10" interpreted as a base 10 lexical representation does not
denote the same thing as "10" interpreted as a base 2 lexical
representation.

(xsd:integer)10 is a completely different thing from "10",
just as both are completely different from a URI.

Calling (xsd:integer)10 a "literal" is misleading and does
not help RDF one bit.

And it still does not address the whole issue of what *real*
literals, such as "10", mean when used inline, without local
typing, but where the datatype context intended to apply to
its interpretation is bound to the property for which it serves
as a value.

> 2. Conceptually, we want to put larger sets of things into "Literal"
> than will fit into URI-space. This is where the token/denotation
> distinction is important, because while you might say "throw all the
> reals in there", even a million Mike Deans (as a prolific RDF 
> producer)
> working until the heat-death of the universe can only produce RDF
> documents that use a few of them.

Eh? URI space is finite? *Any* so-called (datatyped) literal
such as (xsd:integer)10, i.e. the entire infinite set, can
be expressed as a val: URI.

Sorry, I don't follow you at all here.

> > 2. Also, can the new typed literal be a subject? Can you say
> >
> >     (DDD)10 rdf:type <DDD> .
> >
> > ???
> 
> Separate issue; the syntax impact of this change is large, but there's
> little or no conceptual reason to forbid it.

As I've said before, I'm not specifically opposed to the
idea of a fourth graph node type, which explicitly denotes
datatype values based on the pairing of datatype identity
and lexical representation. I've called for such a representation
for a very long time.

But those are *not* literals. They're something else.

Furthermore, I feel that the process has broken down. That
the WG agreed not to make any further changes to the
datatyping solution already documented unless required
by fatal flaws.

Finally, if this proposal goes the further step of making
particular datatypes native to RDF such that RDF applications
will have to grok them, then I am strongly opposed. It
kills the genericity and neutrality that RDF has with regards
to particular models.

> > 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.
> 
> That phrase should be printed out and nailed over the door of the WG
> chambers :-)
> 
> > > 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?
> 
> There are a few fundamental types from which all information systems
> seem happy to be able to represent compond and derived types. 
> But sergei
> wants the space of literals to be open-ended.

I also want it to be open-ended, but also generic.

> > > 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.
> 
> There I agree. I don't like the sitg proposal personally, but that's
> because I still find it really ugly, not expressively deficient.

Well, there are aspects about it that I don't find ideal,
but it's been a long process to get to that point, and 
to be quite honest, I consider the process as having 
broken down.

1. Native datatypes have been rejected for a very long time,
and there is no technical reason to include them, so I am
amazed that they are being proposed this late in the game.

2. A single node representation for datatyped literals 
was presented from very early on, and that was rejected
by the WG (dispite there not really being any technical
grounds for rejection, just personal taste, IMO) so again,
why are we revisiting this again this late when there is
no technical requirement to do so.

> > > 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" .
> 
> Looks like a string to me.

What, it's not a literal? So now datatyped literals
are called "literals" and literals are called "strings".

I really hope I've missed something here. 

Patrick

Received on Friday, 9 August 2002 08:57:56 UTC