Re: why I don't like named graph IRIs in the DATASET proposal

On Oct 4, 2011, at 10:37 AM, Richard Cyganiak wrote:

> Hi Pat,
> 
> On 3 Oct 2011, at 02:27, Pat Hayes wrote:
>> There is no "way" of denoting something. To say that A denotes B is simply to say that A is being used as a name to refer to B. 
> 
> We're writing a technical specification. This means we get to define what we mean when we use a word. “To denote” in RDF can have a specific technical definition that can have caveats or complications not found in the usual meaning of the word, as long as we define our terms.
> 
> We regularly use words such as “resource”, “triple”, “subject” or “literal” with specific narrow technical definitions that differ from the usual definitions of these words.
> 
> This is common in standardization work, and given the time you've spent in standardization bodies I shouldn't have to explain that to you.

But as this word is used only in the semantics document, and I get to write it, I will use words with their normal meaning wherever possible, especially when they are already technical words with a technical meaning which we are in fact actually using. If you can come up with two senses of 'name' or 'refer' which differ in some useful way, I'm all ears to hear about them. How would it work? Two different interpretation mappings? 

> 
>> If an identifier of some kind is being used to refer to some thing, whatever the thing is, then it is being used to, and can correctly be said to, DENOTE that thing. That is what the word "denote"  MEANS.
> 
> No. To say that A denotes B means whatever the specification defines it to mean. It can differ from what's written in a logic textbook.

It could mean anything we want it to mean, but in fact it will mean what it means in a "logic textbook", which is also what it means in English. 

> 
>> RDF will continue to be a notation with a normative model-theoretic semantics in which the IRIs in RDF triples are all treated as denoting names, and the truth of triples is defined in terms of that these names denote.
> 
> How about this: RDF *graphs* will continue to be a notation with a normative model-theoretic semantics, etc.
> 
> RDF datasets, however, will be simple semantics-free collections of RDF graphs where these graphs happen to be associated with IRIs to ease their management.

I do not understand what you mean by a "semantics-free" collection of things that have a normative semantics. Do graphs inside a dataset have their semantics switched off in some way? What does this mean? Since they are graphs, and the semantics of graphs is normative, how does the switch work? (This sounds eerily reminiscent of the old idea of 'dark triples', except these triples can get darker or lighter as they move around.)

> My demand is that *nothing* is changed in RDF Semantics as a result of the introduction of RDF datasets.

We must be at cross purposes. I thought that was MY demand :-)

> 
>> (unless we somehow impose some extra semantic conditions to achieve the necessary lock on what the IRI denotes, as described in the original named-graph paper.) 
> 
> I think that this “lock” on what the IRI denotes is unnecessary and would be harmful and should be strictly avoided.

Leaving quad-store engineering aside, and talking instead of named graphs more generally, I profoundly disagree. Without some kind of semantic condition, none of the suggested uses of named graphs makes real sense, and certainly none of the applications which involve any reasoning (and querying is a form of reasoning) would work properly.

> RDF is being used to make statements about all sorts of things – people, web pages, taxonomic concepts, and so forth – without having any of this kind of “lock” in RDF Semantics. Why should graphs be any different? What's the use case?

The use case is exactly when you put some way to 'label' a graph into the syntax, and expect that syntactic operation to have semantic consequences. (See for example the ideas about publication warrant graphs in the old named graph paper.) 

I went along with this (passionately expressed) divorcing of the fourth quad field from the RDF semantics, reluctantly and with great apprehension, under the condition that there was clearly a complete break between this 'association' and actual naming of a graph by an IRI. But that is not what you are now proposing: that has the direct, and ineluctable, consequence that the *use* of an IRI in RDF - any RDF that is supposed to be conformant to the RDF specs, that is -  cannot rely on this association to determine the referent of that IRI. If the IRI in a graph in a quad store is referring to a person, then that same IRI cannot be used to *refer to* a graph. And when it is used inside an RDF triple, what it *refers to* is what is being talked about by that triple. Anything that is using this IRI to both refer to  a graph and to refer to something other than a graph is in violation of the RDF semantics specifications, because that kind of dual-reference is impossible in any RDF interpretation. So, yes, you can keep 'refer' and 'associated with' distinct, provided that you really do keep them distinct. But you can't say they are distinct and then use them as though they are interchangeable. 

Now, I say 'can't' and what I mean of course is, that usage violates the specs. But of course if all we are talking about is some machinery internal to some application, well it can do whatever its owners want to do. I can print out an IRI on a brick and use it as a doorstop if I feel like it. The specs surely only apply to RDF used 'in public', as it were, on the open Web. That is the only case, at any rate, that I feel we need to even be thinking about. 

Pat


> 
> Best,
> Richard
> 

------------------------------------------------------------
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 Wednesday, 5 October 2011 23:38:46 UTC