- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Thu, 23 May 2013 09:33:31 +0100
- To: RDF-WG <public-rdf-wg@w3.org>
On 22/05/13 22:48, Pierre-Antoine Champin wrote: > Hi Richard, > > On Fri, May 17, 2013 at 4:49 PM, Richard Cyganiak <richard@cyganiak.de > <mailto:richard@cyganiak.de>> wrote: > > I'm not really sure why RDF-WG is spending time on this issue at > all. As Sandro's research shows, there are several adequate ways of > addressing this already. (Personally I find option 3 particularly > elegant, and don't find that it contradicts any spec I know of. Yes, > protocols that want to use URI-bearing payloads should define how a > base URL can be established for a given payload. If a protocol > doesn't do that, then consumers have to make up a base. That doesn't > break anything, as long as the consumer re-serialises everything > using relative URIs again.) > > > You are right, concrete syntaxes of RDF are allowed to use relative URIs > (and so, why not as graph identifies as well). > However, the abstract syntax does not allow them; so working at the > abstract level, one has to deal with absolute URIs only. > > If then they want to produce a concrete syntax that is base-less (i.e. > leave it to the consumer to decide on the bas eURI), they have to rely > on the serializer to remove *all* occurences of the base URI. Do you > know any implementation that provides that kind of guarantee? I don't. > > So if we want to advocate the use of base-less serializations, I think > we should have RDF-concept saying something in the line of: > > In some situations, it is desirable to produce a serialization of an RDF > graph (or dataset) where relative URIs are used and their base URI is > left unspecified, so that the consumer may decide on the base URI to > apply. To allow to produce such a base-less serialization from an > abstract RDF graph, a serializer must accept a base URI and provide a > way to guarantee that 1/ all URIs that can be made relative to the base > will be made so, and that 2/ no mention of the base URI will appear in > the serialization (e.g. in turtle, @base will not be used). > > I'm not saying that this should be made normative, but it is a hint to > implementers that this is a desirable feature. And LDP will need it too, > according to how POST is specified [1]. > > pa > > [1] http://lists.w3.org/Archives/Public/public-ldp-wg/2013Mar/0077.html > > PS: Note that I'm not a big fan of this way of using an "artificial" > base URI on the producer side, just for the sake of producing a > base-less serialization... but if we want to promote base-less > serializations (and I too see the elengance you find to it), I only see > two other ways, and they are worse: > > * working directly at the concete syntax level (which negates the whole > point of having an abstract syntax, IMO) > * re-defining the abstract syntax to allow relative URIs in some graphs > (base-less graphs?) (which is out of our charter, I think, not too > mention way too late to be feasible...) Better to think of these base-less syntax form as a template for some RDF, and not RDF itself. Andy > > > > Best, > Richard > > > On 17 May 2013, at 14:24, "RDF Working Group Issue Tracker" > <sysbot+tracker@w3.org <mailto:sysbot%2Btracker@w3.org>> wrote: > > > RDF-ISSUE-131 (mobile-datasets): How can one create an RDF > dataset without being a web server? [RDF Graphs] > > > > http://www.w3.org/2011/rdf-wg/track/issues/131 > > > > Raised by: Sandro Hawke > > On product: RDF Graphs > > > > In general, the SPARQL definition of datasets (adopted into RDF > 1.1 by WG resolution on 29 October 2012) satisfies our charter > deliverable of allowing people to work with multiple graphs. > However, it requires that each graph be labeled with an IRI, and > creating such an IRI can be problematic. > > > > It's easy enough for software to make up IRIs for graphs if it > happen to be a web server, in charge of some range of web addresses. > But how can other software do this? For instance, how can a web > client create a dataset to send as one of several parameters in an > HTTP POST operation? And how can a web client use datasets for > HTTP PATCH (as the LDP Working Group wants to do). And how can > something use datasets in a UDP or TCP based protocol? > > > > At the moment, a few options come to mind: > > > > Option 1 - Use RFC-4122 Random UUIDs as graph names. These are > IRIs that look like urn:uuid:7a745845-5a5e-46ad-9ae7-6ec202741183, > where the hex parts are 118 random bits, and 10 fixed bits. In > theory, collision is unlikely if a good source of randomness is > available. Perhaps the randomness can be improved by including a > hash of the other parts of the dataset. Note that use of > non-resolvable IRIs like this is bad practice for Linked Data. > > > > <urn:uuid:7a745845-5a5e-46ad-9ae7-6ec202741183> { ... contents > of graph ... } > > > > Option 2 - Use a UUID-like string as an IRI base or prefix for > graph names. (Slight variation on Option 1.) By going outside the > RFC-4122 syntax, we can include a "local part" in the IRI. > Something like: > > > > @prefix my: <tag:w3.org > <http://w3.org>,2013:uuid:7a745845-5a5e-46ad-9ae7-6ec202741183:> > > ... > > my:g2 { ... contents of graph 2 ... } > > > > Option 3 - Use a "relative" dataset, where the graph names are > written as relative IRIs but the base for IRI-resolution is not > known to the system generating the dataset and is assigned to some > new, unique IRI base by each receiver. This is arguably not > licensed by the current RDF drafts or the SPARQL 1.1 spec. Some > client libraries will not store or serialize RDF with relative IRIs. > > > > <#g3> { ... contents of graph 3 ... } > > > > Option 4 - Use blank nodes as graph names. This is not allowed > in Datasets as defined in the current RDF drafts or the SPARQL 1.1 > spec. Some client libraries will not store or serialize RDF > datasets with blank node graph names. As with other uses of blank > nodes, knowing they cannot be referenced by other documents allows > certain optimizations, and they can be Skolemized for use in systems > that do not want/allow blank nodes. > > > > _:g4 { ... contents of graph 4 ... } > > > > Option 5 - Do not directly support this use case in RDF 1.1. > Instead, require systems to use an extended RDF which allows blank > node graph names, eg JSON-LD, or variations on TriG and N-Quads > which may arise for this purpose. > > > > > > > > > >
Received on Thursday, 23 May 2013 08:35:12 UTC