Re: Typed literals: current status

Patrick,

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, 
>patrick.stickler@nokia.com]
>
>
>----- 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
>deviant.

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.

and
>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.
>
>Patrick

Received on Tuesday, 22 October 2002 04:29:22 UTC