RE: XML Schema is untidy (was RE: type test case)

> -----Original Message-----
> From: ext Graham Klyne [mailto:Graham.Klyne@MIMEsweeper.com]
> Sent: 08 August, 2002 18:13
> To: Stickler Patrick (NRC/Tampere)
> Cc: w3c-rdfcore-wg@w3.org
> Subject: RE: XML Schema is untidy (was RE: type test case)
> 
> 
> At 12:18 PM 8/8/02 +0300, Patrick.Stickler@nokia.com wrote:
> > > It appears that community feedback is that that's exactly
> > > what we ought
> > > to be doing (for a small set of datatypes)
> >
> >I didn't see any substantial feedback suggesting this.
> >A few outspoken respondents does not constitute an
> >overwhelming concensus of community feedback.
> >
> >Furthermore, the inquiry to the community had nothing to
> >do with this, and the proposals reflected in that inquiry
> >provide *full* support for all XML Schema datatypes.
> 
> I think it's worth recapping how we got to the current point 
> of debate.
> 
> This is, of course, a personal interpretation and I'd be happy to be 
> corrected by others.
> 
> Following Brian's question to the wider community, it seemed 
> clear that we 
> were *not* going to get a clear answer to the point we were trying to 
> resolve.  To my view, and I think to that of others, there is 
> no clear 
> consensus concerning the tidy vs untidy question.

But the tidy versus untidy question is a MT issue that *must*
be resolved.

If it is not clear which is correct, then an untidy intepretation
does the least harm to RDF, as it is then possible to choose
between tidy (string-equal) and untidy (resource equal) tests
for equality.

The tidy versus untidy issue still needs to be decided, even
if we opt-out on global datatyping.

> Thus, we were in danger of creating a recommendation about a 
> matter whose 
> ramifications are not adequately understood.  In such 
> circumstances, it is 
> better to be less ambitious -- better to leave something (clearly) 
> unspecified than wrongly specified.

Well, I can't see that the community was able to fully review
the DT proposal based solely on Brian's execellent but very
terse summary. The WG agreement, as I remember it, was to
decide on tidyness and get the WD done and out to solicit
*real* comments from the community.

Publishing the stake-in-the-ground as a WD is not writing it
in stone. I do not believe the community has been given a
sufficient presentation of the previous proposal to offer
any meaningful comments -- considering the number of misconceptions
and misunderstandings reflected in the responses to Brian's inquiry.

> Next, it seemed that there *is* consensus about the meaning of:
> 
>      :Jenny :age _:x .
>      _:x type:integer "10" .
> 
> i.e. the so-called "local idiom".  

Exactly. So where the heck do native RDF datatypes suddenly
come into the picture with a new node type for datatyped
literals?!

> It is the global idiom 
> that is proving 
> difficult to pin down.  Maybe, we are chasing a chimera and 
> shouldn't even 
> try to realize that (global datatyping) form, however attractive its 
> attributes may appear.

I feel that would be a failure to provide an acceptable
datatyping solution.

> Further, this "local idiom" doesn't require any change to the 
> basic RDF 
> model theory, (other than possibly to note the data type 
> mapping is fixed 
> separately from the rest of the interpretion).

Agreed.

> At the last teleconference, it was pointed out (and generally 
> accepted) 
> that to publish an RDF recommendation without a good account 
> of how to deal 
> with something as pervasive as numbers would be a grave 
> disservice to the 
> RDF community as a whole.

Eh? The point of RDF Datatyping is to provide a way to
communicate datatypes values of any kind which have
lexical representations and where those datatypes conform
to the basic model of lexical space, value space, and
N:1 lexical to value mapping.

RDF is not *supposed* to provide an account for numbers,
anymore than it is supposed to provide an account for
blarg codes, other than the fact that (int, "10")
or (blarg, "78470187340982q3r8*&^(*&^RWE(*@") each
globally, unambiguously, and consistently denote a single
datatype value. *What* that value is is outside the
scope of RDF semantics, and it would IMO be a grave
disservice to the RDF community as a whole to lose
that genericity and neutrality.

> This is roughly the point at which you have rejoined the 
> debate, 

Actually, I have been following the discussion list the
whole time, even though I have missed the telecons. Still...

> at a time 
> when the choice between the triple-based local idiom, and 
> extending the 
> notion of literals to include well-defined denotations of 
> numbers (and 
> maybe other values) as well as strings, has not been finally nailed 
> down.  (But I think the group is leaning toward the notion of 
> extended 
> literals -- that's the essence of Sergey's proposal.)

Well, it seems far too late in the program to be tossing
such proposals on the table. It should be noted and 
put on the wish list for RDF 2.0.

> >The WG has *agreed* that any deviations from the stake-in-the-ground
> >proposal would be motivated by clear technical and practical
> >considerations -- i.e. fatal flaws or errors in the proposal.
> 
> This is a change of tack from what we were trying to do 
> previously, and one 
> which is motivated by a very strong technical and practical 
> considerations:  

I've yet to see any detailed summary of those motivations.

I've seen Sergey's proposal, but no minutes or other writeup
that would clearly demonstrate the need to be considering
such a proposal. 

> without cutting back the scope of the 
> problem in this way, 
> it is likely that this working group will never finish.  

Certainly if the process is not followed.

> More 
> than anything 
> now, we need to finish.

I considered that we were already 99% finished, with only
one issue left to resolve.

The desire to have native datatypes, if only a few, is new,
too late, and IMO completely out of scope for the WG.

I agree. We need to finish, and if we stick to what was
agreed upon in Bristol, we could.

> Yes, there are details to iron out, 

Lots!

> but compared with what we 
> were trying 
> to do they are small details.  

Small? I think not. I've brought up several, and only
the most major ones. And that's only after chewing on
it for a short time.

> If we get them wrong, the 
> result will be 
> some small inconvenience rather than possible severe damage 
> to the whole 
> RDF framework.

I consider what is being proposed to be severely damaging to RDF
and also nearly completely failing to provide a solution to
datatyping which meets the desiderada and needs already agreed
upon.

> And I think the "stake in the ground" still remains:  I think 
> nothing we're 
> trying to do now is inconsistent with the stake-in-ground 
> principles, 

Eh? I can't even recognize the stake in the ground proposal in
what Sergey's writeup outlined!

If anything, it's just the local idiom portion of the URV proposal 
in different dressing. 

Now, if this were 6 months ago, I'd be happier with it, presuming
that we also were going to provide for global datatyping, but
it is not a subset of the stake in the ground proposal.

> but 
> we are trying to do less so the full reach of that stake may 
> not be needed.

I certainly consider that global datatyping is needed, as
is a means of integration with RDFS range semantics. The
new proposal addresses neither.

> PS: looking back, I suspect Brian foresaw much of this back 
> in Cannes, when 
> he suggested concentrating on the "local idiom".

And the reason why that suggestion was not accepted
was because a solution for global datatyping and
the assertion of datatyping constraints is sorely
needed.

Patrick

Received on Friday, 9 August 2002 07:48:33 UTC