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

> 
> On Wed, Sep 18, 2013 at 9:37 AM, Sandro Hawke <[email protected]> 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)
[email protected]       http://www.ihmc.us/users/phayes







Reply via email to