- From: Sandro Hawke <sandro@w3.org>
- Date: Wed, 03 Oct 2012 10:33:36 -0400
- To: Antoine Zimmermann <antoine.zimmermann@emse.fr>
- CC: Pat Hayes <phayes@ihmc.us>, W3C RDF WG <public-rdf-wg@w3.org>
On 10/02/2012 05:54 AM, Antoine Zimmermann wrote: > Le 28/09/2012 12:23, Sandro Hawke a écrit : >> On 09/28/2012 05:19 AM, Antoine Zimmermann wrote: >>> Wasn't the proposal made in the telecon good enough? >>> For me, this proposal is the absolute minimal requirement that I have. >> >> I don't see any problem with this proposal, but it would be helpful to >> be able to explain what it's good for. Since you said the magic word >> ("requirement"), I'm going to ask you for at least one use case that >> motivates this. > > Same use cases as I already mentionned many times. E.g., truth of a > triple varying in time: > > <year2001> { > :bill :worksFor :IBM . > :worksFor rdfs:domain :Employee . > } > <year2012> { > :bill a :Unemployed . > :Employee owl:disjointWith :Unemployed . > } > > I want that this dataset entails: > > <year2001> { :bill a :Employee .} > > and: > > <year2012> { :bill a :Unemployed .} > But clearly people can do that today, without any spec from us. They take one dataset and they make another dataset, where there's some kind of entailment relationship between the graphs in the first and the graphs with the same tags in the second. Fine. I'm asking what people will be able to do if we put this bit in the spec that they can't do if we don't. (as such, the use case probably will involve people communicating with people they don't know, guided only by the specs.) -- Sandro > > Variation in time is not the only UC. Any situations where you want to > know the conclusions you can draw from specific graphs, e.g., > reasoning over RDF graph from different provenances; over graphs of > different trust levels; etc. > > Or simply for materialising inferences for efficient SPARQL queries: a > SPARQL query of the following form: > > ASK WHERE { > { #Basic Graph Pattern G without variables } > GRAPH <n1> { #BGP G1 w/o variables } > ... > GRAPH <nk> { #BGP Gk w/o variables } > } > > issued on a dataset <DG,NGs> (with an entailment regime E) should > answer "yes" whenever <DG,NGs> E-dataset-entails > <G,<n1,G1>,...,<nk,Gk>>. > > > > AZ > >> >> -- Sandro >> >> >>> >>> The way I imagined this being explained in the spec is approximately >>> as follows: >>> >>> """ >>> The Working Group is not providing a formal semantics for RDF >>> Datasets, but agrees that the notion of entailment must satisfy the >>> following requirement: >>> a dataset (DG,NGs) dataset-entails a dataset (DG',NGs') if: >>> - DG entails DG'; >>> - for all <n,g'> in NGs', there is a pair <n,g> in NGs such that g >>> entails g'. >>> See [NOTE] for examples of formal semantics that satisfy this. >>> """ >>> >>> Then we write a WG note to provide possible formal definitions of >>> dataset semantics. >>> >>> >>> Le 28/09/2012 01:19, Pat Hayes a écrit : >>>> As promised at the telecon, an outline of the even more minimal >>>> proposal. Rather than attempt to define entailment for an entire >>>> dataset (which, however we do it, will involve some decisions about >>>> the semantic relationships between the various graphs), we can retain >>>> one key aspect of Antoine's idea by defining a named graph >>>> entailment, which is extremely simple: >>>> >>>> <N, G> name-entails <N', G'> just when N=N' and G entails G'. >>>> >>>> This extends to any entailment regime, eg we can distinguish >>>> name-RDFS-entailment and name-OWL-entailment, etc., in the obvious >>>> way, for any entailment regime on RDF graphs. >>>> >>>> This has the merit of providing the 'preserve the context' notion of >>>> entailment that Antoine has pointed out is useful in some use cases >>>> of datasets, and it allows people to define relationships between >>>> datasets (including the "minimal" entailment patterns) in terms of >>>> either graph or named-graph entailments between the various graphs in >>>> the dataset. And this can be done in the revision of the RDF >>>> semantics document in a few paragraphs, without impacting existing >>>> ideas at all. So unless there are any serious objections, I propose >>>> to define this in the revision of the RDF Semantics. >>>> >>>> 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 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> >
Received on Wednesday, 3 October 2012 14:33:45 UTC