Re: RDF speficiations (was RE: Cutting the Patrician datatype knot)

Peter F. Patel-Schneider wrote:
> >
> > Well that depends on what you mean by "addition"
>
> How?  What sort of additions could be possible?
>
> Maybe you mean that the implementation could provide additional
interfaces.
> Yes, I suppose that this would be allowable in a fully-conforming
> implementation, provided that the additional interfaces could be reduced
to
> the specified ones.  However, if the additional interfaces allow
> applications to make finer-grained distinctions than the specification
> supports, then the implementation is *not* fully conforming.

Right and that's why it is important to be totally clear about how XML
Schema might interface with RDF. My fear is that slapping this together
might cause subtle unintentioned problems (so far, I've been extremely
disappointed in the lack of coordination among various W3 WGs including RDF,
XSD, XLink/XPointer, XHTML etc.)

>
> Sure, and so, maybe, RDF is not in compliance with XML.  If so then this
is
> a problem that should be worked out in the Semantic Web Coordination
Group.

he he, it is clear that coordination with various XML related activities is
not often the highest priority.

>
> > [G]iven this draconian (yet well specified) definition what makes anyone
think
> > that "10" and "010" would be equated under RDF itself?
>
> Under RDF itself, there is, of course, no way of determining that "10" and
> "010" denote the same value.  However, a datatype extension may end up
> requiring that "10" and "010" denote the same value in some circumstances.
> Under these circumstances an implementation of the extended RDF *must*
> behave accordingly.  To claim that an implementation of the non-datatype
> RDF is in conformance with the extended RDF if it has different behavior
> is just not correct.

Certainly. Yet the point remains that the XML Namespaces definition of how
namespaces are to be compared (literal string) is not how many people want
to compare URI references ... the whole xml-uri@w3.org "debate" (thousands
of emails by hundreds of people talking past eachother) highlights the
issues that will continue to plague efforts at creating interoperable
specifications if people don't carefully think through the details of these
specs. In many cases different groups have different goals and thus it
simply may not be possible to reuse work.

> > But suppose I create my own datatypes using XML Schema, including
> > myxsd:integer which derives entirely from the lexical space (i.e. is
defined
> > by which characters are allowed in each position in the string). Now I
> > submit that there is a clear and unambiguous 1:1 mapping from
> >
> > myxsd:integer <=> xsd:integer
> >
> > that is that the instance sets of tokens that form each type are
identical.
> > XML Schema provides no way to define this (I choose in this case _not_
to
> > derive myxsd:integer from the builtin, i.e. value space derived,
> > xsd:integer)
>
> If you define myxsd:integer as something that defines a lexical-to-value
> mapping in a different way than xsd:integer does, then, of course any
> implementation of RDF plus datatypes that understands whatever method you
> used to define myxsd:integer must follow your definition.  If the value
> space of myxsd:integer is the same as the value space of xsd:integer and
> the lexical-to-value mapping is the usual one, then, again of course, the
> RDF plus datatypes implementation is *required* to answer affirmatively
> that <John> <age> <myxsd:integer:010> entails <John> <age>
<xsd:integer:10>
> Otherwise the implementation is non-conforming.  How can it be otherwise?

Aha! But do you assume that the requirements you have outlined above are
implemented by a particular XML Schema validation interface?

This is my entire point, even though it is quite apparent that two types are
equal (their instance sets are identical), discovery of such type
equivalence is not necessarily possible by a type system that uses
_hierarchy alone_ in determining type algebra operations i.e. are two types
equal, supersets or subsets. An _explicit_ type heirarchy tells you this
"because I say so", but more generally a type formalism allows such type
equivalences to be computed from the equations that define the types
themselves.

>
> > In such cases an XML Schema validator will correctly validate the _XML_
> > input, but derive a unique post-Schema validation Infoset (psvi)
according
> > to which schema was used to validate. Are you are suggesting that ? the
> > datatype model theory operate on the "psvi" graph rather than the input
XML
> > character stream?
>
> The behavior of RDF plus datatypes must be fully specified in the RDF plus
> datatypes specification.  If it is possible to implement a significant
> portion of the specification using an XML Schema validator, either because
> the specification explicitly references XML Schema datatypes or in the
> extraordinarily-unlikely event that the independently-specified RDF plus
> datatypes specification happens to have a close semantic relationship to
> XML Schema datatypes, then that is a (very) happy occurence.  I happen,
> moreover, to believe that it should be the goal of the RDF Core Working
> Group to build any RDF plus datatypes specification so that this is the
> case.

I wholeheartedly agree. My point is to expose some of the possible seemingly
insignificant inconsistencies so that any holes might be appropriately
plugged. Working with types like "integer" is relatively simple because we
all know one when we see one (it is a simple type). XML Schema provides a
framework for defining an unlimited number of complex XML types, and until
the issues regarding XML and RDF are better sorted out, datatypes in RDF,
insofar as they include XML datatypes, is going to be frought with
difficulties. Thankfully formalisms _do_ exist for defining XML lexical
types (e.g. references in http://www.openhealth.org/RDF/RDFSyntaxFormal.html
, XDuce http://xduce.sourceforge.net ). You can see that the pattern that
describes the RDF XML 1.0 syntax itself is reasonably compact. (such
formalisms do not trip up on the very basic <foo></foo> vs. <foo /> issues
that trip up the psuedo-EBNF grammars).

Jonathan

Received on Monday, 3 December 2001 18:33:30 UTC