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

RE: RDF datatyping

From: Graham Klyne <GK@NineByNine.org>
Date: Fri, 11 Jan 2002 00:10:20 +0000
Message-Id: <5.1.0.14.2.20020110234748.038ac9a0@joy.songbird.com>
To: "Jeremy Carroll" <jjc@hplb.hpl.hp.com>
Cc: "Patrick Stickler" <patrick.stickler@nokia.com>, "Sergey Melnik" <melnik@db.stanford.edu>, "RDF Core" <w3c-rdfcore-wg@w3.org>
At 11:21 PM 1/10/02 +0000, Jeremy Carroll wrote:
>A few comments ...
>
>Patrick:
> > > The S idioms, while also doing the job, do so with more machinery and
> > > most significantly are contrary to the intuitions of current RDF users
> > > (data typing by predicate rather than by rdf:type).
>
>Graham:
> > I don't recognize that description of S:
> > - I don't see "more machinery" here, whatever that means,
> > - "contrary to the intuitions of current RDF users" is precisely one area
> > where I think S scores very strongly, based on my intuitions from work
>with
> > CC/PP (modulo small issues raised in my comments to Sergey's paper).
>
>The machinery I find hard to justify is:
>  - Needing three URIs for each datatype.
>    Seems a bit like needing to talk about "Jeremy's body", "Jeremy's soul"
>and "Jeremy' mind". Might be useful sometimes, but plain "Jeremy" will get
>you a long way. I suppose RDF is about triples!

We can do that in English because the language allows names to be 
disambiguated by context.  But as far as I know, nobody has succeeded in 
devising a theory that always works for a natural language.  (The chapter 
"Knowledge Soup" in John Sowa's book on KR does a pretty good job of 
exposing the difficulty of this.)

We need to start from a place where the meaning of a URI is well-defined, 
so if we need to make statements about three different aspects of some 
entity I submit that we need three different names.  I'm sceptical that we 
can talk effectively about a data type and its representations with just 
one name.

>  - Having two incompatible usage idioms (two compatible idioms would somehow
>be less cumbersome).

I don't see any incompatible idioms here.  Just different idioms.

>  - Always carrying the lexical values in the graph, and having the lexical
>values in the model theory.

Well, that's a reasonable opinion to hold, but I don't see it as additional 
machinery.  Well, not much.

>I find idiom A contrary to my intuitions simply because it is very
>unfamiliar, in a way that P & D are not. I find idiom B contrary in its
>insistence on talking about the lexical space when what I mean is the type -
>it's like a doctor who only cares about my body and not the well-being of me
>as a whole.

Again, these are reasonable opinions.

I'll note that some folks using RDF have found idiom A (where the 
indirection may involve a resource or a literal) is the appropriately 
flexible way to proceed in constructing information models in RDF.  It is 
quite central in the RDFWeb structure, and I understand also in some of the 
W3C uses of RDF.

>elsewhere Patrick:
> > It appears to me that the S idioms A and B are not compatible
>
>I found that to be the intent of the current document too, and I agree that
>it is a problem that the PD combination does not suffer from.

How are they (A and B) not compatible?

>graham:
> > The advantage of the S scheme is that is sits comfortably within the
> > current model theory.
>
>and again graham:
> > Point me to the model theory, and I may be convinced.
>
>I find S a theoretical work that is practically unappealling. The model
>theory is the tail not the dog.
>
>Yes, we do need a model theory to capture the PD proposal; but being
>well-grounded in the model theory is not the most important consideration.

If this group doesn't end up with something that is well-grounded in some 
appropriate formalism, I think we'll have wasted our time.

>Most users will have only a passing understanding of the MT, and merely
>wished to be reassured by it. If every time they think of a datatype they
>need to get unnecessarily involved in the complexities of lexical spaces,
>value spaces and the mappings between them they will rightly curse us.

Here, I agree.  My perspective on this is looking for a scheme that works 
for CC/PP, which was put together without any of these concerns (i.e. 
before there was any theory to be concerned about).  Of the proposals I've 
seen, it is the S scheme that seems to most effectively formalize the 
intent of that work.

I also agree that when the two idioms are mixed, some awareness of the 
difference between lexicals and values is required.

I'm still open to other worked-out proposals that hide this value/lexical 
distinction, but I'm concerned that we'll spin indefinitely for wont of a 
solid proposal.  A main virtue of S is that it's largely fleshed out, here 
and now.

#g


--------------------------
        __
       /\ \    Graham Klyne
      /  \ \   (GK@ACM.ORG)
     / /\ \ \
    / / /\ \ \
   / / /__\_\ \
  / / /________\
  \/___________/
Received on Thursday, 10 January 2002 19:15:47 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:43:53 EDT