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

Re: Typed literals: current status

From: Brian McBride <bwm@hplb.hpl.hp.com>
Date: Tue, 22 Oct 2002 09:31:35 +0100
Message-Id: <>
To: "Patrick Stickler" <patrick.stickler@nokia.com>, "Dan Connolly" <connolly@w3.org>
Cc: "Jeremy Carroll" <jjc@hplb.hpl.hp.com>, <w3c-rdfcore-wg@w3.org>


Thanks for the response.  I think I understand your point of view better now.

At 09:52 22/10/2002 +0300, Patrick Stickler wrote:

>[Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, 
>----- Original Message -----
>From: "ext Brian McBride" <bwm@hplb.hpl.hp.com>
>To: "Dan Connolly" <connolly@w3.org>
>Cc: "Jeremy Carroll" <jjc@hplb.hpl.hp.com>; <w3c-rdfcore-wg@w3.org>
>Sent: 21 October, 2002 19:24
>Subject: Re: Typed literals: current status
> > I agree that doesn't look good either, which would suggest we drop the 
> lang
> > tag from the abstract syntax, but that invalidates the Nokia data, 
> which is
> > undesirable.
> >
> > I'm suggesting the WG consider which is the least damaging option we
> > have.  Patrick: comment?
>Well, our present usage is presuming value-based semantics for
>inline literals, where we would have (using the most recent syntax):
>    mars:shortLabel rdfs:range mars:Token .
>    some:Resource mars:shortLabel "Foo"-en .
>    some:Resource mars:shortLabel "Bar"-fi .
>Now, since we can't do that, we're going to have to instead say
>    some:Resource mars:shortLabel mars:Token"Foo"-en .

That seems to suggest that you will have to change this data anyway to be 
conformant.  Would it be feasible to change it use a b-node while you are 
at it?

   some:Resource mars:shortLabel _:v .
   _:v  rdf:value mars:Token"Foo" .
   _:v  mars:lang "en" .

or some such construct?

>We need the language classification in order to differentiate
>between different language variants, and we also need the
>datatype to constrain values to valid tokens. It is not
>acceptable to only say
>    some:Resource mars:shortLabel "Foo"-en .
>as the property value is a token, not an abitrary Unicode string.

Right, I can see that.

>Yes, theoretically, we could go with some other representation,
>such as using a bnode,

Ah.  You answer my question.

>  but that complicates all code which then
>has to deal with alternate graph representations for language
>qualified values versus non-language qualified values, rather
>than just an optional lang suffix on the label which is much
>easier and more consistent to deal with.

 From a Nokia point of view I can see that changing the code is 
undesirable.  But from a more global  point of view, is it something that 
perhaps Nokia should be willing to do in order to preserve conformance with 
the xml schema datatypes model.  I would have thought that was something 
Nokia would also like to preserve.

>Alternately, we could use reification and qualify each statement
>for language, but again, that is a very heavy solution and
>grossly redundant.

Oh Yuk. Right.  Not a good way to go.

>Ideally, RDF would have a proper scoping mechanism a'la XTM
>for such things, but as it doesn't, the above approach seems
>the most straightforward.
>If it comes down to choosing between no lang tag and literals
>denoting pairs of value + lang then I'd definitely opt for no
>lang tag on literals and keeping the typed literals denoting
>values, as the pair interpretation simply breaks everything IMO.

Right, that is what is worrying me.

>Changing the software to deal with some alternate way of
>capturing the language qualification is not my worry. No, it's
>not trivial, but it's not all that terrible either. But having
>to change deployed content, and get numerous existing systems
>that push metadata into centralized tools is going to be
>*extremely* painful, if not impossible (those who work for
>big companies will fully appreciate this). It's concievable
>that the old-style RDF can be transformed into the new-style
>RDF at various key points in the process, but most likely
>our RDF (at the creation source at least) will remain persistently

Transforming legacy is always a pain.  To some extent its unavoidable given 
a 'clarification' of the spec.

To be quite frank, RDF over XML has not been an easy sell,

No. I can appreciate that.

>given the distance that RDF is now diverging from the way we
>do things (or visa versa) it looks probably that RDF will become
>unsellable for future incarnations of our present systems, at least
>at the more general level, even if future XML is mined into RDF
>for some purposes.
>But hey, you can't please everyone all of the time.

Exactly.  But we can try to ameliorate the effects.  I wonder if there is 
scope for a note discussing how to migrate legacy data.

>  I guess
>we may have to get what we need elsewhere and relegate RDF
>to the fringe rather than core of our processes.

That would be a shame.

>So I guess the WG can omit lang tags from literals entirely.
>It's looking like it won't matter to us one way or another.
Received on Tuesday, 22 October 2002 04:29:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:16 UTC