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

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:

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

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 15:57:21 UTC