Re: pfps-08 last call comment on typed literals

Jeremy, see end of message.

>From: pat hayes <phayes@ai.uwf.edu>
>Subject: Re: pfps-08 last call comment on typed literals
>Date: Thu, 3 Apr 2003 14:48:40 -0500
>
>>  >From: Brian McBride <bwm@hplb.hpl.hp.com>
>>  >Subject: Fwd: pfps-08 last call comment on typed literals
>>  >Date: Thu, 20 Mar 2003 19:41:32 +0000
>>  >
>>  >>Date: Thu, 20 Mar 2003 18:56:18 +0000
>>  >>To: pfps@research.bell-labs.com, www-rdf-comments@w3.org
>>  >>From: Brian McBride <bwm@hplb.hpl.hp.com>
>>  >>Subject: pfps-08 last call comment on typed literals
>>  >>
>>  >>Peter,
>>  >>
>>  >>You made a last call comment "Comment on Last Call Working Draft of RDF
>>  >>Semantics document concerning typed literals" captured in
>>  >>
>>  >   http://www.w3.org/2001/sw/RDFCore/20030123-issues/#pfps-08
>>  >>
>>  >>After due consideration, the RDFCore WG has resolved
>>  >>
>>  >>[[RDFCore do not accept this comment. The semantics are as intended.  The
>>  >>text has been clarified to make this clearer.]]
>>  >>
>>  >   http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Mar/0124.html
>>  >>
>>  >>
>>  >>Please reply to this email, copying www-rdf-comments@w3.org indicating
>>  >>whether this decision is acceptable.
>>  >>
>>  >>Brian McBride
>>  >
>>  >
>>  >I do not view this reponse as acceptable because it does not point to the
>>  >clarification text.  There may also remain outstanding action items related
>>  >to this issue (namely pointing to Pat's message(s)).
>>  >
>>  >    http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Mar/0124.html
>>  >  >
>>  >  >
>>  >  >Please reply to this email, copying www-rdf-comments@w3.org indicating
>>  >  >whether this decision is acceptable.
>>  >  >
>>  >  >Brian McBride
>>  >
>>  >
>>  >I also do not view this response as acceptable for technical reasons:
>>  >
>>  >1/
>>  >
>>  >  From http://www.w3.org/TR/2003/WD-rdf-mt-20030123/
>>  >
>>  >In an RDFS interpretation I (see section 3.3)
>>  >          I(rdf:XMLLiteral) in ICEXT(I(rdfs:Datatype))
>>  >In a D-interpretation, for any D (see Section 3.4)
>>  >          ICEXT(I(rdfs:Datatype)) = D
>>  >
>>  >Therefore, in any D-interpretation, for any D, there must be a member of D
>>  >that is a standard datatype corresponding to rdf:XMLLiteral.
>>  >
>>  >This means that any set of datatypes includes a datatype for
>>  >rdf:XMLLiteral, and this datatype has a L2V mapping that takes lexical
>>  >forms (in the form of strings *without* language tags) to resources.
>>  >Any specification of D-interpretations must include this mapping.
>>  >
>>  >This superfluous mapping cannot be accessed from RDF, but can in OWL, for
>>  >example by
>>  >
>>  >          rdf:XMLLiteral owl:sameIndividualAs ex:foo .
>>  >          ex:bar ex:baz "55"^^ex:foo .
>>  >
>>  >I do not view this as an acceptable situation, if only for semantic
>>  >cleanliness reasons.
>>  >
>>  >This situation is not improved in the current editor's draft.
>>  >
>>  >2/
>>  >
>>  >Even if this issue were to be solved, I believe that OWL should have the
>>  >following sort of entailment hold:
>>  >
>>  >          rdf:XMLLiteral owl:sameIndividualAs ex:foo .
>>  >          _:x owl:sameIndividualAs "..."@en^^rdf:XMLLiteral .
>>  >          _:y owl:sameIndividualAs "..."@en^^ex:foo .
>>  >
>>  >entails
>>  >
>>  >          _:x owl:sameIndividualAs _:y .
>>  >
>>  >(This entailment holds for every URI reference except rdf:XMLLiteral.)
>>  >
>>  >However, there is no way for OWL to do this, because typed literals that
>>  >include ex:foo are interpreted by the rules for non-built-in datatypes and
>>  >there is no way to specify a non-built-in datatype that works the same way
>>  >as rdf:XMLLiteral.
>>  >
>>  >I do not view this as an acceptable situation.
>>
>>  Peter, could you articulate *why* you do not view it as acceptable?
>
>Isn't my discussion above sufficent? 
>
>The current treatment of rdf:XMLLiteral requires an extra, useless
>datatype.  This is going to be an endless source of confusion.  This, at
>least, has to be fixed.
>
>The basic idea of treating rdf:XMLLiteral as a datatype means that there
>are two different kinds of datatypes - I(rdf:XMLLiteral) and all the other
>datatypes.   The two different kinds of datatypes work completely
>differently, but there is no way of distinguishing between them.
>
>>  It seems to me to be inevitable that the built-in datatype will
>>  differ from other datatypes since it has a unique relationship to
>>  lang tags in the syntax. As you say, there is no way to specify a
>>  non-built-in datatype that works the same way as the built-in
>>  datatype. That is why we built it in, because it needed to be treated
>>  specially.  The consequence for OWL is merely that OWL is required to
>>  respect the unique status of the built-in RDF datatype, which does
>>  not seem to me to be a severely onerous requirement on either OWL
>>  users or the OWL spec.
>
>I disagree.  Every formalism built on RDF, including OWL, will have to have
>special cases for rdf:XMLLiteral.

It will have to handle this piece of RDF according to the spec, but I 
don't see why you consider this piece to be a 'special' case, it's 
just one of the cases. Yes, RDF treats XML literals in a special way, 
but it always has done. Time was when we had a special 'XML bit' 
included in every literal, if you recall.

>
>>  Allowing the entailment you describe would make the semantic picture
>>  somewhat more uniform, but it would also complicate the
>>  implementation in many ways. At present, an engine can take the
>>  presence of the datatype label "rdf:XMLLiteral" as a direct syntactic
>>  flag which indicates the need to parse lang tags in a particular way,
>>  without requiring any inference to be done. Since this treatment of
>>  lang tags is essentially a syntactic matter concerned with XML, to
>>  require all engines to indulge in open-ended OWL reasoning in order
>>  to check whether or not to proceed with a syntactic operation seems
>>  counterproductive to me.
>
>>  One option would be to say that in a D-interpretation (not a simple
>>  RDF interpretation) , rdf:XMLLiteral should be a 'fully-fledged'
>>  datatype, so that the inference you describe above would hold. It
>>  would mean that ex:foo would be obliged to handle lang tags in the
>>  same way that rdf:XMLLiteral does, note, so that implementations
>>  would be obliged to check that any user-defined datatype was *not*
>>  equal to rdf:XMLLiteral before treating lang tags appropriately.  Let
>>  me know if that would be acceptable, and if so then I will put it to
>>  the WG as a suggested change. I do not think it will affect any
>>  documents other than the semantics, and has no real impact on RDF
>>  reasoning as such, so would be an easy change to make.
>
>This would provide some sort of improvement, but I don't think that this is
>the right way to go.

It might be the best that we can do at this stage. We have already 
decided that all XML literals in the RDF graph are considered to be 
canonicalized, so that the datatype is kind of trivial except for the 
treatment of the lang tags. I do not, myself, understand the reason 
for this lang tags business, but I gather that for some people this 
is is a VERY big issue, so we are unlikely to change it at this stage.

>I think that the best way to go would be to remove rdf:XMLLiteral
>entirely.  It is a bastard amalgam of syntax and semantics that provides
>far greater pain than benefit.

Yeh, well, the world isn't perfect. Whatareyagonnado?

>
>If, however, it is not possible to remove rdf:XMLLiteral, then why not
>separate its syntactic and semantic components?  Simply make it be the case
>that the processing of rdf:XMLLiteral in the RDF/XML does all the
>non-standard stuff in the translation to triples (much like rdf:nodeid
>does).

We have done except for the lang tag business.

>   So the translation of
>	<subject>
>	  <predicate parsetype="rdf:XMLLiteral">
>	    [some text]
>	  </predicate>
>	</subject>
>into a triple would be something like
>	subject predicate "[some other text]"^^rdf:XMLDocument .
>where [some other text] included all the junk involved with rdf:XMLLiteral,
>including the language tag stuff.

Jeremy is the one to ask. Jeremy, can we do this?? Note that this 
would then mean that we could GET RID OF LANG TAGS IN THE GRAPH 
ALTOGETHER. Just thought I'd mention it in passing.

Pat

>  This would allow rdf:XMLDocument to be a
>standard datatype.  You could even use rdf:XMLLiteral instead of
>rdf:XMLDocument if you really needed to, but I wouldn't recommend it.
>
>>  Pat
>
>peter


-- 
---------------------------------------------------------------------
IHMC					(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola              			(850)202 4440   fax
FL 32501           				(850)291 0667    cell
phayes@ai.uwf.edu	          http://www.coginst.uwf.edu/~phayes
s.pam@ai.uwf.edu   for spam

Received on Thursday, 3 April 2003 18:43:23 UTC