Re: Skolemization and RDF Semantics

On Apr 17, 2011, at 1:58 AM, Ivan Herman wrote:

> 
> On Apr 17, 2011, at 06:38 , Pat Hayes wrote:
> 
>> 
>> On Apr 16, 2011, at 9:46 AM, Steve Harris wrote:
>> 
>>> On 2011-04-15, at 20:35, Dan Brickley wrote:
>>> 
>>>> On 15 April 2011 21:29, David Wood <dpw@talis.com> wrote:
>>>>> Hi all,
>>>>> 
>>>>> Ivan and IIRC Steve or Richard tried to convince me that Skolemization is already mentioned and allowed in the 2004 version of the RDF Semantics.  I can't find it.  Can someone please enlighten me?  Thanks.
>>>> 
>>>> http://www.w3.org/TR/rdf-mt/#prf
>>> 
>>> This section also contains the text which means it's not currently OK (by my reading) to expose skolem constants to the outside world:
>> 
>> No, the cited passage does not imply that. I am at a loss to see how you think it can be interpreted that way. 
>> 
>>> “Intuitively, this lemma shows that asserting a Skolemization expresses a similar content to asserting the original graph, in many respects. However, a graph should not be thought of as being equivalent to its Skolemization, since these 'arbitrary' names would have the same status as any other URI references once published. Also, Skolemization would not be an appropriate operation when applied to anything other than the antecendent of an entailment.”
>>> 
>>> There's some more context too.
>>> 
>>> Interestingly it also touches on the issue of being able to identify URIs that are skolem constants, here's a quick summary of the issues in that area:
>>> 
>>> SPARQL stores which skolemise on export need to be able to identify their own skolemised bNodes so they can correctly handle SPARQL Query/Update operations which use them.
>> 
>> Can you (or anyone) explain this point more carefully? What exactly is a "SPARQL store" ? Is this simply RDF, or does it have more structure? What exactly does it mean for a SPARQL store to "export"? If this simply publishing RDF, or does it have a SPARQL-specific meaning? And if so, what is it exactly? 
> 
> I believe what Steve meant, by 'export', simply the SPARQL query return results. 
> 
> <a> <b> _:x .
> 
> query:
> 
> SELECT ?z WHERE { <a> <b> ?z }
> 
> if the store decides to skolemize on return the blank node _:x, it is good if the skolemization is such the the store can recognize its own, so it can make sense of a subsequent
> 
> INSERT { <WHATEVERCAMEBACKFOR?z> <p> <q> . }
> 
> I guess, at least, that is what he meant:-)

Ah, OK. That makes sense, thanks. I think this would be covered by the 'who owns the URI' rule I suggested, BTW; In this case, the SPARQL engine owns the URIs, so it has the responsibility of making sense of them in the future. 

FWIW, I would suggest that it would be bad design to send back skolemised results without first skolemising the actual data the results were derived from. But that is only a suggestion :-)

Pat


> 
> Ivan
> 
> 
>> 
>> Pat 
>> 
>>> 
>>> Based on previous experience, a genid: URI scheme or similar will be extremely slow to register, and would hold up any recs. which reference it, probably beyond the life of the WG. It may be possible to register a URN NID, but I don't know how practical that is either. 
>>> 
>>> There's an IETF spec for /.well-known/$id URI prefixes, but some people who want to make their skolem constants resolvable, don't want to be forced to use this prefix for their resolvable bNodes, and it makes even non-resolvable skolem constants quite verbose.
>>> 
>>> My suspicion is that the only way forward would be some text along the lines of: [with apologies for any abuse of terminology]
>>> 
>>> Systems wishing to skolemise bNodes, and expose those skolem constants to external systems (e.g. in query results) SHOULD mint fresh a "fresh" (globally unique) URI for each bNode.
>>> 
>>> All systems performing skolemisation SHOULD do so in a way that they can recognise the constants once skolemised, and map back to the source bNodes where possible.
>>> 
>>> Systems which want their skolem constants to be identifiable by other systems SHOULD use the .well-known URI prefix.
>>> 
>>> - Steve
>>> 
>>> -- 
>>> Steve Harris, CTO, Garlik Limited
>>> 1-3 Halford Road, Richmond, TW10 6AW, UK
>>> +44 20 8439 8203  http://www.garlik.com/
>>> Registered in England and Wales 535 7233 VAT # 849 0517 11
>>> Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
>>> 
>>> 
>>> 
>> 
>> ------------------------------------------------------------
>> 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
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> PGP Key: http://www.ivan-herman.net/pgpkey.html
> FOAF: http://www.ivan-herman.net/foaf.rdf
> 
> 
> 
> 
> 

------------------------------------------------------------
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 Sunday, 17 April 2011 07:06:40 UTC