W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > July 2003

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

From: Graham Klyne <gk@ninebynine.org>
Date: Thu, 03 Jul 2003 12:24:59 +0100
Message-Id: <5.1.0.14.2.20030703122219.00bcf438@127.0.0.1>
To: Jeremy Carroll <jjc@hplb.hpl.hp.com>, pat hayes <phayes@ihmc.us>
Cc: w3c-rdfcore-wg@w3.org, Brian_McBride <bwm@hplb.hpl.hp.com>, Martin Duerst <duerst@w3.org>

FWIW, I think Pat's proposal is marginally easier to implement than what we 
have at the present, and considerably easier than some approaches that have 
been suggested.

(Just an opinion based on my implementation perspective.)

#g
--

At 11:02 03/07/03 +0100, Jeremy Carroll wrote:


>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

-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E
Received on Thursday, 3 July 2003 07:40:44 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:58:42 EDT