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

Dear Simon,

Thanks for highlighting this issue. I finally got around to adding it to the list of errata (https://www.w3.org/2001/sw/wiki/OWL_Errata).

Regards,
Ian


On 2 May 2014, at 18:09, Simon Spero <sesuncedu@gmail.com> wrote:

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

Received on Tuesday, 5 August 2014 10:49:20 UTC