W3C home > Mailing lists > Public > public-rdf-wg@w3.org > April 2011

Re: Skolemization and RDF Semantics

From: Pat Hayes <phayes@ihmc.us>
Date: Sat, 16 Apr 2011 23:38:19 -0500
Cc: Dan Brickley <danbri@danbri.org>, David Wood <dpw@talis.com>, "public-rdf-wg@w3.org" <public-rdf-wg@w3.org>
Message-Id: <CFB6209E-E86C-4C34-90C2-0F5F177B14F9@ihmc.us>
To: Steve Harris <steve.harris@garlik.com>

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? 

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
Received on Sunday, 17 April 2011 04:38:56 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:41 GMT