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

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

Received on Thursday, 15 November 2012 21:29:40 UTC