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

Re: Factoring of entailment regimes

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Fri, 16 Nov 2012 10:25:58 +0000
Message-ID: <50A614B6.2050908@epimorphics.com>
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 GMT

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