Re: Comments on Last-Call Working Draft of RDF 1.1 Semantics

Hi Richard!

Am 07.12.2013 02:52, schrieb Richard Cyganiak:
> Hi Michael,
>
> An unofficial response from the sidelines.
> I always make a fool of myself when I comment
> on Semantics matters, so I’m already regretting this email.

Very good that you step into this discussion, as you
are one of the editors of the RDF Concepts document,
and I haven't had realized yet that my points hit
this document as well.

> But doesn’t http://www.w3.org/TR/rdf11-concepts/#datatype-maps
> answer your concern? It says that XSD IRIs MUST denote their
> respective datatypes. This is a normative for Semantics.

But what about all the other, non-XSD datatypes, that are
around (in OWL and elsewhere) or that can be invented as
custom datatypes (e.g. a datatype for representing complex
numbers)? What does the "MUST denote their respective
datatypes" mean then?

In the RDF 2004 spec, this was perfectly clear: once you have
provided an explicit datatype map D, i.e. a set of pairs <aaa,x>
of datatype IRIs aaa and their respective datatypes x (the
latter, for example, given in terms of a pointer to another 
specification that defines that datatype), then the "General
semantic conditions for datatypes", as defined in the old
spec, would do the rest for you, e.g. the first of these
semantic conditions is:

   "if <aaa,x> is in D then I(aaa) = x"

To be read as: "the datatype IRI aaa denotes its
'respective datatype' x."

Now, indeed, the old form in its generality allowed for
defining datatype maps where an XSD IRI is mapped to some
datatype which is not the corresponding XSD datatype.
Neither do I see this as a problem (it's like as you can
write non-terminating or "non-intuitive" programs
in any programming language), nor can such "evil" stuff
be excluded entirely, anyways. As I have pointed out in
my original mail, you can associate any XSD URI with any
other datatype easily as soon as you have equality in
your entailment regime, i.e., owl:sameAs. Of course,
with the restriction given above, this would then
easily lead to unsatisfiable RDF graphs, if the
value spaces of the datatypes are disjoint
(as it is the case for, e.g., xsd:string and xsd:integer).
But in any way there is no method to stop people from doing
crazy stuff. And as I said, I don't consider this not
to be a problem at all, let people fool around if they like,
I don't have to buy their stuff. And you have this option
of fooling around in virtually any (non-trivial) technology,
e.g. in programming languages, but no one ever complains.

But if the Working Group believes that it is still a good
idea to include such a restriction on XSD datatype IRIs,
then just add a sentence corresponding to the above one
to the spec:

   "Given a datatype map D and a mapping <aaa,x> in D,
   then if aaa is an XSD IRI, then x MUST be
   the respective datatype (as defined in the XSD spec)."

Then, you have the restriction that you want, without the
need to change the original representation formalism for
datatype semantics - the two things, datatype maps and
restrictions on datatype IRIs, have really nothing to
do which each other. Personally, I would be ok with this
treatment (knowing well that I can still happily garble
up the whole datatype semantics with owl:sameAs ;-)).

> Can’t specs that currently use datatype maps in their
> formalism simply continue to do so? They just need to
> state that the IRIs in the datatype map are considered
> recognized datatype IRIs (to be technically compatible
> with RDF 1.1 Semantics), and add a requirement that certain
> datatype IRIs, if present in a datatype map, MUST be paired
> with certain datatypes (to be compatible with 1.1 Concepts).
> It’s not like RDF 1.1 is outlawing the datatype map construct.
> It just doesn’t use it to define its own semantics.

Well, other specs may perhaps continue to use datatype maps,
but then imagine what an embarrassment this would be for
the RDF WG: by going on with the old datatype maps
even in the next spec, the other spec's WG would clearly
confirm that it prefers the old way over the new way,
so the old way has always been good enough for that spec,
while the new one is not good enough to switch to it.
Another round of spec wars in the SW...

But I think there may be a general misunderstanding here
of what I am about primarily. I'm not in the first
place interested in the question whether the particular
proposed change is appropriate or not (although I consider
it to be confusing, awkward, and a bad idea). What I am
primarily about is that there is no need for any change
whatsoever! It appears to me that the WG has easily
accepted such a need as a fact, but, as I have pointed
out in my longish earlier mail, all evidence known to
me goes right against such a need.

Datatype maps in their current form have been in use
so long and so widely and examined with such intense,
including by myself, and without any indication for
problems ever raised, that the only thing I can say
about it is that the original datatype semantics in
their precise form have to be considered robust
technology by now. The change, as also pointed out
by Antoine Zimmermann in his original discussion of
the topic, comes completely out of the blue now!

I mean, if there really was a problem, why hasn't
this problem been brought up during the LCWD or CR
phase of the SPARQL 1.1 spec, which was finalized just
in Spring this year? Has there been any discussion
between the two working groups on this change?

And if the problem was the issue with the "pathological
mappings" for XSD datatypes, then I have given a
solution above, without the need for replacing the
original notion of a datatype map. And again: the
proposed change would by no means remove that problem,
as I will always be able to fool around with datatypes,
if only I have enough semantic power, as with owl:sameAs.

I say that the original datatype maps were perfectly
ok, clear and simple enough, at least for me and
for several other WGs, and for several textbook writers,
and for several university lecturers, and so on.
The change does not solve any existing problem
(including the one discussed above), so why should
there be a change at all? So no problems, so no need for
a change, so no need to discuss the change by other WGs,
so no danger of interoperability issues, spec wars,
or whatever (and, on a personal note, no tons of mails
in the following years by people wanting to know from
/me/ how this new formalization relates to the good
old datatype maps they were accustomed to :-]).

So, please, just don't do anything about the original
definition of datatype maps, because there is absolutely
no need to change anything, because there's nothing wrong
with them - that's all I am wishing for Christmas! :-)

> Best,
> Richard

Cheers,
Michael

Received on Sunday, 8 December 2013 20:28:38 UTC