W3C home > Mailing lists > Public > www-archive@w3.org > September 2013

Re: defn of Named Graph

From: Pat Hayes <phayes@ihmc.us>
Date: Sun, 22 Sep 2013 17:11:12 -0700
Cc: Gregg Reynolds <dev@mobileink.com>, Sandro Hawke <sandro@w3.org>, www-archive <www-archive@w3.org>
Message-Id: <B9F47B6D-B4BF-4017-A1D6-7F3A1363FFCE@ihmc.us>
To: Jeremy J Carroll <jjc@syapse.com>
On Sep 20, 2013, at 10:54 AM, Jeremy J Carroll wrote:

> 
> 
> On Sep 20, 2013, at 2:45 AM, Pat Hayes <phayes@ihmc.us> wrote:
> 
>>  In the original paper that Jeremy and I (and Chris Bizer) co-wrote, we defined a named graph to be a <name, graph> pair, so the statement
>> 
>> GRAPH x:g1 { :a :b :c .}
>> 
>> would mean that the IRI x:g1 denotes the pair < x:g1, { :a :b :c .} >.  But if someone were to object that this is artificial and unintuitive, I would not defend it overly strongly. 
> 
> Patrick Stickler was our fourth author.

Of course, sorry. (How can I have forgotten Patrick??)

> 
> This actually works; I had forgotten. But it gives all the rights answers to all the test cases.
> 
> This suggests a different fix that achieves my personal goals and would satisfy *my* objections
> 
> Ah, I just reread:
> 
> [[
> An RDF dataset (see [RDF11-CONCEPTS]) is a finite set of RDF graphs each paired with an IRI or blank node called the graph name, plus a default graph, without a name. Graphs in a single dataset may share blank nodes. The association of graph name IRIs with graphs is used by SPARQL [RDF-SPARQL-QUERY] to allow queries to be directed against particular graphs.
> 
> Graph names in a dataset may refer to something other than the graph they are paired with. This allows IRI referring to other kinds of entities, such as persons, to be used in a dataset to identifygraphs of information relevant to the entity denoted by the graph name IRI.
> 
> When a graph name is used inside RDF triples in a dataset it may or may not refer to the graph it names. The semantics does not require, nor should RDF engines presume, without some external reason to do so, that graph names used in RDF triples refer to the graph they name.
> 
> RDF datasets may be used to express RDF content. When used in this way, a dataset should be understood to have at least the same content as its default graph. Note however that replacing the default graph of a dataset by a logically equivalent graph will not in general produce a structurally similar dataset, since it may for example disrupt co-occurrences of blank nodes between the default graph and other graphs in the dataset, which may be important for reasons other than the semantics of the graphs in the dataset.
> 
> Other semantic extensions and entailment regimes may place further semantic conditions and restrictions on RDF datasets, just as with RDF graphs. One such extension, for example, could set up a modal-like interpretation structure so that entailment between datasets would require RDF graph entailments between the graphs with the same name (adding in empty graphs as required).
> 
> ]]
> 
> hmm, I think I need to update my comment to indicate that on its resolution that paragraph should probably change.
> 
> Here is a different version.
> 
> [[
> An RDF dataset (see [RDF11-CONCEPTS]) is a finite set of RDF graphs each paired with an IRI or blank node called the graph name, plus a default graph, without a name. Graphs in a single dataset may share blank nodes. The association of graph name IRIs with graphs is used by SPARQL [RDF-SPARQL-QUERY] to allow queries to be directed against particular graphs.
> 
> An RDF interpretation I conforms with the naming of a dataset, if for each graph name gn, I(g) is the pair < gn, G > where G is the graph associated with gn by the dataset.
> 
> An RDF interpretation I of a graph within a dataset SHOULD conform with the naming of the dataset.
> 
> While graph names in a dataset may **lower case deliberate** refer to some other kind of entity, such as persons, this may cause confusion and is not RECOMMENDED.

I don't think this will be allowed by the WG, but we could put it to a vote. If it is accepted, we ought to also put some wording into Concepts to make this clear. 

> RDF datasets may be used to express RDF content. When used in this way, a dataset should be understood to have at least the same content as its default graph. Note however that replacing the default graph of a dataset by a logically equivalent graph will not in general produce a structurally similar dataset, since it may for example disrupt co-occurrences of blank nodes between the default graph and other graphs in the dataset, which may be important for reasons other than the semantics of the graphs in the dataset.
> 
> Other semantic extensions and entailment regimes may place further semantic conditions and restrictions on RDF datasets, just as with RDF graphs. One such extension, for example, could set up a modal-like interpretation structure so that entailment between datasets would require RDF graph entailments between the graphs with the same name (adding in empty graphs as required).
> 
> ]]
> 
> 
> (I didn't really understand the last two sentences and just left them unchanged and crossed my fingers)

The idea is to allow extensions which DO impose this naming condition. So we could for example say that using some new vocabulary item in a dataset (say, including < > rdf:type rdf:Referential . in the default graph) imposes this names-shall-refer-to-named-graphs conditon on the named graphs in the dataset, and this is a semantic extension to RDF. This would deflect the opposition to your SHOULD from people who want to use a different convention. 

Pat

> 
> And then any changes to concepts would be merely editorial.
> 
> Jeremy
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 home
40 South Alcaniz St.            (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile (preferred)
phayes@ihmc.us       http://www.ihmc.us/users/phayes
Received on Monday, 23 September 2013 00:11:46 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:44:23 UTC