1) Error in examples for rdf:PlainLiteral langRange ; 2) changes needed for RDF 1.1 simple literal compatibility

1) There is an error in the examples given for the langRange facet in the
rdf:PlainLiteral specification sec. 3.

The recommendation requires the use of extended filtering ; however the
examples are taken from the basic filtering section, and indicate that the
range "de-de" should not match the language tag "de-latn-de". The test
cases in the extended filtering specification explicitly list that value as
a match.

2) OWL-2 is currently out of alignment with RDF-1.1 in its treatment of
literals. RDF-1.1 no longer has the concept of plain literals.

A literal with no datatype and no language tag is defined to be syntactic
sugar for a literal of type xsd:string.  A literal with no datatype and in
language tag is defined to be syntactic sugar for a literal with type
rdf:langString (with the associated language tag).

Note that this is a syntactic transformation, not the optional RDF 1.0
entailment.

Like PlainLiteral, langString may not appear in serialization formats that
support simple literals.

Literals of type xsd:string may be serialized with or without the explicit
datatype. It is thus no longer possible to distinguish an xsd:string from a
PlainLiteral with no language tag after RDF processing.  This may impact
tools that rely on preservation of xsd:string typing. The value spaces
remains identical.

Literals without explicit datatypes are called simple, not plain. This is
distinct from SPARQL simple literals, which cannot have language tags, and
have minor differences in sorting order to xsd:string.

Proposed changes to OWL AS/FSS

0) Note the removal of plain literals from rdf 1.1, and deprecate
rdf:PlainLiteral. Note that literals without language tags that are parsed
from rdf may be typed as xsd:string and that explicitly typed xsd:string
literals may lose their explicit typing.

1) Define serialization of FSS literals to conform with RDF 1.1, permitting
explicit xsd:string typed literals to be rendered without explicit typing.

2) Add rdf:langString to the datatype map.

rdf:langString can be  defined as internally equivalent to
   rdf:PlainLiteral [langRange "*"]

3) Define xsd:string as internally equivalent to
    (rdf:PlainLiteral [langRange ""]).

This is not strictly necessary, but makes the RDF 1.1 partitioning more
obvious.

4) Allow all facets applicable to PlainLiteral to be applied to the two
partitioning subtypes.

Obviously, any rdf:LangRange on xsd:string apart from "" gives a trivially
unsatisfiable datatype.

--

Alternative:

Modulo langRange, it would also be possible to define PlainLiteral as a
legacy type that is internally equivalent to  (xsd:string or
rdf:langString); if langRange is defined as applicable to to both types,
PlainLiteral can be deprecated.

This would be a more extensive change, and if treated as a purely syntactic
expansion, would require some minimal distributive rule for restricting
disjunctive types.

Simon

p.s.

(Not an erratum or proposed change - just a whine)

I don't quite understood why defined datatypes cannot inherit the
compatible facets from the types they are defined in terms of (at the very
least for defined types that are defined as mapped types, or restrictions
on same. If named data ranges are just syntactic abbreviations, facets
applicable to the expansion should be available).