Re: Dataset Semantics

Le 20/09/2012 16:48, Pat Hayes a écrit :
>
> On Sep 20, 2012, at 4:19 AM, Antoine Zimmermann wrote:
>
>> Gregg,
>>
>> I tend to see the default graph in the same way, but there are
>> other people who don't, and we don't want to break their
>> applications. In any case, the goal of the "minimal" semantics is
>> not to have something that will solve the use cases for free, by
>> simply running a reasoner over well chosen data. Nor is it
>> something that would block your application from doing stupid
>> thing. The goal, the way I see it, is to define a semantics that
>> satisfies the requirements that we all agree on, such that if a
>> conclusion is drawn from a dataset by applying the semantics, no
>> one would object to that conclusion. In my opinion, the absolute
>> minimal requirements are:
>>
>> 1. if G graph-entail G' then, { G } dataset-entail { G' } 2. if G
>> graph-entail G' then for any IRI n, <n>  { G } dataset-entails<n>
>> { G' } 3. a dataset D entails any of its subsets
>>
>> I think this is pretty much what Peter said he would agree with.
>> Given these requirements, our objective has been to formalise it in
>> term of model theory. Unfortunately so far, each proposed
>> formalisation was implying something extra that was not in the
>> requirements above.
>>
>> The proposal that I made in my last email to Peter [1] has only one
>> extra consequence: that the inconsistency of the default graph
>> implies the inconsistency of the dataset.
>
> Suppose we simply say that {G, N} ds-entails {G' N'} exactly when: G
> entails G' and for all<n, g'>  in N' there is a<n, g>  in N with g
> entails g'. (Same n, note.) This covers the three conditions above,
> and it does not imply ds-entailment simply from inconsistency of the
> default graph alone.  (This relies on the idea that a missing graph
> is understood to be the empty graph, but I think we all assume this,
> right?)
>
> This kind of finesses the task of giving a model theory for datasets,
> so its not exactly a dataset semantics, but it might be enough for
> our purposes. It is monotonic in the usual senses, eg adding graphs
> to a dataset does not block any entailments. We could describe it as
> a constraint on any stronger (and genuine model-theoretic)
> semantics.
>
> Comments?

That would be what I would accept in the last resort, if we cannot get 
an agreemeent on a model theoretic semantics. At least it satisfies the 
requirements.


>
> Pat
>
>
>> This can either be considered as a bug, and we should fix it (or
>> give up), or we manage to agree that it is a feature, and it can be
>> added to the absolute minimal requirements, and we can declare
>> victory.
>>
>>
>> Then, when this is set up, all kinds of extensions (or
>> vocabularies, or use case-specific implementations) can be invented
>> to cover specifically certain use cases. For instance, define a
>> temporal extension where triples in named graphs corresponding to
>> disjoint time frame would not interfere (that's the minimal
>> semantics) but /additionally/, certain inferences occur between
>> overlapping time frame (that's the extension).
>>
>>
>> [1] Really minimal dataset semantics.
>> http://lists.w3.org/Archives/Public/public-rdf-wg/2012Sep/0210.html
>>
>>
>>
>>
AZ
>>
>> Le 19/09/2012 22:42, Gregg Kellogg a écrit :
>>> I step into this debate, not with any great understanding of the
>>> details, but with some expectations as a developer and as an
>>> implementer of RDF frameworks.
>>>
>>> Part of the problem that I see in the WG dynamics is that there
>>> are a number of different ways in which things like a default
>>> graph might be used. As a developer, the lack of guidance by this
>>> group (past and present) has lead to confusion IMO. This is also
>>> true of the SPARQL WG, in that implementations are free to
>>> provide different implementations of a default graph: the union
>>> of all named graphs, a separate unrelated graph not having a
>>> name, or as the default location for meta-data about named graphs
>>> themselves. I think this situation is brought about principally
>>> because of the lack of guidance these groups have given as to
>>> what the use of these features is intended to be.
>>>
>>> To not provide guidance now, after there is some experience in
>>> implementation, is, I think, a missed opportunity.
>>>
>>> Speaking as an implementer, I expect to be able to use a dataset
>>> without advance knowledge of how the data is organized. This
>>> requires that there is some meta-data that can be used to
>>> understand things like entailment regimes and the "meaning" of
>>> graph names. The SPARQL Service Description is a natural format
>>> for describe this, but there is no default binding to a dataset
>>> itself; I think there should be. I my usage, this is typically
>>> the default graph, but it could be some other "named" graph;
>>> however, if it is named, there doesn't seem to be a way to find
>>> it unless there is some normative language for how the dataset
>>> description is named within a dataset. I think it is most natural
>>> for this to be the default dataset, or that there is a relation
>>> defined within the default dataset which names the dataset
>>> description.
>>>
>>> IMO, the default graph should be used for metadata about the
>>> dataset, including, but not limited to, the SPARQL Service
>>> Description. I also believe that I should be able to use
>>> information in that service description to reason about the named
>>> graphs themselves.
>>>
>>> As an example use case, I might load information from a
>>> particular Wiki page into a graph named with the URL of the page,
>>> along with query parameters indicating a particular version of
>>> that page (clearly, the format of these URLs is arbitrary, but
>>> the way to describe them should be normative). If the page
>>> changes, I would likely load the data into a new named graph. I'd
>>> like to be able to use information in the dataset description to
>>> identify the most current version of the named graphs for a
>>> particular page, and potentially the named graphs for a
>>> collection of these pages (all pages from a current wiki, for
>>> example) at a specific time. I can imagine a system in which
>>> these graphs could be described using a vocabulary that allowed
>>> me to construct consistent SPARQL queries across these named
>>> graphs, but only if the location and semantics of this
>>> information can be determined without built-in knowledge of the
>>> dataset semantics. Perhaps this is too ambitious, but I believe
>>> that this is where we should be going in the long run.
>>>
>>> Gregg Kellogg gregg@greggkellogg.net
>>
>> -- 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/
>>
>>
>
> ------------------------------------------------------------ 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 66 03
Fax:+33(0)4 77 42 66 66
http://zimmer.aprilfoolsreview.com/

Received on Thursday, 20 September 2012 15:12:47 UTC