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

Re: Skolemization and RDF Semantics

From: Richard Cyganiak <richard@cyganiak.de>
Date: Wed, 27 Apr 2011 17:51:02 +0100
Cc: "RDF-WG public-rdf-wg@w3.org" <public-rdf-wg@w3.org>
Message-Id: <1C8D3EC6-ADCE-4642-A1CE-09BB5A3090A5@cyganiak.de>
To: Ivan Herman <ivan@w3.org>
On 27 Apr 2011, at 17:28, Ivan Herman wrote:
> | (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 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.)
> - do we stick to .well-known/genid, or do we want to use other terms instead of genid (there were some discussion about that)

Personally I'm a fan of .well-known/skolem :-) Obscure, but once you know what they are, you'll recognize them. genid is too boring. bnode confuses some people.

> - do we want to also have a non-http versions of the URI-s that are likely to be more readable. The tag: scheme came up (though that is not necessarily more readable) or the urn:genid: version. 

Personally I'm -0 on that. The phrasing above leaves open the possibility of using any other type of URI, including tag: or urn:uuid:.

We should maybe add something like, “Systems MAY make the .well-known URIs resolvable.” This would make clear that, despite being http: URIs, they may or may not resolve.

> Tracker, this is relevant for ISSUE-40

Thanks! Somehow there seems to be a duplicate of that issue now, with number 41?

Received on Wednesday, 27 April 2011 16:51:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:06 UTC