- From: Mark Birbeck <mark.birbeck@webbackplane.com>
- Date: Thu, 12 Jun 2008 21:52:27 +0100
- To: "Jonathan Rees" <jar@creativecommons.org>
- Cc: "Ben Adida" <ben@adida.net>, public-rdf-in-xhtml-tf@w3.org
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