- 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