Re: Comments on "RDFa in XHTML: Syntax and Processing"

Hi Jonathan,

You haven't said who will buy the beers! :)

I realise that you are resigning yourself to that fact that the moment
for this discussion may have passed, but at the same time I hate to
let something as important as this pass by. I therefore feel compelled
to respond, even if my response is not 'official'.


> I understand you are way past being able to take any nontrivial suggestions,
> so I'm not sure how what I say can matter.

I'm not sure if that is true, but I'll leave that to others more
versed in the W3C process to respond to. I would prefer to explain why
your issue was rejected on technical rather than procedural grounds.


> My answer is no, it is not acceptable, as I don't feel whoever replied paid
> attention to what I said. I was not talking about CURIEs; I was talking
> about the syntactic category URIorSafeCURIE (which I am very glad to see you
> renamed - thank you). I had four sub-points and these were not addressed,
> and it sounds like the comparison between [...] and a URI scheme was taken
> seriously.

I guess you mean *not* taken seriously. But I feel Ben responded
correctly, and we *did* take into account your four points. I'll go
through your comments.

Your original comments were:

  Hal Abelson of MIT pointed out to me that the [...] syntax
effectively introduces
  a new kind of URI - it extends the URI space.

This is not the case. We explicitly aimed to provide a mechanism to
*abbreviate* URIs, but wanted to ensure that the end result of the
expansion was simply a URI. I think Ben addressed this in his
response.

Note that one of the key drivers behind creating CURIEs is the strong
feeling that using QNames to achieve URI abbreviation is essentially
wrong, since it makes use of a mechanism that was created in XML in
order to provide qualified element and attribute names. The 'URI
abbreviation' aspect of QNames has been used in Turtle, N3, XML
Schema, RDF/XML, and many other languages, some of them not even
XML-related. We felt this was 'bad architecture'.

The architectural aspects of the issue might have been acceptable if
it was possible to express all URIs with QNames, but it isn't. So we
were presented with a bad architecture, that didn't even solve the
problem it was supposed to solve!

CURIEs was therefore proposed as a way to do this right, but
crucially, in a way that was backwards compatible with QNames.

You also said:

  However, we already have a standard way to extend the URI space,
  namely the creation of new URI schemes.

You are right, but hopefully I've explained why we are most definitely
not creating new URIs. If we did, we'd still have our original problem
which is how to abbreviate URIs. You then asked if we had consider
alternatives:

  Did you consider doing this (curie:prefix:suffix or cu:prefix:suffix or ...)?

and yes...that kind of solution was raised many times. :)

The four points that you referred to began:

  It would have some advantages over [...]:

    . it would eliminate the need for a new URIor[safe]CURIE datatype
      since you could just use URI

But we wanted a language-independent mechanism for *abbreviating*
URIs, not a new way to mint URIs. Your second point was:

    . it would protect against possible conflicting future extensions of
      the URI space that include [...]

We feel that we do have this protection, and that it comes about by
introducing the notion of 'safe CURIEs'. We advise that they are to be
used in any situation where a CURIE could be confused with a URI.

Your third point was:

    . it would avoid ambiguity with relative URIrefs that happen to be
      spelled [...]

You are right, and this was an issue that did occupy a lot of time.
But we have provided many mechanisms (default prefix mappings,
constant string mapping, etc.) that allow language authors to choose
how such values should be dealt with.

Finally, you said:

    . it would avoid setting a precedent; by introducing [...] you
      pave the way for other notations that extend URI syntax in other
      ways, e.g. {...}, <...>

Hopefully it's now a little clearer that we are not touching URIs, but
creating a mechanism to abbreviate URIs.


> If you had said, we're too late in the process to think about anything like
> this, which I suspect is the true answer, that would have been better.

That really isn't the true answer...the problem with your proposal is technical.

Ben pointed your comments out to the group as soon as they were made,
and we discussed them--I recall your proposal had some support, too.
But in the end the conclusion was that we don't get what we need by
adding another URI scheme.

(Note that there is something not quite right about using a new URI
scheme as an indicator that you have an abbreviate URI. I'm no
mathematician, but I'm sure Godel would have something to say on
this.)


> Looking back - there was a probably a time, before I was involved, when we
> might have had an opportunity to do a cleaner architecture, one that could
> grow to be used uniformly throughout future W3C recommendations.

I have to take issue here; if you mean a time BC ('before CURIEs')
then I disagree with you. Given what we were working with--which was
both the legacy of QName proliferation, and the use of fixed values in
@rel/@rev--then I think CURIEs is about as good as we could do, and
it's pretty clean. (Actually, I'd go further and say it's quite
impressive.)

Of course, if you mean a time before the us of QNames to abbreviate
URIs, then sure...we'd all like to have seen that done differently.
And we would never have needed CURIEs.


> It might
> have been based on some radical change such as joining the CURIE and URI
> syntactic categories...

I still would like to stress though, that having URIs and abbreviated
URIs in the same 'space' is extremely problematic.


> ...thus doing away with the CURIE/Safe CURIE distinction
> which I think is going to be confusing to users (it's confusing to me); or
> if that turned out to be nonsense, then some other radical proposition. It
> is unfortunate that what we've ended up with is such a compromise.

I'm with you on the sentiment. :) But the compromise was caused by
QNames, not by CURIEs.


> Anyhow - not to worry about any of this - there's not a lot of point in
> answering me except over beer. I don't mean my comments to be at all
> hostile. Good work, RDFa will be a big help I think, now let's figure out
> how to use it and spread it.

As Ben said...many thanks for your good wishes.

I hope you don't mind the long reply; I just wanted to reassure you
that your proposal really was taken seriously, and was discussed at
length, but ultimately it doesn't achieve what we need.

Regards,

Mark

-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Thursday, 12 June 2008 20:53:18 UTC