Re: Using bnode identifiers for predicates, graph names

On Feb 5, 2013, at 1:48 PM, Manu Sporny wrote:

> ...
> We can have blank nodes in RDF, and those nodes can refer to one
> another.

Whoa. In what sense do you think that a blank node can refer to another blank node? In any sense of "refer" that I know, this is not true. It is certainly wrong to say that a blank node can *identify* another blank node. 

> Why can't we have blank graphs?

What is a blank graph? Do you mean the empty graph? Hmm, I guess not ...

> Why can't the content of blank
> graphs refer to one another?

Right now, the RDF spec does not even provide a way for one named graph (that is, named with a URI) to refer to another. This is because the RDF specs require an IRI used in an RDF triple to be interpreted referentially, and the specs deliberately allow an IRI to be used as a graph label when it is being used to refer to something other than the graph it labels. 

Pat


> 
> 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/
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Tuesday, 5 February 2013 21:50:03 UTC