Re: [ALL] agenda telecon 14 Dec

On 16 Dec 2011, at 18:42, Pat Hayes wrote:
>> 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. 

So, named graphs means something different in SPARQL 2008 than it does in the paper you co-authored. The overloading of the term hasn't caused any major problems as far as I can tell. The SPARQL usage has long since superseded the original usage in popularity, and the different meaning it had in its original form can be considered a historical footnote at this time.

> 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.

It *is* obvious. SPARQL is an engineering artefact. The term “named graph” in that context is exactly what the specification defines it to be. Unlike some other specs that shall remain unnamed here, SPARQL defines clearly what it takes to conform to the specification. The query language specification does not constrain the semantics of datasets in any way; there is nothing that indicates non-conformance when “strange” datasets such as those using primary topics or email addresses as graph names are used.

http://www.w3.org/TR/sparql11-query/#conformance

> Also, there are now three meanings of 'name' to be unpicked.

Yes, and that's been the case ever since SPARQL introduced datasets several years ago: “graph name” in RDF datasets, “to denote” as in the relationship between RDF terms and their interpretations, and “dereferencing” as a protocol operation in HTTP and web architecture.

> 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.

Aligning those three senses is a matter of best practices, not a matter of standards.

>>>> 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.

The sense of “meaning” that you're using here isn't how people use that word elsewhere and isn't terribly relevant to the work we are doing here. If we come up with a mechanism that is “meaningless” but useful, then that's surely ok.

> 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. 

What? I don't want to persuade the world to stop using graph names in RDF triples. They've been happily using them for years, and it works just fine. I want them to be able to keep doing that.

As far as I can tell, they're doing just fine without any entailments. That's why I said:

>> I don't think that it should produce any additional entailments and hence see no need for the model theory to address it.

There are many useful bits and pieces in RDF that don't produce entailments and are very useful. Are you saying that they all should be removed? Are you saying that entailments are needed for all of them?

>>> 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. 

Well, SPARQL has been implemented many times. Changing the terminology in SPARQL would be rather costly. The suggestion that SPARQL should use a different term than “named graph” because you used that term earlier with a different definition is absurd.

>>> 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. 

The normative definition of SPARQL is Section 12. RDF Datasets are in 12.1.2:
http://www.w3.org/TR/rdf-sparql-query/#sparqlDataset

>>> 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.

No. Denotation in RDF isn't the same as the general and ordinary sense of “naming”.

In RDF, only URIs and RDF literals denote; this isn't the case in naming in general.

In RDF, there is a unique name assumption. This isn't the case in naming in general.

Denotation in RDF is an attempt at a formal account of describing how naming works. It's a simplified model. As they say, “all models are wrong, but some are useful”. Pretending that naming *is* RDF denotation is wrong in so many ways.

> 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.

You may wish that RDF Semantics was that general, but it isn't.

I could call my dog "http://dbpedia.org/resource/Spain". I would be using an IRI as a name, to identify a dog. There is surely nothing wrong with that. I could do that even if I knew nothing about RDF. It would be rather comical for you to insist that someone would violate a foundational specification of the Semantic Web by doing so. The relationship between IRI and thing in this case simply has nothing to do with RDF Semantics.

(I don't have a dog.)

> 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. 

I'm sure there's a database somewhere that has the data value “34” in an ID column and uses that number to refer to your uncle Jim. That is completely normal. The database just doesn't use RDF semantics.

> 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.

There *is* a syntactic marker. IRIs appearing as part of a named graph establish that this IRI is a graph name for the RDF graph; their occurrence in this position doesn't restrict what they may denote. IRIs appearing in RDF triples within RDF graphs restrict what the IRI may denote; it doesn't establish that the IRI is a graph name for anything.

> This has nothing to do with some kind of scruffy-implementor's jihad you are determined to wage against 'precise, technical' model theory:

“Scruffy-implementor's jihad…” :-)

My problem with model theory isn't that it's precise or technical. I like precise and technical. I don't have any problem with model theory, in fact. I do have a problem with people who have deluded themselves into thinking that anything not said explicitly in model theory is wrong, invalid, or impossible.

> 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.

Quotes from the spec please.

> 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.

Quotes from the spec please.

>>> 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. 

*Maybe* denotation is naming. But naming isn't denotation. The inference “If x names y, then x must RDF-denote y” is not valid. It doesn't hold for literals, for example. (Even literals that are IRIs.)

>> 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. 

There are many senses of “naming” in and around RDF that are not denotation. We have blank node identifiers, variable names, the foaf:name property, etc

>>> 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. 

There is no need for interpretation. If it's not in the specification text, then conformance doesn't depend on it. End of story.

>> 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.

Which different people have built things that don't interoperate because of the definition of RDF datasets in SPARQL 2008?

> 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,

You mean, get it as clear and exact as the formal treatment of RDF lists, containers, reification and rdf:value?

> and this is done by putting it into the semantics (and into Concepts) explicitly. 

I'll quote from RDF Semantics:

[[
The omission of these conditions from the formal semantics is a design decision to accomodate variations in existing RDF usage and to make it easier to implement processes to check formal RDF entailment. For example, implementations may decide to use special procedural techniques to implement the RDF collection vocabulary.
]]

This sounds relevant. I fully support a treatment of RDF datasets in RDF Semantics that amounts to the above.

>>> 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. 

There are all sorts of ways how RDF triples can connect to IRI referents. The triple { [] foaf:name "Alice" } is (somewhat) meaningful because the FOAF spec assigns a referent to the IRI foaf:name, and announces this assignment in a number of ways that are generally accepted as authoritative by the community. RDF Semantics isn't needed for that to work. RDF Semantics is needed to explain the blank node and to explain any possible additional triples entailed by this one.

>> 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?

Any application that puts information onto a map.

> 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,

Right.

> 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. 

Those are unproven assertions. The community seems to be doing pretty well without rigid denotation.

RDF Semantics is a foundational standard of the Semantic Web. But it doesn't say *anything* about the denotation of IRIs as implied by the Web, much less give them rigid referents.

RDF Semantics is all about RDF graphs. But it doesn't say *anything* about the denotation of resources that represent rdf:Statements or rdf:Lists, much less give them rigid referents.

From this I conclude that RDF Semantics doesn't need to say *anything* about the denotation of IRIs used as graph names in RDF datasets, much less give them rigid referents.

This stuff works just fine!

>>> 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. 

Well, depending on how you look at it, a vacuum cleaner isn't about getting dirt out of the carpet, but about sucking air.

A manufacturer of vacuum cleaners who puts sucking air over getting carpets clean will eventually end up out of business. Think about it, Pat.

>> 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.

I don't know what philosophers mean by “ostentation”, and can't make sense of the tent/fabric metaphor.

Best,
Richard

Received on Monday, 19 December 2011 22:26:42 UTC