Re: [ALL] agenda telecon 14 Dec

On Dec 14, 2011, at 5:44 PM, Richard Cyganiak wrote:

> On 14 Dec 2011, at 21:02, Pat Hayes wrote:
>>>> But that design refers to 'named graphs', which already introduces new semantics (that is, semantics which goes beyond that defined in the RDF specs.)
>>> 
>>> Isn't it a fallacy to think that because a symbol is called X, its formal meaning has to be what's implied by X?
>> 
>> Yes, but that does not seem to have anything to do with what we are talking about. I am concerned with the actual meaning of this rather important phrase. 
> 
> We are creating an engineered artefact. The actual meaning of the terms that we use in defining this artefact is whatever we define it to be. “Named graph” is a neologism and its definition is whatever we make it.

Fair enough. But since this term was introduced in an extant publication, and is widely used in that sense, we ought (if we are planning to re-define it) at least draw attention to the fact that our definition does not correspond to the pre-existing one. 

BTW, I am not at all clear that the usage in SPARQL 2008 is intend to be different from this usage. You apparently take this for granted, but it is not obvious.

Also, there are now three meanings of 'name' to be unpicked. If a dataset has <:foo [graph]> in it and [graph] contains a triple which uses :foo to refer to, say, me, but HTTP GETs something else altogether when you give it :foo, then we have three senses of "identify" to reconcile. I wonder how many more of them there will be in the future.

> 
>>> “Blank node identifiers” exist in concrete syntaxes but do not occur at all in the formal semantics, much less “identify” anything.
>>> 
>>> The xsd:anyURI datatype is supported in RDF Semantics, and its value space is IRIs, but these IRIs don't “denote” or “identify” in the formal semantics. They simply are inert string values.
>>> 
>>> Same with “graph names”, they exist in the abstract syntax, but that doesn't mean they have to occur in the formal semantics. They're ways of grouping RDF triples together, that's all.
>> 
>> Well, that is a meaning which the semantics should address. Presumably they have some function: if that functionality produces any entailments that would not hold without it, then the semantics should address and clarify these. 
> 
> I don't think that it should produce any additional entailments and hence see no need for the model theory to address it.

Well, consider the fact that many of us in these email discussions have given examples in which an IRI is used in RDF triples with the intention of it denoting the graph that it "names". If this "naming" does not produce any entailments which depend on what is 'named', then all these examples are meaningless. Even if we, the WG, clean up our act in this regard, I simply do not believe that we can persuade the world to have IRIs used as "names of graphs" but not to use those names in any RDF triple. 

>>> Research on adding formal semantics for named graphs
>> 
>> Named graphs already have a precise semantics. Both the phrase and the full semantics of it were published in the original paper I co-authored with Jeremy and others.
> 
> Has this semantics ever been implemented? What systems rely on it to function or interoperate?

? One does not implement a semantics. The semantics expresses truth conditions in a way which stands outside details of implementations. That is the point of having it. So, no, of course it has not been implemented. 

> 
>> If you mean something else by "named graph", please use a different terminology (and so should the specs). 
> 
> I'm using it in the sense of Prud'hommeaux and Seaborne, Eds.: SPARQL Query Language for RDF. W3C Recommendation, 15 January 2008.

And what sense is that, exactly? The nearest thing I can find there to a definition is (section 8) "... named graphs, where each named graph is identified by an IRI." although the term has been used without definition or citation several times earlier. To me, this use of "identifies" at least strongly suggests that the IRI is intended to denote the graph. 

>> I understood that people want to be able to use an IRI to 'label' a graph (to be the fourth field in a quad store) while at the same time considering that IRI to denote something else, such as a person. OK, but this means that the relationship between the IRI and the graph it labels cannot be that of naming.
> 
> Why do you say that it cannot be? Of course it can be.
> 
> An IRI can denote one thing – in the precise technical

I wish you would stop using these 'scare adjectives'. The semantics might be precise and technical (that is the point of it) but the SENSE of denotation is describes is perfectly ordinary. It means, the relationship between a name and what the name is used to refer to. It is the relationship between "Richard Cyganiak" and you, and between "Patrick Hayes" and me. The relationship of naming: the inverse of the relationship of is-a-name-for. There is nothing 'mathematical' or 'technical' about the relationship that the semantics *describes*, even though the way it describes it is mathematical and technical, just as engineering drawings of a bridge do not imply that the bridge is made of paper (or mathematics.)

> sense of “denote” as used in RDF Semantics (and, as of RDF 1.1 ED, in RDF Concepts).
> 
> The same IRI can be the graph name of another thing – in the precise technical sense of “graph name” as used in SPARQL 1.0, SPARQL 1.1, and RDF 1.1 Concepts.

Well, there is no technical sense given there, in fact. But in any case, that is largely irrelevant. If an IRI is being used as a name, or used to identify something, then that relationship between the name and the thing identified  is EXACTLY what the model-theoretic semantics is designed to be talking about. Your case here is like saying that we can use the numeral '34' to refer to my uncle Jim because the that 'numerical' sense given to it by arithmetic is just a 'precise, technical' sense, and we are free to use it other ways when we aren't being so, well, precise and technical. 

What we have here is a single IRI being used simultaneously with two distinct meanings, and the operation of the overall system (SPARQL included) depends on some of the occurrences being interpreted one way, and some another way, with no syntactic markers to distinguish which meaning is intended in which cases. This has nothing to do with some kind of scruffy-implementor's jihad you are determined to wage against 'precise, technical' model theory: it is a design feature which we are apparently going to set in stone, and it is one which is in direct violation of the current 2004 RDF specs. So we have to rewrite something here. We can't just pretend that there isnt an issue to be fixed. 

> 
> Reasonable people might argue that this would be confusing or a bad idea, but saying that it is somehow impossible is plainly false.

It violates the 2004 specs. As long as "RDF Datasets" were part of the SPARQL spec, then this wasnt strictly RDF's problem. But we are revising the RDF spec, not the SPARQL spec. So now, this is RDF's problem. And it really is a problem.

My own preference would be to simply ignore this entire business of datasets in the the RDF spec. They have nothing to do with RDF as such: they are a poorly defined implementation issue which rides on top of RDF, and one that I predict will be history in about five more years in any case. There isnt really any need to standardize them at all, IMO. But I guess that would not be an acceptable strategy for us to adopt :-)

> 
>> Under these conditions, with the RDF semantics unchanged, the fourth field in a quad store, or the IRI associated with a graph in a SPARQL RDF Dataset, is *not* the name of the graph, and these items are *not* named graphs. 
> 
> The IRI is not the *denotation* of the graph, in the technical sense of “denotation” used in RDF Semantics.

The only thing technical is the way the semantics are expressed. What they are talking about is naming, in any sense that matters in using RDF. So, if this is not 'denotation, then it is not naming. Because that is what naming IS. 

> 
> Something is a named graph if and only if it meets the definition of the term “named graph”. How else could it be?

I can define a 'named froodle' to be a pair of a froodle and a IRI. That however does not automatically make the IRi into a name of the froodle. To do THAT, you have to somehow explain how it can be that interpretations I are required to have I(<the IRI>) = the froodle. Because that is the (only) sense of 'naming' that matters when we interpret RDF triples normatively. 

> 
>> However, Concepts currently says they are named graphs.
> 
> Yes. And that makes anything that meets that definition a “named graph in the RDF Concepts sense”.
> 
>> OK, you can take the position: to hell with what 'named graph' used to mean, Concepts is currently *defining* it to be simply a <IRI, graph> pair; end of story.
> 
> That's what SPARQL said in 2008.

It did not actually say: end of story. Which is where we (and I will bet many others) apparently differ on how to interpret that SPARQL standard. 

> 
> My position is: why change what works?

Because it does not work. It is ambiguous, and different people build things which work differently as a result. And in any case, I don't want to change it, I want to get it clear. I am even willing to go along with the poisonous 'punning' idea, but I want it to be made as clear and as exact as the rest of the spec is, and this is done by putting it into the semantics (and into Concepts) explicitly. 

> 
>> Which is a coherent position, as long as you stop there. But in fact, everyone wants more: they want to be able to *use* the IRI to *refer to* the graph, inside some RDF triples. And this simple definition of named graph does not cut it for that use.
> 
> What does RDF Semantics have to do with that? RDF Semantics isn't a theory of reference.

It connects reference with truth of assertions, which is the only way that RDF triples can connect to IRI references. 

> 
> People use the URI <http://dbpedia.org/resource/Malta> to refer to the mediterranean island nation in RDF triples. Even though RDF Semantics doesn't say anything about countries. You know, it actually works.
> 
>> You have to also specify that the IRI denotes the graph (a semantic condition.)
> 
> Where's the semantic condition that specifies that the IRI denotes the country?

Where is the application which depends upon the IRI denoting the country? Contrast that with the IRI-to-graph case. That is the key point (which also applies to owl:imports, by the way): in some cases, the referent of an IRI is itself an RDF artifact which is involved in the RDF processing, which in turn depends on getting the naming relationship *right*. And in those cases, we need something better than accidental denotation: we need *rigid* denotation. 

> 
>> Just being a handy organizing tag isn't enough to get the intended meaning of this 'tag' into RDF. 
> 
> RDF Semantics isn't about meaning. It's about entailment relationships between RDF graphs.

Wrong. It determines entailment relations as a by-product, but what it is about, directly, is truth conditions on interpretations. 

> RDF graphs acquire meaning through social contracts and conventions.

Which largely work by imposing or presuming truth conditions on assertions. In some cases, reference is determined by ostentation (graphs are one such case), but these are like the guy ropes holding down the corners of a tent. Most of the semantic fabric is held together by its own truth conditions, which is exactly what the model theory describes. 

Pat 


> 
> Best,
> Richard
> 
> 
> 
> 
>> 
>> I confess that I am now rather puzzled about what position the WG has actually taken. On the one hand, there seems to be a strong feeling that this kind of labeling flexibility must be permitted: on the other, there seems to be a resolution that the labeling IRI in a SPARQL store does indeed denote the graph. Taken together, these directly contradict the current RDF semantics, so *something* has to be changed. 
>> 
>> Pat
>> 
>>> 
>>> Best,
>>> Richard
>>> 
>>> 
>>> 
>>> 
>>>> 
>>>> Pat
>>>> 
>>>>> Knowing who can't live with this minimalist approach would be a form of progress IMO.
>>>>> 
>>>>> Best,
>>>>> Richard
>>>>> 
>>>>> 
>>>>> [1] http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html#section-multigraph
>>>>> 
>>>> 
>>>> ------------------------------------------------------------
>>>> IHMC                                     (850)434 8903 or (650)494 3973   
>>>> 40 South Alcaniz St.           (850)202 4416   office
>>>> Pensacola                            (850)202 4440   fax
>>>> FL 32502                              (850)291 0667   mobile
>>>> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>> ------------------------------------------------------------
>> IHMC                                     (850)434 8903 or (650)494 3973   
>> 40 South Alcaniz St.           (850)202 4416   office
>> Pensacola                            (850)202 4440   fax
>> FL 32502                              (850)291 0667   mobile
>> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Friday, 16 December 2011 18:43:14 UTC