Re: Factoring of entailment regimes (was: Re: Ill-typed vs. inconsistent?)

+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> 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> 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>  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
> >> 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
>
>
>
>
>
>