Re: message to RDF entailment implementors

Your changes look fine.   I'll put together a cleaned up version and send
it out to targetted implementers in advance of the CR change as a heads-up
(unless anyone thinks that that is a bad idea).

peter



On Thu, Oct 31, 2013 at 8:50 AM, Pat Hayes <phayes@ihmc.us> wrote:

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