Re: pfps-08 last call comment on typed literals

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.  

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

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.

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

Received on Thursday, 3 April 2003 15:48:11 UTC