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

Hello Jeremy,

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

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

So do you think that half-way deployment (in the sense that an
unsatisfactory solution is deployed) is better?

Just some background on why this argument which may look very
convincing to you may not really help you to convince us:

Traditionally, i18n people are not very sympathetic
to arguments such as "this will be doing the right thing for 80%
of the world, so let's do this rather than risk that things won't
be done at all". For i18n, 80% is just simply not enough.
Also, we are somewhat used to the unfortunate fact that i18n
features don't always get implemented first. We just had to
learn to live with 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).

If I understand this example correctly, an OWL parser that does not
support XML Literals will not be able to decide whether by chance,
<b>Good!</b> and <b>Bad!</b> might are actually the same after
canonicalization, and therefore may not see that there is a conflict
because there are two different property values for a functional
property?
[aside: The additional <span xml:lang='en'> looks strange.]

If that's true, then there will be similar problems for datatypes
such as float and double, and so on. Is that considered acceptable?

If that's true, then it also means that the RDF parser actually
does not do any canonicalization on the XML, nor that any RDF store
would seem inclined to do canonicalization on the XML. That seems
to me to be highly inefficient, i.e. in terms of actual implementations,
OWL tools should just choose RDF tools that do the canonicalization.
Whether for this to happen, the responsibilities of the two specs
have to be adjusted, or whether we can just assume that this will
happen naturally is something I'm not sure about.

If RDF parsers and RDF stores actually cannonicalize XML, then
the question is why would it be so difficult for OWL applications
to support it? Turned the other way round, when DanC asked us
whether we are okay that only string and integer types have
to be supported by OWL applications, we should probably have
asked to add XML Literals, because the benefit for i18n is
large while it seems that the actual cost on the OWL level
is actually rather low.


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

So do they actually do the canonicalization, or not?


Regards,    Martin.

Received on Thursday, 3 July 2003 11:51:46 UTC