Re: enforcing the prohibition

On May 22, 2009, at 1:31 PM, Axel Polleres wrote:

> Maybe I missed that in the thread, but as for defining D-entailment  
> for SPARQL, we should be fine, because we can restrict BGP matching  
> extension accordingly, right?  We can just say that graphs with  
> explicit rdf:PlainLiteral typed literals aren't well-formed.

We can say that, yes, but there is nothing in the current RDF or  
SPARQL specs that say this. So what should a conforming SPARQL/RDF  
engine do, if it comes across one? Apart from reporting it to the OWL/ 
RIF militia, that is. That is why I think having a named 'convention'  
that engines can say they support, or not, is useful. An engine which  
does can flag this as an error with a clear conscience, and its owners  
can cite the relevant W3C document when challenged, and nobody has to  
refer to OWL or RIF (inviting the response: so what, I'm not using  
those, just RDF...) Note, just saying that you support {rdf:text}- 
entailment isn't going to be enough.

Pat

>
> Axel
>
> Eric Prud'hommeaux wrote:
>> On Fri, May 22, 2009 at 09:55:03AM +0000, Seaborne, Andy wrote:
>>>
>>>> -----Original Message-----
>>>> From: public-rdf-text-request@w3.org [mailto:public-rdf-text-
>>>> request@w3.org] On Behalf Of Sandro Hawke
>>>> Sent: 22 May 2009 01:27
>>>> To: Pat Hayes
>>>> Cc: Axel Polleres; public-rdf-text@w3.org
>>>> Subject: enforcing the prohibition
>>>>
>>>>
>>>>>> One thing I am not sure still: It was pointed out that we cannot
>>>>>> prevent people from writing graphs using rdf:text as a datatype
>>>>>> explicitly.
>>>>>> Is that a problem?
>>>>> Well, I think we can very actively discourage them from doing  
>>>>> so, and
>>>>> warning them to expect trouble, and exactly what to expect, if  
>>>>> they
>>>>> do. In fact, nothing will actually break if they do, unless they
>>>>> expect these things to mean the same as plain literals without  
>>>>> using
>>>>> datatype entailment. Its more likely that they, the publishers.  
>>>>> won't
>>>>> have any problems, but some poor schmuk the other side of the  
>>>>> world
>>>>> won't get their queries answered properly. But if the spec has  
>>>>> plainly
>>>>> said this using rdf:text (or whatever) as a dataype will cause  
>>>>> these
>>>>> problems, and it does, then its going to be easy for people to  
>>>>> find
>>>>> the culprit, which I think is all that we really need to do.  
>>>>> Social
>>>>> pressure will do the rest: blogs will immediately point out that  
>>>>> XXX's
>>>>> RDF is corrupted with the forbidden datatype, etc..
>>>> I'm neutral on this option, but one more stick we *could* use is to
>>>> require RIF systems to reject RDF graphs that use rdf:text as a
>>>> datatype.
>>> This seems harsh.  "Be liberal with what you accept."
>> i have a similar conclusion, but my arguments are:
>>  1 don't add a new graph validation layer, burden for implementors.
>>  2 someone may have clever ideas for it in the future.
>>> 	Andy
>>>
>>>
>>>> RIF already does this with the rif:iri, to try to make sure
>>>> it doesn't leak out.
>>>>
>>>>     ...documents importing RDF graphs containing typed literals  
>>>> of the
>>>>     form "http://iri"^^rif:iri must be rejected.
>>>>
>>>>            -- http://www.w3.org/2005/rules/wiki/SWC
>>>>
>>>> We haven't yet added any ImportsRejectionTests to check on this,  
>>>> but we
>>>> plan to.  I don't think OWL 2 such a notion, and I wouldn't want  
>>>> to add
>>>> it just for this.
>>>>
>>>>      -- Sandro
>
>
> -- 
> 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

Received on Friday, 22 May 2009 23:47:37 UTC