Re: Problem with auto-generated fragment IDs for graph names

On Feb 17, 2013, at 8:56 AM, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 02/17/2013 08:15 AM, Ivan Herman wrote:
>> I do not think so. I actually do not have a strong opinion on the 
>> bnodes-as-graph-labels issue. What I am uneasy about is that, *if we
>> use them*, they would represent a different semantics as IRI-s which
>> is my understanding of Pat's emails. That is all.
> 
> Can we fix this based on what the RDF WG suggested that we do for
> JSON-LD? By creating a special form of fragment identifier to deal with
> the situation? I realize that IRIs-as-graph-names can currently be used
> for both denoting a graph and naming-but-not-denoting a graph use cases.
> What if we do something like this:

If the group can reach consensus on using BNode identifiers to name graphs, then I really don't see the need to try to create a special fragment-identifier mechanism, and it would require modifying every RDF serialization format to define this use of fragment identifiers.

> In general, graph names denote the graph (both IRIs and Blank Node
> Identifiers).

It seems to me that the problem is that a BNode identifier used as a graph name seemingly _must_ denote the graph. Many (most) uses of IRIs as graph names also denote the graph, this just seems like common sense. The fact that some uses of IRIs for graph names do not denote the graphs is allowed, because the group could not reach consensus, but perhaps a future WG would be able to go this extra mile. If this is the case for IRIs, then I'm not sure why you couldn't say that a BNode identifier doesn't necessarily denote the graph either. In fact, if you use Andy's proposed inference rules, if the IRI didn't denote the graph, then neither would the inferred BNode.

It's clear to me that we have a mechanism for identifying things (nodes, graphs) and that making up a new thing, because we've decided to be intentionally weak in having graph names denote the graphs is just silly.

Let's just agree that we won't open the door to graph name denotation, and will maintain this illusion for BNode graph names too. As I recall, a referencing specification could always say that graph names _do_ denote the graphs, for the purposes of that specification.

Gregg

> If a developer wants to use an IRI that names-but-does-not-denote the
> graph, they can append a "special" fragment identifier (that is
> specifically called out in one of the RDF specs) to the IRI. Something like:
> 
> http://example.com/graphs/1#_:unnamed OR
> http://example.com/graphs/1#_graphname:123
> 
> We might even want to create a new class of non-IRI value to
> name-but-not-denote a graph:
> 
> _connotation:27392
> 
> It seems to me that the case where we name-but-do-not-denote a graph is
> more rare than the case where we want to denote a graph by its name. Can
> somebody point to the discussion where we decided that we can't do this?
> Or rather, who in this group would strongly oppose this general approach?
> 
> Like some of the others on this list, I'd also not prefer that graph
> names do anything other than denoting the graph. I don't want to revisit
> the issue to debate it to death again. A simple preference straw-poll at
> the next telecon might show us that this idea is/isn't worth pursuing.
> 
> -- manu
> 
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Aaron Swartz, PaySwarm, and Academic Journals
> http://manu.sporny.org/2013/payswarm-journals/
>

Received on Sunday, 17 February 2013 16:41:46 UTC