Re: simple fix

On May 21, 2009, at 7:19 PM, Sandro Hawke wrote:

>>>> Can't we just say, as strongly as we need to, that rdf:text is NOT
>>>> for use in RDF?
>>
>> Too strong. All we need is that its not for use as the datatype URI  
>> in
>> an RDF typed literal. It would be fine to allow RDFS to reason about
>> the class, for example. Yes, that is pretty much what my earlier
>> suggestion amounts to, in practice.
>
> Yes, I didn't think of that case, but indeed, I did mean that rdf:text
> is not for use in RDF as an RDF datatype URI.
>
> I'm hoping that by explaining what rdf:text is *for* we can make this
> more obvious.  I'm imaging text in the intro like:
>
>    Systems which support XML datatypes but do not directly support RDF
>    can use rdf:text to represent RDF Plain Literals.  The mapping is
>    1-to-1, so such systems can do their processing of XML data values
>    and effectively be processing RDF data values.
>
>> On another topic, the more I think about it, the better the idea gets
>> of sticking to xsd:string for untagged literals and using rdf:text
>> only for tagged ones. This seems to lead to a simplification in the
>> spec for handling all the alternative function definitions as well.
>
> I find that very appealing, but I think there's a fatal problem with  
> it,
> which is that these two RDF graphs are not the same:
>     <a> <b> "Hello".
> and
>     <a> <b> "Hello"^^xs:string.
>
> If we did this simplification you're suggesting, then in the rdf:text
> form we could no longer distinguish between the above two triples, and
> if we converted back to RDF, we'd have altered the graph.

Don't we have this problem anyway? Oh, I see: not if we actually  
**prohibit** rdf:text typing.

>  The mapping
> would not longer be 1-to-1.  Not a huge pain for users, but still, I
> think, and unnecessary incompatibility.
>
> (Of course I *wish* those two RDF graphs were the same, but, alas.  I
> rather think xs:string should have been banned as a datatype from RDF,
> for the same reason we're banning rdf:text.  But I guess it's too late
> to do that now.

Yup. And also, there was prior art for the XSD usage, but we are  
inventing rdf:text ourselves, so we need a much better excuse :-)

>  Maybe someone, somehow, can make a Best Practice
> declaration against using xs:string?  Hmmm.  I wonder if the reason  
> some
> people use xs:string is because they want to process their RDF without
> implementing Plain Literals, and they don't have any language tags....
> In that case, it's germaine for rdf:text spec to mention that there is
> now one less reason to use xs:string at all, and maybe people should
> just avoid it in RDF.  I know that's a stretch.  xs:string probably  
> has
> some big fans out there, and it's best for rdf:text not to anger  
> them.)

Well, yes, but more generally we really ought to not be legislating  
this one way or the other, ideally. I can see that in a possible  
future RDF world, every literal has a type and this whole issue is as  
archaic as arguing about the merits of binary coded decimal. But maybe  
Microsoft will produce the killer SWeb app using plain literals, and  
that will end the debate the other way. No way to know, really.

In that draft, Ive made the use of the datatype a syntax error, no  
compromise, but we could just use SHOULD NOT everywhere and tell  
people what will break if they do (mixed use will give query losses  
unless you use a special D-entailment; round-tripping will change  
graphs; there will be information loss.) I actually prefer that, but I  
bet it will be less popular. People don't want freedom, they want  
clarity.

Pat

>
>     -- Sandro
>
>

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Friday, 22 May 2009 00:36:22 UTC