One final step to datatyping convergence and closure?

I am very grateful to Pat for his execellent summary of the convergence
proposal in terms of his proposed MT treatment and to Jeremy for his
earlier distillation of it into specific issues. I feel that within
these can be found an excellent solution to the datatyping issue.

The following (hopefully) explains why I feel it is in the users'
best interest to adopt the convergence proposal without the datatype
triple idiom detailed in section 3 of Pat's summary (which actually
was not included in the original convergence proposal specifically
for the reasons outlined below).

I've tried to be relatively terse, which I think will be appreciated.
If any particular statement is not clear, just ask and I will gladly
expound upon it until it is clear or until you start throwing heavy
objects ;-)

As with my convergence proposal, please read the whole thing before
responding/reacting to a single particular statement, as most are
qualified/explained in subsequent paragraphs.

OK, here goes...

1. The datatype triple idiom is not needed, and has no actual utility.

a) The idiom does not do anything that doublet idiom does not do,
except allow multiple types to be explicitly defined for same bNode,
yet:

b) The ability to define multiple types for same bNode will, I
think, rarely be useful even even more rarely used, and:

c) The utility of such multiple type definition is an illusion
since it doesn't remove any untidyness in value comparisons because
doublet and global idioms still exist, and also there may be separate
datatype triples which denote same value.

Thus, the datatype triple idiom actually does not offer any real utility.

2. The inclusion of the idiom does not meet the "KISS" desire of users.

a) Since not needed, it merely adds complexity both for users and
implementors.

The point of a standard such as RDF is to provide a consistent,
explicit point of intersection between knowledge producers, knowledge
consumers, and application implementors which facilitates efficient
implementation and interoperability. Including needless components
for the sake of style or preference which impact portability of
knowledge and interoperability of systems, or needlessly complicate
implementation or use of such knowledge are contrary the very point
of such a standard.

b) It is not as symmetrical with the global idiom, therefore harder
for users to understand its relationship with the global idiom than
is the doublet idiom.

RDF is already widely percieved as "difficult to understand" and
"difficult to use". The last thing we want to do is make it any
more difficult by making the datatyping solution needlessly
complicated.

We have an opportunity to provide a solution based on two clearly
and intuitively related idioms which help users understand the
relation between typed literals and the datatype that provides the
context for that typing. The superfluous, more complex datatype
triple idiom undermines us providing the simpler, fully symmetrical
solution.

c) It requires schema definitions to use -- and thus it is not a
schema-free local idiom, which was the whole point of providing a
local/explicit idiom.

One must define each datatype as an rdfs:subPropertyOf rdf:value
in order for the MT interpretation to work. Thus, the idiom does
not meet the desiderada of either a local/explicit or global/implicit
idiom, but is a kind of strange hybrid that needs both local
definition and schema definition to work.

3. The idiom forces the qname issue.

The XML Schema community strongly dispute RDF qname practice as
valid and an idiom that requires the use of qnames puts us deep in
the middle of that issue -- which likely cannot be resolved within
the boundries of our present charter.

One has no choice but to use qnames to use the datatype triple
idiom, whereas the other idioms work with full URIs and avoid
this issue entirely.

Why exacerbate this issue needlessly?

4. Its interactions with rdfs:subPropertyOf are not clear.

a) Datatype properties only make sense with a bNode domain. We must
either somehow restrict the use of datatype properties to bNode
subjects or explain to users why they should do that, making more
work for us and more for users to understand. If not restricted in
this fashion, then:

b) What does it mean to combine datatype semantics with "traditional"
property semantics? If some property such as ex:age is declared as
a subproperty of xsd:integer, what does that mean? Should it even
be allowed (per (a) above)? Should users be advised against it,
and why/how? Again, more questions to be answered and addressed by
the MT, the primer, the spec, or elsewhere.

c) Cohabitation with doublet and global idioms not yet certain.

See my comments in my reply to Pat's summary which detials a
potential erroneous inference based on combined use of all three
idioms (sorry, offline, but should be easy to find).

Even if the MT could be re-re-re-vamped to address these issues,
that's unnecessary work, since we have a local idiom (which is a
true local idiom not requiring any schema assertions to be properly
interpreted) and the single percieved benefit of the datatype triple
idiom is, as explained above, an illusion; so what's the point in
continuing to try to make the idiom work (apart from just stylistic
preference)?

--

Thus, the combined weight of all of these issues regarding the
datatype triple idiom is, I feel, overwhelming, and we will be
serving RDF users far better by giving them a solution based only
on the symmetrical doublet and global idioms.

If we take the original convergence proposal and Pat's MT for it,
sans the datatype triple idiom, then we can be done with datatyping.
I repeat, done. Whoohoo!

Please, please, please, let's drop this extra idiom and move on. OK?

RDF users, both present and future, will thank us. Really.

Cheers,

Patrick

Received on Friday, 8 February 2002 17:07:15 UTC