- From: Sandro Hawke <sandro@w3.org>
- Date: Wed, 20 Apr 2011 10:58:18 -0400
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- Cc: public-rdf-wg@w3.org
On Tue, 2011-04-19 at 11:15 +0100, Andy Seaborne wrote: > > On 19/04/11 10:19, Steve Harris wrote: > > On 2011-04-18, at 21:37, David Wood wrote: > > > > > Please see: > >> > >> http://www.w3.org/2011/rdf-wg/wiki/Meetings:Telecon2011.04.20 > > > > I think it's worth appending Sandro's description of the .well-known > > prefix to the skolemisation proposal. > > > > I left it outto save space, and because it was fresh in most people's minds anyway. > > You had to be there! > > > > > - Steve > > > > Trying to be clear about the details for myself, I gathered together the > emails and minutes: > > Final proposal from the minutes 14/April: > > ---------------- > > PROPOSED: If systems are going to reveal Skolemized bnodes, without > doing damage to the graph, they MUST use a fresh URI (per bnode) and Note that the language about "fresh URI" was added late in the discussion and I don't really like it since its redundant -- that's what Skolem terms are (fresh), by definition. > SHOULD follow the form > http[s]://[domain]/.well-known/genid/[locally-uniq-id][#] > or > tag:[domain],[year]/.well-known/genid/[locally-unique-id] > (or, someday, genid:...). Such IRIs are considered more disposable. > > "genid" to be reg'd with IETF. > > ---------------- > > Observations: > > 1/ Why is > http://host.com/.well-known/genid#1816 > excluded? An error. > 2/ The authority is not optional in http URIs (RFC 2616 sec 3.2.2). I was typing this during the meeting and ended up overloading a made-up template syntax and BNF syntax. I'm still not sure the right way to say this in ASCII. The [s] meant the "s" was optional; the [domain] meant that a domain name went there. (really an authority, yes.) > A skolemized bNode might look like: > > http://host.com/.well-known/genid/cb48cfae-6a5d-11e0-ba3a-00270e03441 > > (that's using a version 1 UUID) > > tag: can be used when machines don't know their own external name (e.g. > on a 10.* network). > > > Subsequent email (key parts): > > On 16/04/11 15:46, Steve Harris wrote: > > > 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 > > On 16/04/11 18:51, Steve Harris wrote: > > We will have to register the "genid" .well-known tag in any case, > > and tag: might have to be amended to say that .well-known is reserved > > there too. No need to amend tag:, just us a tag like tag:w3.org,2001:bnode:[uuid-or-whatever] > On 16/04/11 23:27, Pat Hayes wrote: > > It is not enough that *they* can so recognize it. It needs to be > > globally recognizable by any system that has access to the > > specifications. We need to specify how this can be done. > > > I don't worry about dereferencability so prefer "genid:" -- currently > provide support for <_:...> to put bNodes in a different space to URIs > while reusing/abusing the syntax. A key point about this proposal is that some people want dereferenceability and some don't, so to move forward I think we need to allow for both. So folks who want to use http/https can, and folks who want to use a non-referenceable scheme (genid:/tag:/bnode:/urn:bnode:) also can. -- Sandro > Andy > > FYI: > > Registry for well-known: > http://www.iana.org/assignments/well-known-uris/well-known-uris.xml > > Registration list: > http://www.ietf.org/mail-archive/web/wellknown-uri-review/current/maillist.html > > >
Received on Wednesday, 20 April 2011 14:58:28 UTC