Re: RDF-ISSUE-131 (mobile-datasets): How can one create an RDF dataset without being a web server? [RDF Graphs]

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