Re: A summary of the proposal for resolving the issues with rdf:text --> Could you please check it one more time?

On May 20, 2009, at 6:38 AM, Boris Motik wrote:

> Hello,
>
> I fully appreciate use case and I agree with your observation: this  
> is something
> that has to be addressed. I don't think, however, that solving this  
> problem is
> in the domain of rdf:text. The rdf:text specification merely defines  
> yet another
> datatype by specifying it in exactly the same way as this is done in  
> XML Schema.
> This datatype is just like any other XML Schema datatype; hence, the  
> job from
> rdf:text's point of view is done.

This is disingenuous. rdf:text is not 'just another datatype',  
precisely because its intended use cases interact, BY DESIGN, with  
existing deployed RDF use cases involving plain literals. That is why  
we have a problem here.

>
> Furthermore, the addition of rdf:text to the mix of the supported  
> datatypes adds
> no new conceptual problems to SPARQL: the situation with rdf:text is  
> no
> different than with, say, xsd:integer (there are other examples as  
> well). For
> example, assume that you have an RDF graph
>
> G = { <a, b, "1"^xsd:integer> }
>
> but you ask the query
>
> Q = { <a, b, "1.0"^^xsd:decimal> }.
>
> Clearly, G D-entails Q,

Actually, not, according to XML Schema, which insists that primitive  
datatype value spaces are disjoint. so the integer 1 is distinct from  
the decimal 1.0.  (I agree this can be counterintuitive, but for some  
it is obviously correct.)

> so Q should be answered as TRUE in G. It is not the
> business of XML Schema to specify how this is to be achieved: XML  
> Schema merely
> specifies what the correct answer to the above question is. It is a  
> SPARQL
> implementation such as OWLIM that should think of how to support  
> such a
> definition.
>
> I don't know whether a solution to the above problem (with  
> xsd:integer and
> xsd:decimal) exists. If not, I agree that one should be developed;  
> however, we
> would not go to the XML Schema WG and ask them to specify how should  
> SPARQL
> handle this case, would we?
>
> The problem with rdf:text is *precisely* the same as the one that I  
> outlined
> above.

The differences are (1) that in the case of integer vs. decimal, the  
question of identity is somewhat debatable (see above), (2) this  
particular issue is well-known and has been around for many years  
(strongly typed inference systems such as Kestrel routinely  
distinguish natural, integer, real and complex values, so they have  
four distinct zeros) so users may be expected to be aware of it,  
whereas having two distinct forms for something as obvious as a  
character string is unprecedented; and (3) integer/decimal only arises  
when one is already assigning types, whereas this issue comes up when  
people are using plain literals which are not considered to even have  
a type, so this issue impacts simple RDF inference systems, which are  
just about all RDF systems.

> At an abstract level, it can be stated as "Several syntactic forms of
> literals get mapped to the semantically identical data values". AS  
> demonstrated
> above, this problem exists without rdf:text, so I don't see how  
> rdf:text brings
> anything new into the whole picture. Thus, you can apply to the  
> rdf:text case
> exactly the same solution that you would apply to xsd:integer and  
> xsd:decimal.
> If such a solution doesn't exist yet, then the SPARQL WG should  
> address these
> issues, and it should do so in general for all datatypes (xsd:integer,
> xsd:decimal, and so on), not just for rdf:text.
>
> To summarize, I think that the work from the point of view of the  
> rdf:text WG is
> *done* and that we should not do anything else in this forum.

This is exactly the 'not my business' attitude that creates  
interoperability problems. We should all - that is, all WGs - try as  
best we can to be sensitive to issues that we create for other WGs and  
standards, and try to minimize potential conflicts. We aren't doing  
house-cleaning here, each in our own private little group.

Pat

>
> Regards,
>
> 	Boris
>
>> -----Original Message-----
>> From: Eric Prud'hommeaux [mailto:eric@w3.org]
>> Sent: 20 May 2009 13:18
>> To: Boris Motik
>> Cc: 'Seaborne, Andy'; 'Alan Ruttenberg'; public-rdf-text@w3.org;  
>> 'Sandro
>> Hawke'; 'Axel Polleres'
>> Subject: Re: A summary of the proposal for resolving the issues  
>> with rdf:text
>> --> Could you please check it one more time?
>>
>> On Wed, May 20, 2009 at 09:29:00AM +0200, Boris Motik wrote:
>>> Hello,
>>>
>>> I don't see the benefit of option 1, as it makes things  
>>> unnecessarily
>> complex.
>>> The fewer exceptions we have, the easier it will be to actually  
>>> implement a
>>> conformant system. The dichotomy between plain und typed literals  
>>> is just an
>>> example of an exception that just makes implementation difficult.  
>>> Instead of
>>> introducing more special cases, I think we should unify these  
>>> whenever
>> possible.
>>>
>>> Furthermore, I'm not sure whether sorting out things such as the  
>>> ones
>> pointed
>>> out below is necessary to finalize the rdf:text specification.  
>>> Please note
>> that
>>> rdf:text already has a well-defined lexical and value space, and  
>>> this is
>> *the
>>> only* thing that we need to be able to plug rdf:text into the  
>>> model theory
>> of
>>> RDF. That is, given RDF graphs G1 and G2 possibly containing  
>>> rdf:text
>> literals
>>> and/or plain literals, using the definitions from the present  
>>> rdf:text
>>> specification one can unambiguously answer the question whether G1  
>>> D-entails
>> G2.
>>> For example, if G1 is
>>>
>>> <a, b, "abc@en"^^rdf:text>
>>>
>>> and G2 is
>>>
>>> <a, b, "abc"@en>
>>>
>>> then, according to the existing RDF model theory document, G1 D- 
>>> entails G2
>> and
>>> vice versa. I don't see what else is there for the rdf:text  
>>> specification to
>> do:
>>> I really think that the specification is complete. If SPARQL or  
>>> other
>>> specifications want to apply rdf:text in a different way and  
>>> create special
>>> cases, they are free to do so; however, I don't think it is in  
>>> scope of the
>>> rdf:text specification to solve all such problems.
>>
>> (Hesitantly re-stating use case), consider the use case of the OWLIM
>> plugin for Sesame. If OWLIM forward chains some triples into the
>> Sesame repository with objects like "bob"@en, existing SPARQL queries
>> on the existing Sesame engine will match them as expected. RIF rules
>> can consume those triples and know that any rules applying to a  
>> domain
>> of rdf:text apply.
>>
>> Constrast that with an OWLIM which emits triples with objects like
>> "bob@en"^^rdf:text . These triples will not match conventional  
>> queries
>> intended to discover e.g. all the folks named "Bob". The Sesame  
>> SPARQL
>> implementation can be extended, but then we are in Pat's scenario of
>> fixing RDF by visiting all the deployed code.
>>
>> I expect that any design of rdf:text would have it reacting to plain
>> literals as if they had a datatype of rdf:text and the appropriate
>> lexical transformation. I propose that the simplest complete design  
>> is
>> one where the inference of rdf:text objects results in their
>> expression as plain literals, avoiding a dualism between
>> "bob@en"^^rdf:text and "bob"@en which would lose interroperability
>> with existing queries, graph APIs, XPaths operating on SPARQL  
>> Results,
>> non-OWL inferencing systems, ...
>>
>>
>>> Regards,
>>>
>>> 	Boris
>>>
>>>> -----Original Message-----
>>>> From: public-rdf-text-request@w3.org [mailto:public-rdf-text-
>> request@w3.org]
>>>> On Behalf Of Eric Prud'hommeaux
>>>> Sent: 20 May 2009 03:18
>>>> To: Seaborne, Andy
>>>> Cc: Alan Ruttenberg; public-rdf-text@w3.org; Boris Motik; Sandro  
>>>> Hawke;
>> Axel
>>>> Polleres
>>>> Subject: Re: A summary of the proposal for resolving the issues  
>>>> with
>> rdf:text
>>>> --> Could you please check it one more time?
>>>>
>>>> On Tue, May 19, 2009 at 03:57:11PM +0000, Seaborne, Andy wrote:
>>>>> Apologies:
>>>>>
>>>>>> On Fri, May 15, 2009 at 11:50 AM, Seaborne, Andy
>> <andy.seaborne@hp.com>
>>>> wrote:
>>>>>>> Monday PM end before 18:00 (GMT+1)
>>>>>>> Thursday PM.
>>>>>>> Tuesday @17:00 (GMT+1) for a short call; end before 17:30.
>>>>>
>>>>> I can't make the slot.
>>>>>
>>>>> Input: please consider interoperability of data between OWL and  
>>>>> RDF.
>> Option
>>>> 1 is better for that than option 2 as Eric points out.
>>>>>
>>>>> This is also the least change to LC and IMHO is not a  
>>>>> substantive change
>> (it
>>>> follows on from the current graph exchange intent) to add the  
>>>> text needed
>> for
>>>> SPARQL.  Roughly: the scoping graph of an rdf-text aware D- 
>>>> entailment for
>> BGP
>>>> matching includes the RDF forms and does not include ^^rdf:text.   
>>>> (Non-
>> aware
>>>> entailment regimes would merely treat as a datatype form.)
>>>>
>>>> does anyone oppose option 1 (plain literals are considered to  
>>>> satisfy
>>>> entailments constrained to type rdf:text and entailments of type  
>>>> rdf:text
>> are
>>>> expressed as plain literals in the RDF graph)? (i'm wondering if  
>>>> we can
>> work
>>>> this out before we work out scheduling this phone call.)
>>>>
>>>>
>>>>> 	Andy
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Alan Ruttenberg [mailto:alanruttenberg@gmail.com]
>>>>>> Sent: 19 May 2009 16:01
>>>>>> To: Axel Polleres
>>>>>> Cc: Seaborne, Andy; public-rdf-text@w3.org; Boris Motik; Sandro  
>>>>>> Hawke;
>>>>>> eric@w3.orf
>>>>>> Subject: Re: A summary of the proposal for resolving the issues  
>>>>>> with
>>>>>> rdf:text --> Could you please check it one more time?
>>>>>>
>>>>>> On Mon, May 18, 2009 at 10:03 AM, Axel Polleres
>> <axel.polleres@deri.org>
>>>>>> wrote:
>>>>>>> Alan, since you were calling for the TC, is that fixed now?
>>>>>>> Otherwise, I am afraid it is not possible before Friday.
>>>>>>
>>>>>> Yes, let's have whoever can make it meet at 5:30 BST = 12:30  
>>>>>> Boston
>>>>>> time.
>>>>>> Zakim, meet on irc #rdftext for the code. I will send a code  
>>>>>> earlier
>> if
>>>>>> I can.
>>>>>>
>>>>>> -Alan
>>>>
>>
>> --
>> -eric
>>
>> office: +1.617.258.5741 32-G528, MIT, Cambridge, MA 02144 USA
>> mobile: +1.617.599.3509
>>
>> (eric@w3.org)
>> Feel free to forward this message to any list for any purpose other  
>> than
>> email address distribution.
>
>
>
>

------------------------------------------------------------
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, 20 May 2009 16:28:09 UTC