W3C home > Mailing lists > Public > public-rdf-wg@w3.org > December 2011

Re: [ALL] agenda telecon 14 Dec

From: Antoine Zimmermann <antoine.zimmermann@emse.fr>
Date: Fri, 16 Dec 2011 17:29:08 +0100
Message-ID: <4EEB71D4.3080409@emse.fr>
To: Pat Hayes <phayes@ihmc.us>
CC: David Wood <david@3roundstones.com>, Guus Schreiber <guus.schreiber@vu.nl>, RDF WG <public-rdf-wg@w3.org>, Tim Berners-Lee <timbl@w3.org>
Le 14/12/2011 22:09, Pat Hayes a écrit :
>
> On Dec 14, 2011, at 9:57 AM, Antoine Zimmermann wrote:
>
>> The idea of having an agreed formal semantics is to be sure that no
>> matter where and when the graph is, what you can conclude from it
>> is the same. With a semantics based on URI resolution, it becomes
>> dependent on who, where and when a user agent is when trying to
>> make conclusions. You go offline and the graph changes its meaning.
>> You're behind a proxy or haven't enough rights and you change the
>> meaning...
>>
>> We can propose this as a best practice (the graph URI /SHOULD/  be
>> used to denote the RESTful etc...) but hardly a rule in the formal
>> semantics.
>
> No, really, we can make a formal semantics which takes into account
> URI resolution. Of course it will refer to whatever is resolved, so
> will be indeterminate in that sense, but it can still be enough to
> usefully (and nontrivially) constrain the possible meanings. We have
> done this for owl:imports, for example. One can rephrase
> http-range-14 in formal semantic terms, with a great increase in
> clarity, I might add.

The mechanism of owl:imports is not part of the model theory of OWL. 
With the formal semantics of OWL, a given RDF graph has a unique set of 
possible entailments, no matter what's the state of the network.
owl:imports serves to define what *is* the RDF graph on which to define 
this unique set of entailments. It acts prior to the definition of 
interpretation, so to say. In terms of what owl:imports /denotes/, there 
are no constraints other than the domain and range are both 
owl:Ontology. I could very well interpret owl:imports as "this ontology 
is funnier than that ontology", and it would be perfectly consistent 
with the semantics.

Similarly, we could very well define a mechanism which says that the RDF 
graph associated with a URI is defined as the set of triples that you 
can get from a HTTP lookup. Then the set of triples is known and fixed 
and you use the normal RDF semantics on this, which gives the same 
entailment for everybody, everywhere, always, and which can interpret 
the URI you looked up as just anything.

In fact, this would already be a good step forward, as in RDF 2004, 
nothing says what delimits a graph. With RDF 2004, it is not clear that 
all triples in a single file necessarily belong to the same graph. Nor 
is it clear that triples in different files or at different places 
belong to different graphs. In RDF 2004, we can very well believe that 
there is just one giant graph composed of all triples ever published online.

With a semantics like Tim proposes (although I would not like it to be 
included in the model-theoretic semantics), we would make clear what's 
in a graph in function of what you get in a lookup, just like OWL makes 
clear what's in an ontology thanks to expliciting the 
(non-model-theoretic) semantics of owl:imports.

Anyway, back to the discussion, David said that Tim says "the URI 
denotes", and I interpret this word as "what the model-theoretic 
interpretation assigns to the URI".


AZ

>
> If I might add a meta-comment, it would be useful if the members of
> the WG were to say what they want the semantics to do, and let the
> editors tell them what is or is not possible.
>
> Pat
>
>>
>> Le 14/12/2011 00:29, David Wood a écrit :
>>> Hi all,
>>>
>>> I had a lengthy conversation with TimBL about named graphs at the
>>> LEDP Workshop [1] last week.  Briefly, he feels that the
>>> semantics for named graphs should work like this:
>>>
>>> - An RDF Graph is named via a URI. - The URI denotes the RESTful
>>> Representation that is returned when the URI is resolved.
>>>
>>> That is, the URI denotes the graph's contents, not the graph
>>> Resource itself.
>>>
>>> How do Peter and Pat feel about that?
>>>
>>> TimBL: Please let us know if I misrepresented your position.
>>>
>>> Separately, Elsevier representatives Brad Allen and Alan Yagoda
>>> informed me that by "named graphs" they mean an RDF Graph that is
>>> referenced by a URI.  Resolution of that URI returns the graph
>>> contents (a g-text) via RESTful interaction.  That would seem to
>>> be in line with TimBL's preference.
>>>
>>> Regards, Dave
>>>
>>>
>>>
>>>
>>> On Dec 13, 2011, at 15:54, Guus Schreiber wrote:
>>>
>>>> All,
>>>>
>>>> It is quiet on the mailing list. The main thing we seem to be
>>>> in limbo about is the GRAPHS debate. I suggest we devote the
>>>> meeting to this theme. I have included in the agenda some
>>>> discussion topics that came up in recent telecons, plus the
>>>> email of Andy on TriG examples.  I suggest we also have a
>>>> meta-discussion on what our options are for getting consensus.
>>>>
>>>> The agenda is at:
>>>>
>>>> http://www.w3.org/2011/rdf-wg/wiki/Meetings:Telecon2011.12.14
>>>>
>>>> Hope to speak to many of you tomorrow. Guus
>>>>
>>>
>>>
>>>
>>
>> -- Antoine Zimmermann ISCOD / LSTI - Institut Henri Fayol École
>> Nationale Supérieure des Mines de Saint-Étienne 158 cours Fauriel
>> 42023 Saint-Étienne Cedex 2 France Tél:+33(0)4 77 42 66 03
>> Fax:+33(0)4 77 42 66 66 http://zimmer.aprilfoolsreview.com/
>>
>>
>
> ------------------------------------------------------------ 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
France
Tél:+33(0)4 77 42 83 36
Fax:+33(0)4 77 42 66 66
http://zimmer.aprilfoolsreview.com/
Received on Friday, 16 December 2011 16:29:44 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:46 GMT