Re: defn of Named Graph

On Sep 19, 2013, at 10:42 AM, Gregg Reynolds wrote:

> 
> On Wed, Sep 18, 2013 at 9:37 AM, Sandro Hawke <sandro@w3.org> wrote:
> On 09/18/2013 04:29 AM, Gregg Reynolds wrote:
> 
>> Names Graphs also provide a useful semantics for RDF Datasets.  Some RDF Datasets, hereafter NG Datasets, have this intended meaning: each (_name_, _graph_) pair is a statement that _name_ is a Named Graph which contains exactly the triples in _graph_.
>> 
>> Since _name_ is an IRI, this would mean that a Named Graph is (I think you mean "denotes"?) an IRI value (in "IR"), unless you're abandoning RDF Semantics.  
> 
> Right, a Named Graph is in IR.     We need some term for the class of things (in IR) which are denoted by the IRIs used as graph names in dataset.  What would you propose to call that class of things?
> 
> But that's not what I said.  I agreed that _name_ denotes an IR value, not that a "Named Graph" does.

Yes. What Sandro said is that the NG is *in* IR, which means it is *denoted by* an IRI. So _name_ – an IRI – denotes a named graph. Now, exactly what a named graph is, is the ontological question we are currently kicking around. 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. 

>  If I understand you correctly, you want to treat a "Named Graph" as a distinct semantic and/or ontological category disjoint from both IRIs and graphs.

Yes. 

> That's the crux of the problem, at least as I see it.

What problem are we talking about here?

>  It means you have to introduce another semantic category into the semantic domain.

The semantic domain is chock full of ontological categories. That is what RDFS and OWL are for, to describe such categories and their relationships.

>  All I'm saying is that you don't need to do that

How can you avoid "doing that", and why would anyone want to? Of course RDF allows IRIs to refer to things, all kinds of things: people, times, numbers, galaxies, web pages, etc.. Also RDF graphs. 

> if you treat the relation between a graph IRI and the graph that it names (refers to, labels, whatever) in the same way you treat property IRIs and the binary relations they name (refer to, label, whatever).
> 
> But even that doesn't complete solve the problem

What "problem" are you referring to here?

> , because the official RDF semantics, as it stands, cannot accomodate graphs.

Do you mean that the RDF semantics prohibits IRIs from denoting graphs? That is wrong, it does not. 

>  It provides for denotations of IRIs and triples, but not sets of triples.

Set of triples denote truth values. That is specified by the RDF semantic conditions. But that does not prevent IRIs from *denoting* graphs. 

>  That make sense, since the syntax provide no means of expressing graphs.  There's no "graph extension" syntax - no way to write { :a :b :c. }.

Sure there is. Any official syntax for RDF provides for this kind of description. Until SPARQL there was not way to attach names to them, but dataset syntaxes now provide this also. (Which is why this whole can of worms has been opened up, in fact.) 

>  (You might find it useful to look at the way the Z standard defines set extension syntax (ISO 13568:2002, free at http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html)).
> 
>  
> 
>> Above you said that an RDF Named Graph "contains zero or more RDF Triples".  But the values in IR are logical individuals with no substantive properties.  In particular, they are not RDF Triples.  So at this point we do not know what "RDF Named Graph" is supposed to mean.
>> 
>> ...
>> 
>> The greatest differences between RDF Graphs and RDF Named Graphs appear when one considers the possibility of them changing over time.    It is nonsensical to consider an RDF Graph changing over time, just like it makes no sense to talk about the value of some integer, say seven, changing over time.   In contrast, it makes perfect sense to consider Named Graphs changing: at one point in time the identifiable thing that is a certain Named Graph contains some triples and at another point in time it might contain different triples.
>> 
>> To me, at least, it makes no sense to consider "RDF Named Graphs" as any more mutable thatn "RDF Graphs".   They're either mathematical objects or not; if they are - and they must be - they are immutable.
>> 
>> To me the problem with Named Graphs is primarily a matter of getting clear on terminology.  I suppose we're stuck with "Named Graph", but there is no requirement that "name" be construed as a synonym for "denote".  There are lots of ways of referring to things that can loosely be considered as kinds of naming; we can think of these in terms of "modes of referring" or the like.
>> 
>> In particular, there is one mode of referring that seems to capture more or less perfectly what is wanted with Named Graphs: metonymy.  It already accounts for the way RDF properties and classes are construed by RDF Semantics; we can just do the same thing for graphs.
>> 
>> A refresher for those whose rhetorical vocab is rusty: metonymy is when you refer to something indirectly by referring to something related to it, such as using a part to refer to a whole or vice-versa.  Not to be confused with metaphor, which is based on similarity.  An example is "The White House announced that blah blah blah."  Here "the White House" denotes a building, but is used to refer to the administration headquartered in the building:  "White House" ->  building  =>  administration.
>> 
>> This is exactly what happens with RDF properties.

No. The RDF property construction is *not* an application of metonymy. The individual denoted – what you call [:p] below – *is* the property. The property extension is simply a mathematical construct which makes precise how the property holds within the universe of reference. But when a property itself has another property, or is contained in a class, it is the [:p] that we are talking about, not [[:p]]. When a more expressive language such as OWL-Full allows reasoning over cardinalities of sets, the cardinality of a set of properties is determined by counting the [:p] individuals, not by counting their [[:p]] extensions. 

>>  If :p is a property IRI, then it denotes an IR value, which is not its extension.  That IR value is mapped to its extension.  Schematically:
>> 
>>     :p ->  [:p]  =>  [[:p]],  where [[:p]] is the extension (a binary relation) of :p
>> 
>> This means that it is unacceptable to say that :p names its extension by denotation, but entirely reasonable to say that it refers to its extension by metonymy, since what it does denote is related to that extension.
>> 
> 
> I'm in over my head here.   Making some guesses....
> 
> So the the URI "http://xmlns.com/foaf/0.1/knows" is a string.  That string denotes a property I('http://xmlns.com/foaf/0.1/knows').  That property has an extension which is the set of pairs of people who know each other.
> 
> Sure, that construct makes sense and is what we want.   In particular, if it turns out there's a property foaf:hates which HAPPENS to have exactly the same extension as foaf:knows, we kind of hope that doesn't mean {foaf:knows owl:equivalentProperty foaf:hates}, even if happens to be technically true.  I think that's the extensional/intensional distinction.    
> 
> Yes.

No. The owl:equivalentProperty property means that the extensions are identical, so you do want to mean this in this case. What you don't want to conclude is that owl:equivalentProperty implies owl:sameAs. THAT is the extensional/intensional distinction. See http://www.w3.org/TR/owl-ref/#equivalentProperty-def

>  
> 
> And yes, 'named graphs' are intensional while 'graphs' are extensional.    The question is how do we codify and explain that behavior in way everyone can understand.
> 
> In fact *every* name has an intension and some - those that denote, i.e. not "Pegasus" - also have extensions.

Frege lives :-)

>  Even symbols like '2' or 'x'.  So "Named Graphs", or as I prefer, names of graphs

No. The name of a graph in RDF is simply an IRI, like the name of anything else. The term "named graph" is meant to describe the things that are the intended denotations of IRIs used as graph names. The issue underlying this thread is that these named graphs are not, in fact, RDF graphs, ie sets, but something else closely related to those sets. And we are threshing somewhat on how best to charactrize these things. But they are not just sets of triples, for sure. 

> , are not special.  They're just like names of properties or classes.  One way - the only way I can see - to get clarity is to pair an explicit syntax with a formal semantics.

We have the syntax already. The semantics is *formally* trivial: each graph name denotes the named graph that it names in the syntax. The issue is to clarify exactly what that category of "named graph" actually is. This is not a matter of formalism or mathematics, but basically an issue in philosophy of semiotics.

Pat


>  (And to choose the explanatory language very carefully, of course.)  The WGs may not be able or willing to do this officially, but if the idea is to provide some kind of explanation, this is one possibility.
> 
> ...
> 
> I can't blame you for not being willing/able to accept my proposal, but I suspect that was my last one, so I'm probably done now.    Hopefully one of you can sort this all out.    If not, I suppose the world will go on.
> 
> I'm entirely willing to accept your proposal.  I'm not posting in order to bend the world to my will, but to try to clearly explain one way of looking at things, in hopes of reaching mutual understanding.
> 
> Anyway, thanks for the response.
> 
> Cheers,
> 
> Gregg 

------------------------------------------------------------
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 Friday, 20 September 2013 09:46:05 UTC