Re: Skolemization and RDF Semantics

On 2011-04-28, at 06:10, Pat Hayes wrote:
> 
> On Apr 27, 2011, at 10:53 AM, Richard Cyganiak wrote:
> 
>> Hi Ivan,
>> 
>> On 27 Apr 2011, at 09:12, Ivan Herman wrote:
>>> On the one hand, it is not the goal of this WG to remove blank nodes from RDF, or to change its semantics.
>> 
>> Just to be very clear: This option was never proposed or discussed anywhere in this thread. It is not an option that is on the table. We all understand that.
>> 
>>> On the other hand, it is also clear that many in the community have problems with blank node usage and, in many cases, would like to replace them with explicit URI-s, while still having the possibility to emphasize and get other tools to recognize the somewhat 'anonymous' nature of those nodes. I believe it is our job in the WG to give some guidance on how to achieve that in a proper manner. The formulation put forward by Sandro provided just that, and I think it would be a service to our community to get that in writing. Yes, it is informative, but very helpful nevertheless.
>>> 
>>> It has been raised that this should be part of, say, the Primer or the concept document. Personally, I have a preference for the latter, but that is only me.
>> 
>> +1
>> 
>>> However, we have to recognize that the .well-known 'scheme' of Sandro, as well as a urn:genid type URI require formal steps by the IETF to get those registered. In some sense, maybe the biggest service the WG could do is to get through these registrations so that the rest of the community could use those skolemization approaches (afaik, there is no similar registration for the tag: scheme if that is what we choose to use). I presume a proper document is necessary for those registrations, which is one more reason why the skolemization scheme should be part of our documents...
>> 
>> As you know, we have experience with registering .well-known prefixes (we did it for VoID), and it's fairly straightforward.
>> 
>> After last week's call, some of us spent some time on IRC trying to find a set of words that worked for everyone. The result is captured in slightly dissociated form in [1], and I'll give it here for reference:
>> 
>> | (Some intro text explaining what a skolem URI is)
>> |
>> | Systems wishing to skolemise bNodes, and expose those skolem
>> | constants to external systems (e.g. in query results) SHOULD
>> | mint a "fresh" (globally unique) URI for each bNode. Systems
>> | performing skolemisation may
> 
> I presume that is deliberately not MAY, right?
> 
>> wish to do so in a way that they
>> | can recognise the constants once skolemised, and map back to
>> | the source blank nodes where possible.
>> |
>> | Systems which want their skolem constants to be identifiable
>> | by other systems SHOULD use the .well-known URI prefix. (W3C
>> | will register an appropriate .well-known URI prefix with IANA
>> | as per RFC 5758. Details TBD.)
>> 
>> Perhaps we can hear any objections that remain to this phrasing?
> 
> 1.  It is not clear what is meant by " identifiable by other systems". Identifiable as being skolem URIs? Or in some stronger sense of 'identifiable'? If the former, I suggest the wording "identifiable by other systems as Skolem URIs" 

Yes, "identifiable as being skolem URIs", I suggest we change the wording to that.

> 2. However, I would prefer to avoid the "skolem" terminology altogether. It casts some kind of logic-jargon glow over what is really a very simple idea; it will confuse a lot of people; some other people who know what Skolemization is in FOL will be puzzled at how incomplete this simple version is; and if used, it really ought to be capitalized, as it is a direct use of the name of Theo Skolem. Which is an argument for not using it, as the capitalization use will really puzzle many people, but the non-capitalization use will offend and annoy a few people. 

Agreed.

> So how about this version:
> 
> (Intro text explaining the idea and motivation for replacing bnodes with URIs to be used as 'external' identifiers. This text could mention Skolemization in passing.)
> 
> Systems wishing to replace bNodes with URIs in this way, and expose those URis to external systems (eg in query results) SHOULD mint a new, globally unique URI for each bNode. Systems performing this replacement may wish to do so in such a way that they can recognise the URIs  and map back to the source blank nodes where possible. 
> 
> Systems which want a generated URI to be identifiable as having been introduced solely to replace a bNode SHOULD use the .well-known URI prefix....

Looks good to me.

> -----
> 3. Should we say something about whether or not these URIs should be resolvable? There is still the http-range-14 issue hanging around very near this decision, and we should at least be careful not to mislead.

I don't think we should make any recommendation about whether the URIs should be resolvable or not. It's important for some usecases, and not for others.

- 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

Received on Thursday, 28 April 2011 09:37:49 UTC