Re: Using bnode identifiers for predicates, graph names

On 02/02/13 18:31, Manu Sporny wrote:
> On 01/31/2013 06:41 AM, Sandro Hawke wrote:
>> How is using bnodes to identify graphs any more absurd than using
>> them to identify people (the canonical example)?    Blank nodes make
>> prefect logical sense as local (file scope) identifiers.   They are
>> clearly useful.

bnodes don't identify people : bnode + IFP or bnode + some properties 
identify.

[] foaf:name  "Andy" .

is not uniquely me.  It can be anyone called "Andy"

>>
>> I'll agree with Andy's point, however, that this ship has already
>> sailed.   While blank nodes are fine in any position in generalized
>> rdf, they are not okay for predicates or graph names in standard
>> rdf.
>
> Alright, so the direction from the group is clear.
>
> That creates a problem with normalization of JSON-LD (and really, any
> normalization of any RDF graph that doesn't specify an IRI as a name).
>
> Assume that we have the following JSON-LD document, containing two
> "anonymous" graphs:
>
> [
>    {
>      "@context": "http://example.org/mycontext.jsonld",
>      "@graph": {
>         "name": "Sandro"
>      }
>    },
>    {
>      "@context": "http://example.org/mycontext.jsonld",
>      "@graph": {
>         "name": "Pat"
>      }
>    }
> ]

Tangent: how do you know that is 2 graphs, and not 2 fragment of one graph?

> We need to digitally sign the document via the RDF Graph Normalization
> algorithm and generate something like this to digitally sign:
>
> _:bnode1 <http://schema.org/name> "Pat" _:graph1 .
> _:bnode2 <http://schema.org/name> "Sandro" _:graph2 .

How do you sign the document with bnode subjects and objects without the 
same issue? (presumably by label and a deterministic allocation).

(the Normalization document isn't REC track is it?)

> However, now we can't name it _:graph1, or anything else like that,
> right?

Internally (within a JSON LD processor), you can call them "graph1" and 
"graph2" if you want does not have to a bnode, bnode label, string or 
even RDF thing of any kind.

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 order matters (and then it's not an RDF Dataset anyway), add a 
counter to the combine step

Is it different to the same doc with the graphs reversed in the JSON 
array?  use case?

> So we need to come up with another naming scheme that is
> deterministic and it needs to match an IRI. It seems kind of strange to
> introduce a mechanism for something that is already basically there.

This seems to be the heart of it : bnodes don't match an IRI (see above)

You seem to want more than document scoped labels - you want labels that 
are stable across multiple parses of the document.

> Even stranger, the IRI that will be generated will inevitably conflict
> with some other normalized graph IRI because it isn't scoped to the
> document. These identifiers need to be scoped to the document if the RDF
> graph normalization algorithm is going to work fairly cleanly.
>
> Could we introduce the concept of a 'blank graph identifier'?

Sure - (1) create your own URI scheme or (2) a systematic way to 
generate UUIDs based on doc and position of the graph in the doc

> This is time critical for us. We are in the process of launching a
> financial product that uses 'blank graph identifier's for graph IDs when
> normalizing to perform a digital signature. This has the potential for
> delaying that launch. We really need to iron out this issue pretty soon.

It is time critical for RDF-WG as well :-)

>
> -- manu
>

 Andy

Received on Saturday, 2 February 2013 19:45:03 UTC