W3C home > Mailing lists > Public > public-owl-wg@w3.org > May 2009

Re: general stuff about rdf:text / rdf:PlainLiteral / ...

From: Bijan Parsia <bparsia@cs.manchester.ac.uk>
Date: Sun, 24 May 2009 09:30:26 +0100
Cc: "Peter F.Patel-Schneider" <pfps@research.bell-labs.com>, public-owl-wg@w3.org
Message-Id: <7B02DAAA-5847-41D4-A313-FEDD5EB15561@cs.manchester.ac.uk>
To: Sandro Hawke <sandro@w3.org>
I'm not getting involved....I'm not getting involved...I'm not get oh  
who the hell am I kidding?!

On 23 May 2009, at 17:37, Sandro Hawke wrote:
>> I'm even becoming very worried about the requirement to avoid  
>> literals
>> with this datatype in RDF graphs.  So far, I'm willing to go along  
>> with
>> this, but the continued changes to this aspect of the proposal are
>> troubling to me.  In particular, the rationale for the prohibition is
>> completely bogus.
> The rational I find convincing is that its hurts interoperation.

Can someone please sharpen this for me? I'm confused as to what the  
problem is.

>  If
> people start to use rdf:text in RDF graphs, then all the existing
> software won't see their data.

What?!? That *can't* be right at least in this bald form unless all  
existing software is hugely broken.

It's just a datatype after all!

>  That's something we should at least
> point out, warning people who might consider using rdf:text in their
> data.

As Peter said, so too for any new datatype, yes?

> But more than that, I think we have a duty to speak about whether old
> RDF software is then "broken" and should be modified to support
> rdf:text.  For myself, I could go either way on this, but I understand
> providers of RDF systems do not want this.

Wait, the first question is *whether* old RDF software is broken by  
rdf:text. Do you go either way one that?

Another way of framing the whole thing is we know old RDF software  
isn't *sensitive* to rdf:text...should they be *enhanced* to handle  
it? Why not? I think they should, by and large. But many don't really  
handle XMLLiteral (or they weren't back when I was looking.

>  It seems to me they have the
> stronger rights here, so I agree the spec should give some fairly  
> strong
> mandate about rdf:text literals not occuring in RDF graphs.

Shouldn't the priority of constituacies be users before implementors?  
Esp. since they can always *not* support rdf:text. It's not a required  

And, frankly, the cost is pretty damn minimal.

>  To my
> understanding, this issue was decided before Last Call, as a MUST,  
> and I
> haven't seen evidence we should re-open the matter.

I guess I don't care about silly conformance requirements except in so  
far as they lower respect for conformance. I think the datatype being  
optional is all that's really needed. Frankly, if I find rdf:text a  
better and cleaner way of handling textual literals (qua user and tool  
builder) I'm going to use it, and I'm going to use it in my  
serializations. And, y'know, that's not a big problem.

It's easy enough to write a tool that normalize plain literals either  
as rdf:text or as plain literals. It's probably even greppable in RDF/ 

>  (It was not an
> issue that was discussed at length within the OWL-WG, so the bar to
> re-opening it would be fairly low, but still, we agreed to publish as
> Last Call a draft that says "...before exchanging an RDF graph with
> other RDF tools, an RDF tool that suports rdf:text MUST replace in the
> graph each typed rdf:text literal with the corresponding plain
> literal.")

I never twigged to this, and I won't make a fuss about it (there's  
enough people making enough fusses), but isn't this really a silly  
MUST? Isn't this one of those things where market pressure pretty  
obviously can handle it? And that the upgrade code is pretty trivial  
anyway? Am I missing something deep?

Doesn't a similar problem exist with xsd:string? It would be easy to  
coerce all plain literals without language tags to xsd:string  
literals. Code generally doesn't do that. But if market pressures  
shifted, it wouldn't be a big deal.

Received on Sunday, 24 May 2009 08:31:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:42:12 UTC