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

Hi Richard,

On Fri, May 17, 2013 at 4:49 PM, Richard Cyganiak <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...)



> Best,
> Richard
>
>
> On 17 May 2013, at 14:24, "RDF Working Group Issue Tracker" <
> sysbot+tracker@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
> ,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.
> >
> >
> >
> >
>
>