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

On Oct 4, 2011, at 4:30 PM, Richard Cyganiak wrote:

> On 4 Oct 2011, at 21:48, Pierre-Antoine Champin wrote:
>>> RDF Semantics currently doesn't have the power to fix the
>>> denotation of *anything* (except the RDF(S) built-ins),
>> 
>> and all literal values...
> 
> Ok, you got me there ;-)
> 
>>> and *always*
>>> defers to convention for establishing the connection between IRIs and
>>> things. RDF works nevertheless. Why should it be any different for
>>> graphs?
>> 
>> Well, if graphs in a dataset are g-snap, then they look very much like
>> literals to me, and I would tend to read
>> 
>> <some-uri> { :a :b :c }
>> 
>> as something like
>> 
>> <some-uri> owl:equals " :a :b :c . "^^rdf:turtle
> 
> I disagree. The latter amounts to an assertion that <some-uri> denotes an RDF graph. The former doesn't assert anything (or shouldn't, in my view). It's just a graph associated with a URI.

Where 'associated' has absolutely nothing to do with RDF semantics, right? In fact, where it is *normatively asserted* to not have anything to do with it.

> 
>> Now, if graphs are g-boxes, I would rather read
>> 
>> <some-uri> { :a :b :c }
>> 
>> as something like
>> 
>> <some-uri> rdf:hasCurrentGSnap [
>> 	log:implies " :a :b :c . "^^rdf:turtle
>> ]
>> 
>> where rdf:hasCurrentGSnap would have rdf:GBox as its domain, so I can
>> *at least* infer that <some-uri> denotes *some* g-box.
> 
> I do not like the idea of inferring anything from the graph names in RDF datasets. That way madness lies.

But every time you use the name to refer to the graph, you are making an inference. And the way we have set things up with graph labels (see above) it is an *invalid* inference. So forget having RDF 'metadata' using graph labels/names: that is literally impossible, with the current conventions about the fourth IRI in a quad store. There is NO WAY to refer to a graph in RDF, with the current semantics. If we want to do this, we have to change the semantics rules so that the graph label denotes the graph it labels. This is trivial to do, of course, and to me it seems like a no-brainer, but apparently the WG does not agree. Which is fine, but then we all have to live with the consequences.

> For starters: In what graph would you like to store those inferences?

Why is this a question that anyone should feel obliged to answer? Why is it relevant?

>> In any case, I do not see how what I propose implies something radically
>> different from the kind of inference that already exist in RDF.
> 
> Inference is the process of deriving new statements from statements whose truth is known or can be presupposed.

Wrong.   Inference is the process of establishing that an entailment relation holds between (sets of) statements and other statements. Entailment is the relationship that IF the antecedent is true THEN the consequent must be. However, entailment does not itself suppose or presuppose the truth of the antecedent.  (And, BTW, although it is not directly relevant here, inference does not have to be 'forward' inference. One can check inference backwards, in a goal-directed mode, as in Prolog or querying.) 

> In an RDF dataset, you cannot presuppose the truth of anything – the graphs are not asserted but merely collected for data management purposes.

Which is completely irrelevant to asking what they entail. Querying them is asking what they entail. 

> 
> Inference is defined over RDF graphs, not over collections of unasserted RDF graphs.

Inference is defined over RDF graphs, and a set of graphs can be considered to be a graph. Assertion (or not) is irrelevant. 

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 20:14:37 UTC