- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Fri, 16 Nov 2012 10:25:58 +0000
- To: public-rdf-wg@w3.org
SPARQL uses "simple entailment" for Basic Graph Pattern matching.
Andy
On 16/11/12 09:36, Pierre-Antoine Champin wrote:
> +1 to the general approach
>
> like Pat, I'm in favor of keeping SImple entailment. I find it easier to
> explain entailment in two steps
> * first considering only the structure of the graph
> * second, constraining it by giving some semantics to some URIs
>
> That being said, we could explain that simple entailment is a mere
> theoretical step towards RDF-entailment,
> but is not intended to be used alone in actual implementations ?
>
> pa
>
>
> On Thu, Nov 15, 2012 at 10:29 PM, Pat Hayes <phayes@ihmc.us
> <mailto:phayes@ihmc.us>> wrote:
>
>
> On Nov 15, 2012, at 11:28 AM, Richard Cyganiak wrote:
>
> > Pierre-Antoine, others,
> ...
> > So I'd suggest to collapse things a bit:
> >
> > 1. Simple entailment
> > - IRIs
> > - blank nodes
> > - Datatype map
> > - Typed literals (automatically covers rdf:XMLLiteral)
> > - rdf:langString
> >
> > 2. RDFS entailment
> > - rdf:Property
> > - Classes, domain, range, subclass, subproperty
> >
> > 3. D-entailment
> > - Datatypes-as-classes (incl. datatype-as-range, type clashes)
> >
> >
>
> I like this ecept I'd like to keep the term "simple entailment" for
> the basic graph-level case, and so have this:
>
> 1. SImple Entailment
> IRIs
> blank nodes
> triples
> graphs
>
> 2. RDF with literals
> Datatype map
> Typed literals
> rdf:langString
>
> 3. RDFS (including datatypes-as-classes, if you like: I agree might
> as well merge these.)
>
> The reason is, the completeness results of the various rule sets all
> amount to "expanding" the graph by adding stuff, then appealing to
> simple entailment to be handled by matching. So this base case needs
> to be called out: its what you get if all you can do is match
> patterns against a graph, and you know nothing at all about what the
> URIs mean (including the datatype URIs in the typed literals.)
>
> Otherwise, I agree with the general appraoch.
>
> Pat
>
> >
> > On 14 Nov 2012, at 20:41, Pierre-Antoine Champin wrote:
> >
> >> Antoine,
> >>
> >>
> >> On Wed, Nov 14, 2012 at 3:48 PM, Antoine Zimmermann
> <antoine.zimmermann@emse.fr <mailto:antoine.zimmermann@emse.fr>> wrote:
> >> Le 14/11/2012 11:19, Pierre-Antoine Champin a écrit :
> >>> Pat,
> >>>
> >>> On Wed, Nov 14, 2012 at 8:16 AM, Pat Hayes<phayes@ihmc.us
> <mailto:phayes@ihmc.us>> wrote:
> >>>
> >>>> What I still don't follow is, why anyone who understands what an
> >>>> inconsistency is, would even form the idea that an ill-typed
> literal would
> >>>> be an inconsistency. It's not the distinction that needs
> explaining, it's
> >>>> why anyone would treat them as similar in the first place.
> Illformedness
> >>>> is not even in the same category as an inconsistency. Literals
> aren't true
> >>>> or false by themselves.
> >>>>
> >>>
> >>> I think the divergence of opinion comes from the fact that
> >>>
> >>> * you see typed literals merely as terms (which, strictly
> speaking, they
> >>> are), and a term can not be False; it just denotes something ;
> >>>
> >>> * others (at least myself!) see a little more in them, namely:
> an implicit
> >>> assertion that the denoted thing is indeed in the value space
> of the
> >>> datatype.
> >>>
> >>> If we decide to bite that bullet, then this could be endorsed
> in the
> >>> semantic condition for a *graph*:
> >>>
> >>> if E is a ground RDF graph then I(E) = false if I(E') = false
> for some
> >>> triple E' in E,
> >>> or if I(E') is not in LV for some typed literal E' in V,
> >>> otherwise I(E) =true.
> >>
> >> Ouch. I don't like the fact that the notion of type comes in at the
> >> level of ground-graph simple entailment.
> >>
> >> I don't see how my proposal above makes the notion of type more
> present than it was before:
> >> * typed literals are a subset of V, they were already there
> >> * LV is a distinguished subset of IR in *all* interpretation, it
> was already there.
> >>
> >> I don't believe (nor intend) that the proposal above changes the
> result of simple entailment.
> >> The only change is that, in order to satisfy the following graph:
> >>
> >> :a :b "foo"^^xsd:integer .
> >>
> >> an interpretation will have to verify
> >>
> >> IL("foo"^^xsd:integer) is in LV
> >>
> >> As nothing, in simple entailment, can constrain LV in any way,
> >> nothing prevents a graph consistent with the current condition
> to have a satisfying interpretation that meets the condition I propose.
> >>
> >> On the other hand, under XSD-entailment, as "foo" is not a valid
> lexical form for xsd:integer,
> >> the semantic conditions for datatypes impose to every
> interpretation that
> >>
> >> IL("foo"^^xsd:integer) is not in LV
> >>
> >> so no XSD-interpretation can satisfy the graph above under the
> condition I propose.
> >>
> >>
> >> Again, what I'm trying to model is the intuition that any typed
> literal is claiming that its lexical form is indeed a lexical value
> of its datatype (in rdf-mt parlance: they denote something in LV).
> This claim is neutral in simple-entailment, where datatypes have no
> special meaning (LV is not constrained). It has some impact in
> D-entailment (reflected in rdf-mt by the semantic conditions for
> datatypes that constraing what can and cannot be in LV).
> >>
> >> Or do you object to this intuition? I had the impression that
> your proposal was going that way too...
> >>
> >> The more I think of this issue, the more I believe that ill-typed
> >> literals should be a syntax error. An application that supports a
> >> datatype should reject RDF graphs that do not write literals of that
> >> type properly.
> >>
> >> That can work of course.
> >> But that makes RDF+XSD a sublanguage of RDF, just like OWL-DL is.
> >> Worse, that makes RDF+D (with D any set of datatypes) a
> different sublanguage.
> >> Makes me feel uneasy.
> >>
> >> pa
> >>
> >>
> >>
> >> Note that in OWL 2 Structural Specification and Functional Style
> Syntax,
> >> it is required that:
> >>
> >> "The lexical form of each literal occurring in an OWL 2 DL
> ontology MUST
> >> belong to the lexical space of the literal's datatype."
> >>
> >> cf. Section 5.7 http://www.w3.org/TR/owl2-syntax/#Literals.
> >>
> >>
> >>
> >> AZ
> >>
> >>
> >>> The first line (from the original definition) accounts for
> everything
> >>> asserted explicitly in a triple,
> >>> while the second line (which I added) accounts for those "implicit"
> >>> assertions carried by typed literals.
> >>>
> >>> Do you think it's a clean way to do it? Or do you consider it
> as just
> >>> another "trick" ? :-)
> >>>
> >>> pa
> >>>
> >>
> >> --
> >> 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 <tel:%2B33%280%294%2077%2042%2066%2003>
> >> Fax:+33(0)4 77 42 66 66 <tel:%2B33%280%294%2077%2042%2066%2066>
> >> http://zimmer.aprilfoolsreview.com/
> >>
> >>
> >
> >
> >
>
> ------------------------------------------------------------
> IHMC (850)434 8903 or (650)494
> 3973 <tel: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 Friday, 16 November 2012 10:26:30 UTC