- From: Pat Hayes <phayes@ihmc.us>
- Date: Sun, 3 Nov 2013 00:57:00 -0500
- To: Eric Prud'hommeaux <eric@w3.org>
- Cc: Peter Patel-Schneider <pfpschneider@gmail.com>, RDF WG <public-rdf-wg@w3.org>
On Nov 1, 2013, at 4:48 AM, Eric Prud'hommeaux <eric@w3.org> wrote:
> * Pat Hayes <phayes@ihmc.us> [2013-10-31 10:50-0500]
>> Reads nicely. I wonder if the immediate-inconsistency of illtyped literals should be spelled out in a bit more detail, and the notion of recognized datatype be expanded slightly. Minor wording changes along those lines suggested here.
>
> Is there any advice to be offered to folks who don't understand the implications of an inconsistency?
An inconsistency entails anything, even another inconsistency.
> I can imagine different classes of readers wondering if this change applies to them:
>
> SPARQL users who are unaware that they are just using graph entailment: SPARQL says that querying for {<s> <p> ?o FILTER (datatype(?o) = xsd:integer} over { <s> <p> "ab"^^xsd:integer } will get you {(?o->"ab"^^xsd:integer)}
That seems OK, since this inconsistent graph would entail anything. But in any case I don't think that SPARQL has ever set out to check consistency in the graphs it queries, right?
>
> Same users who are using an engine doing RDF/S or DL entailment asking questions which don't require that triple with the malformed object.
Then it shouldnt have any effect on them, I would guess. But even with the 2004 semantics, a graph can be RDFS-D inconsistent. Did SPARQL ever handle this case "logically", ie by saying that all queries are satisfied by an inconsistent graph? For example, using the 2004 semantics
:a :p "ab:^^xsd:integer .
:p rdfs:range xsd:integer .
is unsatisfiable, so it RDFS-{xsd:integer} entails, for example,
:b :q :c .
But if you had queried ?x :q :c against that first graph, you would NOT have got a match, right?
>
> Same again, but who are touching the wretched triple (sameAs? cardinality? i dunno).
Makes no real difference.
Pat
>
> Users of OWL API, etc.
>
>
>> On Oct 30, 2013, at 3:11 PM, Peter Patel-Schneider <pfpschneider@gmail.com> wrote:
>>
>>> One thing that I think would be nice to send out to implementers of RDF entailment systems is something saying what has changed. Here is a draft of the information. Comments are welcome.
>>>
>>> peter
>>>
>>>
>>> Entailment-visible changes for RDF 1.1 (informative)
>>>
>>> Most of the changes between RDF and RDF 1.1 do not have any effect on
>>> implementations of entailment, but there are a few minor changes.
>>>
>>> The sequence in which the versions of entailment are defined has changed.
>>> Datatype entailment is now defined on top of simple entailment, and then
>>> RDF and RDFS entailment are defined on top of datatype entailment. Datatype entailment refers to a set of 'recognized' datatypes. RDF
>>> entailment has two required datatypes xsd:string and rdf:langString which must be recognized, but
>>> this doesn't appreciably add to RDF entailment as these two datatypes
>>> replace plain literals.
>>>
>>> Literals formerly described as plain are now divided into xsd:string literals for plain literals
>>> without language tags and rdf:langString literals for plain literals with
>>> language tags. Thus, all literals have a type and there is no need for an implementation to have
>>> separate data structures for plain literals and datatyped literals,
>>> although rdf:langString is a special datatype as it has a language tag in
>>> addition to a lexical form and thus requires special treatment. The zero
>>> Unicode character is not allowed in xsd:string, but was allowed in plain
>>> literals, so there is a minor change here. Implementations that have a
>>> special internal data structure for plain literals might not need to
>>> otherwise change.
>>>
>>> One change that does affect entailment is that graphs containing invalid literals (e.g.,
>>> "a"^^xsd:integer) are immediately inconsistent for recognized datatypes, even in sub-RDFS entailment regimes.
>>>
>>> There is a list of XML Schema datatypes that are deemed suitable for use
>>> within RDF. They are all optional except for xsd:string.
>>>
>>> The rdf:XMLLiteral datatype is now optional. rdf:HTML is a new optional
>>> datatype; implementation experience and illustrative tests are requested.(Note also that this has at-risk aspects concerning DOM4 normalization.)
>>> rdf:PlainLiteral is a newish optional datatype; implementation experience
>>> and illustrative tests are requested.
>>>
>>
>> ------------------------------------------------------------
>> IHMC (850)434 8903 home
>> 40 South Alcaniz St. (850)202 4416 office
>> Pensacola (850)202 4440 fax
>> FL 32502 (850)291 0667 mobile (preferred)
>> phayes@ihmc.us http://www.ihmc.us/users/phayes
>>
>>
>>
>>
>>
>>
>>
>
> --
> -ericP
>
> office: +1.617.599.3509
> mobile: +33.6.80.80.35.59
>
> (eric@w3.org)
> Feel free to forward this message to any list for any purpose other than
> email address distribution.
>
> There are subtle nuances encoded in font variation and clever layout
> which can only be seen by printing this message on high-clay paper.
------------------------------------------------------------
IHMC (850)434 8903 home
40 South Alcaniz St. (850)202 4416 office
Pensacola (850)202 4440 fax
FL 32502 (850)291 0667 mobile (preferred)
phayes@ihmc.us http://www.ihmc.us/users/phayes
Received on Sunday, 3 November 2013 05:57:29 UTC