Re: regrets and last input for the call...

Ive put a straw-man draft of the style Ive been rooting for here:

http://www.ihmc.us/users/phayes/IntStringSpec052609.html

This is a direct edit from the source of Boris' most recent draft from  
the wiki, at   http://www.w3.org/2007/OWL/wiki/InternationalizedStringSpec 
.  Ive highlighted the additions and  used strikeout rather than  
deletion (sorry, I'm not diff-savvy enough to do it the kosher way.)  
To get rid of the highlighting, search in the source for "HILITE"

Basically it takes the MUST NOT stuff from section 4 and moves it to a  
new section 6, which explicitly describes the semantic extension,  
using MUST NOT language; and then in section 4 it says: use that  
extension, but with SHOULD language. This gives people some  
flexibility to make their own choices and live with them, but it asks  
them to be clear about what they are doing, and gives them a name to  
say it, and to tell others.

To make this work, OWL and RIF should then use MUST language, and  
refer to this extension, when talking about RDF encoding. The two  
MUSTS add up to a strict prohibition of rdf:PlainLiteral leakage.

I thought of a few illustrative entailments, but if anyone can think  
of a good OWL illustration, I'd be grateful. It seems kind of silly to  
use an OWL 1 example when the whole point is for OWL 2.

AFAI can see, there would be no need for SPARQL to do or say anything,  
though it might be good to add some warnings about trying to use  
SPARQL to query non-plain-typed RDF graphs.

---------

BTW, we now have a new open RDF issue: are rdf:XMLLiteral and  
rdf:PlainLiteral disjoint?  Is this a new RDF inconsistency:

_:x rdf:type rdf:PlainLiteral .
_:x rdf:type rdf:XMLLIteral .

I can see arguments both ways, but I think we ought to decide it and  
give a ruling, rather than just let the matter dangle so that people  
will do it various ways. It seems more useful to say they are  
disjoint, even though valid XML is still perfectly correct as a  
character string. And Ive heard it argued that marked-up text is still  
not plain text, even when it has no markup. I guess it kind of smells  
different, or something.

-----------

Another question: do we want to provide a way **in RDF** to talk about  
the lang tags directly? That is, should the extension provide for RDF  
properties to support entailments like these:

aaa ppp "this"@that .

??entails??

aaa ppp _:x  .
_:x rdf:hasString "this"  .
_:x rdf:hasTag  "that"  .

The reason I ask is, if people think this might be useful (seems to me  
it would be) then now is surely the time to define them, as part of  
the overall convention.

No doubt their names should be chosen better, but Im sure y'all see  
the point.

Pat

--------

On May 26, 2009, at 3:08 PM, Pat Hayes wrote:

>
> On May 26, 2009, at 1:50 PM, Axel Polleres wrote:
>
>> As I can't join the call, here some last input for word-smithing...
>>
>> At a second read... what I just committed reads strange:
>>
>> >> Maybe (intro): """ ...typed rdf:text literals MUST NOT occur in
>> >> published RDF content or in the results of SPARQL basic graph  
>> pattern
>> >>  matching [SPARQL] using extended SPARQL Basic Graph Matching"""
>>
>> I won't object against it, but how about rather:
>>
>> "In order to prevent interoperability problems between RDF  
>> processors that support rdf:text and those that do not, typed  
>> rdf:text literals in published RDF content MUST NOT be generated by  
>> RDF processors, such as APIs, or SPARQL engines that implement  
>> SPARQL basic graph pattern matching [SPARQL] using extended SPARQL  
>> Basic Graph Matching;"
>>
>>
>> Would that go?
>>
>> I think we simply can't reasonably forbid that anyone "publishes"
>> rdf:text literals... just as e.g. ill-typed xs:integer literals  
>> can't be forbidden. (and ill-typed literals already *do* occur on  
>> the Web... )
>>
>> I.e., if I publish today
>>
>> :axel :likes "foo"^^xs:integer.
>>
>> that is totally ok with RDF. It might not be wise, but well.
>
> Right, exactly. But if we say explicitly that we are defining a  
> (tiny) semantic extension to RDF, then we can say that it - this  
> extension, call it "plain typed RDF" for want of a better name -  
> comes with a strict syntax prohibition against literals like this.  
> And then a SPARQL engine can declare that it will only deal with  
> plain typed RDF graphs, which conform to the restriction, and reject  
> those that don't (or give wrong answers on them, or whatever.) OWL  
> and RIF can say that their engines are required to use only plain  
> typed RDF, as part of their normative specs, and current RDF  
> publishers can just say, yes, they too are conforming to it, and go  
> on doing exactly what they have always done, without changing a  
> single character in any current RDF file. All we have to do, is give  
> this new revized RDF (which comes along with the MUST NOT applied to  
> these typed literals) a name. We can strongly recommend that people  
> use it "rather than" old RDF, but that's up to them. Social  
> pressures to conform will likely fix any problems quite quickly,  
> provided there is an accessible and quite unambiguous spec document  
> to point people to.
>
>> Likewise, I also can publish complete nonsense in terms of OWL and  
>> nobody can prevent that [1]
>>
>> In that light... saying that publishing
>>
>> :axel :likes "bar"^^rdf:PlainLiteral.
>>
>> is something that MUST NOT be done, I have the feeling that is  
>> overshooting
>
> I think its impossible, strictly speaking. It amounts to  
> retrospectively re-writing the RDF specs, and I don't see that the  
> W3C has any mechanism for doing that. Even OWL 2 doesn't actually  
> change OWL 1.
>
> Pat Hayes
>
>> Still, I think we can and should prevent systems to generate such  
>> thing. I would thus prefer the rewording suggested above.
>>
>>
>> Best regards,
>> Axel
>>
>> 1. http://axel.deri.ie/~axepol/nasty.rdf
>>
>>
>> xel Polleres wrote:
>>> Seaborne, Andy wrote:
>>>> Boris,
>>>>
>>>> The text talks about "in a SPARQL basic graph pattern" - that  
>>>> could be read as what goes in to matching (i.e. part of the  
>>>> PSARQL query syntax. It needs to refer to the results of matching  
>>>> a BGP (what comes out of matching).
>>>>
>>>> (I'm not worried about use of rdf:text in a BGP)
>>>>
>>>> Maybe (intro): """ ...typed rdf:text literals MUST NOT occur in  
>>>> published RDF content or in the results of SPARQL basic graph  
>>>> pattern
>>>> matching [SPARQL] using extended SPARQL Basic Graph Matching"""
>>>> *in the result of* is the key here.
>>> I implemented it:
>>> * SPARQL reference added
>>> * your suggested text added.
>>> http://www.w3.org/2007/OWL/wiki/index.php?title=InternationalizedStringSpec&diff=24147&oldid=24140 
>>>  Is the document in that form acceptable?
>>
>> At a second read... that is strange.
>> As I can't come tomorrow, here some last input for word-smithing...
>>
>>
>>
>> -- 
>> Dr. Axel Polleres
>> Digital Enterprise Research Institute, National University of  
>> Ireland, Galway
>> email: axel.polleres@deri.org  url: http://www.polleres.net/
>>
>>
>>
>
> ------------------------------------------------------------
> 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
>
>
>
>
>
>
>
>

------------------------------------------------------------
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 Wednesday, 27 May 2009 13:58:53 UTC