Re: Summary of strings, markup, and language tagging in RDF (resend)

I disagree strongly with Pat's proposal here.

pat hayes wrote:

> design slightly, by reverting to an older design. The trouble seems to 
> arise from our insisting that XML literals are treated uniformly with 
> typed literals: so let us abandon that idea, in spite of its being very 
> neat, and revert to the state where the XML literals as treated as a 
> special syntactic case in the RDF graph, so that there would be five 
> kinds of literal: plain and XML with and without lang tags, plus 
> datatyped literals.
> 
> In detail, the proposal is as follows.
> 
> 1. There are five kinds of literal in an RDF graph, indicated in 
> Ntriples as follows:
> "string"                  plain
> "string"@tag              plain plus lang tag
> "string"^^rdf:XMLLIteral          XML
> "string"@tag^^rdf:XMLLiteral      XML plus lang tag
> "string"^^foo:baz              typed, where foo:baz is any URI other 
> than 'rdf:XMLLiteral'
> 
> Notice that the Ntriples way of indicating the XML case is just as it is 
> now, but thats just a syntactic decision to save work; rdf:XMLLiteral 
> isn't a datatype and XML literals are not typed literals in this design, 
> so the possibility of having lang tags in its lexical space isn't going 
> to cause any headaches..
> 
> 2. The semantic conditions on the first four are specified in the RDF 
> interpretations and spelled out in detail - exactly how I leave to 
> others to decide, but it seems to me that we could dispense with the 
> wrapper (since we don't need to include the lang tag in a value space 
> any more) and could just say that the XML case is treated semantically 
> just like the plain case, ie the XML literal denotes itself (a piece of 
> XML text, perhaps one conforming to Jeremy's elaborate conditions in 
> http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-concepts-20030117/#section-XMLLiteral, 
> or such a piece of text plus a lang tag); this would simplify the RDF 
> MT, in fact.
> 


The key question is what will this achieve in terms of actual deployment.
What I have seen in webont is that at least some of the target community 
for RDF is resistant to XMLliterals at all.
Every obstacle to easy deployment of XMLLiteral will be a reason to not 
deploy it.
Currently (based on the LC design) webont have declared that OWL tools 
should minimally support xsd:string and xsd:integer, whereas rdf:XMLLiteral 
is optional. This means that certain entailments are implementation dependent
(contrast
http://www.w3.org/TR/owl-test/proposed-misc-200-xmlliteral#miscellaneous-204
http://www.w3.org/TR/owl-test/proposed-misc-200-xmlliteral#miscellaneous-205
)
The same file is constistent or inconsistent depending on implementation 
specific parameters (reasoning support for rdf:XMLLiteral, which is optional).

 From my point of view this is a failure of *this* WG to have a design that 
is sufficiently simple that implementors and others feel they can commit to 
it. I believe that the simplifications we have made will be beneficial for 
I18N, in that the only remaining difficulties for XMLLiteral are in the 
parser, and many parser writers seem bought in to doing the work.

It is futile to have the perfect design on paper if there is not consensus 
amongst the implementators to actually implement it. If this WG decides to 
make XMLLiteral harder to implement in order to make life easier from an 
I18N perspective, then the result will be that many RDF implementations 
will not implement it, and hence the user who needs the I18N features 
provided by XMLLiteral will need to take additional care to find a 
conformant implementation.

It is undoubtedly correct that Pat's design works on paper (modulo a few 
tweaks) and addresses Martin's issue about xml:lang.

It is not at all clear that this actually furthers the real usablity of 
semantic web technologies in an I18N context. I think it probably sets it back.


> 
> 4. Regarding Martin's other beef, that some XML without any markup in it 
> is 'really' just plain text, this design also allows an RDF application 
> to deal with this reasonably sensibly, since that identification amounts 
> to just stripping off the ^^rdf:XMLLiteral flag when the literal string 
> has no XML markup in it. I would vote against making that a valid RDF 
> entailment in the semantics, but it would be relatively easy for a small 
> app to do this using simple scripting on literals and still be a 
> sensible semantic extension, without getting into all the datatyping 
> complexity.
> 


Minor point, such a small app could exist with our current design.

Jeremy

Received on Thursday, 3 July 2003 06:03:32 UTC