Re: Using bnode identifiers for predicates, graph names

On 02/02/2013 05:06 PM, Gavin Carothers wrote:
> It will/will not round trip with signing any more or less than bnode 
> subjects do.
> 
> Do you need to name them at all for signing? Why not sign the two 
> graphs, and combine the signings?
> 
> If you are going to be signing a graph, your going to need to create
>  a byte stream of that graph.

The example I showed is not about signing a graph, it's about signing a
dataset that includes two graphs.

If there are two graphs, you need to take the connectivity of the two
graphs into account when naming them in order to have a deterministic
outcome.

Magnet URIs are NOT a valid solution for this problem.

> If you've created a byte stream you can take a hash of it (in fact 
> your going to anyway with most signing systems) at this point you can
> create a unique URI for graph that is GLOBALLY unique to that set of
> bytes.

Yes, that's true, but it has nothing to do with the problem.

> I've mentioned this before Manu, in fact just about every time graph
>  signing comes up.

Yes, and I've mentioned that this doesn't work at all. :)

Just because a serialized array of bytes are the same DOES NOT mean that
they describe the same graph.

At present, there is no equivalent to a blank node identifier for
graphs. This decision is going to ripple through the other graph-based
serializations - JSON-LD today, and RDFa Next in a few years. The
decision made by the RDF WG means that a developer MUST name a graph
with an IRI. Which means that RDFa is going to have to force something
like this:

<div graph="#foo"> ... </div>

and won't be able to do this:

<div graph=""></div>

even though we can do this today to create a blank node:

<div about=""> ... </div>
<div typeof="schema:Person"> ... </div>

We can have blank nodes in RDF, and those nodes can refer to one
another. Why can't we have blank graphs? Why can't the content of blank
graphs refer to one another?

Blank graphs are useful because it doesn't always make sense to name a
graph with an IRI. For instance, when more than one graph is meant to be
local to a document and is not meant to be dereference-able from outside
of that document via an IRI.

Here's more background on the problem:

http://json-ld.org/minutes/2013-02-05/#topic-3

In the end, the problem manifests itself when we need to serialize an
RDF dataset to a byte-stream so that we can digitally sign it. There are
a few possible solutions:

1. Create a fragment identifier naming algorithm that effectively does
   the same exact thing that our blank-node naming algorithm does.
   That is, re-invent blank node identifiers.
2. Throw an error when somebody tries to serialize a named graph to
   RDF that doesn't have a name.
3. Introduce a new concept called the "blank graph identifier" that
   is basically a blank node identifier.
4. Rewrite what a blank node identifier can be used for - it can be
   used to name a named graph. Perhaps rename it to a
   document-local identifier (specifically, not a fragment identifier).

For this data:

[
  {
    "@context": "http://example.org/mycontext.jsonld",
    "@graph": {
       "name": "Gavin"
    }
  },
  {
    "@context": "http://example.org/mycontext.jsonld",
    "@graph": {
       "name": "Gavin"
    }
  }
]

Gavin's proposal generates this output, which is wrong:

_:bnode1 <http://schema.org/name> "Gavin" <urn:magnet:f3j28sj32189e> .

Proposal 1 above generates this:

_:c14n1 <http://schema.org/name> "Gavin" <#c14n_g1> .
_:c14n2 <http://schema.org/name> "Gavin" <#c14n_g2> .

Proposal 2 throws an error.

Proposal 3 and 4 generates some variation of this:

_:c14n1 <http://schema.org/name> "Gavin" _:c14n2 .
_:c14n3 <http://schema.org/name> "Gavin" _:c14n4 .

I think Gavin's proposal, and proposals 1 and 2 are unfortunate.
Proposal 3 and 4 seem to be a better path forward for RDF.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
President/CEO - Digital Bazaar, Inc.
blog: Aaron Swartz, PaySwarm, and Academic Journals
http://manu.sporny.org/2013/payswarm-journals/

Received on Tuesday, 5 February 2013 19:48:51 UTC