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

On 17/02/13 16:36, Ivan Herman wrote:
> Manu,
>
> the problem with what you propose is that, I believe, it breaks some
> SPARQL usage patterns out there. As far as I remember the main
> obstacle around the denote vs. non-denote was that SPARQL is
> completely silent on this issue which essentially means that in
> SPARQL there is no way of finding out whether it denotes or not
> denotes. So... any proposal in this issue *does* reopen the
> floodgates of discussion. And I do not think we should do that.

Sort of, sort of not.

In one place, SPARQL is not silent -- FROM NAMED, but that is not a 
critical feature IMO.  Otherwise it is pretty neutral, defining 
mechanism rather than architecture.

But even when DAWG was discussing this, the usage of label=location was 
already in use, so the DAWG/SPARQL discussions had that as input.

The neutrality then was the way to get agreement then ... :-)

I can image a proposal whereby

<g> {...} is label and
<value> = {...} is denotes

but then at that point, we should considering real graph literals and 
that's beyond RDF 1.1

> Also: I do not believe this is strongly related to your JSON-LD
> pattern issue with blank nodes. Ie, I would prefer to stay focused on
> that issue.

+1

>
> Ivan
>
>
>
>
> On Feb 17, 2013, at 10:56 , 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:
>>
>> 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/
>>
>
>
> ---- Ivan Herman, W3C Semantic Web Activity Lead Home:
> http://www.w3.org/People/Ivan/ mobile: +31-641044153 FOAF:
> http://www.ivan-herman.net/foaf.rdf
>
>
>
>
>
>

Received on Sunday, 17 February 2013 16:51:27 UTC