W3C home > Mailing lists > Public > public-rdf-wg@w3.org > February 2012

Re: Islands (ACTION-148)

From: Antoine Zimmermann <antoine.zimmermann@emse.fr>
Date: Wed, 29 Feb 2012 12:28:58 +0100
Message-ID: <4F4E0BFA.6030409@emse.fr>
To: Pat Hayes <phayes@ihmc.us>
CC: public-rdf-wg@w3.org

Le 29/02/2012 04:51, Pat Hayes a écrit :
> On Feb 28, 2012, at 11:39 AM, Antoine Zimmermann wrote:
>> ....
>>> If I put two copies of a graph into a single trig document with
>>> two different lables, one of the copies does not entail the
>>> other, even though they are the same graph.
>> Again, no, the RDF graphs entail each others. It's the pairs
>> (n1,g), (n2,g) that do not entail each others. Which is exactly
>> what I would like to have. Otherwise, I would not have made two
>> copies in the first place.
> So the added label *changes the meaning* of the graph it is attached
> to. (It must do so, since otherwise the graph must entail itself,
> trivially.)

No and no. g entails g. (n1,g) does not entail (n2,g). It does not 
change at all the meaning of g. The meaning of g is not the meaning of 
(n1,g), just like the meaning of a quad is not the meaning of a triple.

  So, the natural question to ask is, how does the meaning
> change? That is, where in the semantics of these graph/name pairs, is
> there something that makes it mean something different from what the
> bare graph would mean? One wants to see a specification of an
> interpretation structure (like the INT/EXT mappings in the RDF
> semantics, but probably involving the labels in some way) which
> assigns meanings to the basic symbols, and then precisely given truth
> conditions which specify, given such a structure, what the larger
> syntactic objects - triples, graphs, named graphs and datasets - mean
> in that structure. So far I dont see that in your proposal.

It's a complete model theory for datasets. Given any dataset, 
consistency is fully specified, entailment is fully specified, and 
interpretations are fully specified. What is missing?
If you don't like the fact that I do not define what I(D) means for a 
dataset D, this is another matter. I(D) can be trivially defined, but 
does not need to. The semantics can be implemented right now with what 
the wiki provides.

> BTW, after a brief attempt to actually do it this way, I think it is
> possible to rewrite your semantics in such a way that it is formally
> equivalent to the quad-based semantics I proposed.

Sure it can be restated in terms of quads, but I think there are still 
significant differences between what you started to draft and [2]. Just 
like a quad-based formulation can be restated in terms of multiple RDF 

> Which is
> encouraging, I guess. However, it does mean that *every* triple in
> *every* named graph has to be understood in the 'quad' way, which is
> rather a lot to swallow. And it depends on being able to use a graph
> label in many different datasets with the same meaning, so the scope
> of these labels has to be very wide; and it does not have the label
> URIs denoting the graph they name (unlike N3, for example, and ruling
> out Sandro's interpretation as meta-data.)

Yep, because there are also other use cases where one does not want the 
label to be interpreted as the graph itself. But there can be various 
extensions of the semantics which impose more constraints.
However, if we impose the constraints from the ground up, people who 
need a weaker semantics will not be able to define it in agreement with 
the specs.

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

Antoine Zimmermann
ISCOD / LSTI - Institut Henri Fayol
École Nationale Supérieure des Mines de Saint-Étienne
158 cours Fauriel
42023 Saint-Étienne Cedex 2
Tél:+33(0)4 77 42 83 36
Fax:+33(0)4 77 42 66 66
Received on Wednesday, 29 February 2012 11:29:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:03 UTC