W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > November 2005

Re: CURIEs vs. QNames

From: Ben Adida <ben@mit.edu>
Date: Mon, 28 Nov 2005 11:56:20 -0500
Message-Id: <A7375775-A4F2-43C7-9FF3-0056ABD643A8@mit.edu>
Cc: public-rdf-in-xhtml-tf@w3.org
To: Dan Connolly <connolly@w3.org>


On Nov 28, 2005, at 11:14 AM, Dan Connolly wrote:

> Really? I don't believe so. I've seen comments from individuals,  
> but I don't recall the taskforce as a whole giving a position on  
> this. But I may have lost track of how the taskforce makes  
> decisions (which is easy to do, since the only charter(s) I can  
> find are expired.
> http://www.w3.org/2003/08/rdf-in-xhtml-charter.html#_Duration )

Dan, at this point, I feel that you're trying to bury the issue in  
bureaucratic technicalities.

I appreciate the importance of keeping proper records, but it seems  
silly to claim that no such decision has been made, when all task  
force members who have attended telecons semi-regularly have been  
diligently working on this requirement as a group without any  
internal dissent for more than 6 months.

By the way, the most recent charter and requirements are to be found  
in their expected location:

1) go to the Best Practices WG page:
http://www.w3.org/2001/sw/BestPractices/

2) click to the HTML Task Force page:
http://www.w3.org/2001/sw/BestPractices/HTML/

3) click through to the late 2004 charter and requirements:
http://www.w3.org/2001/sw/BestPractices/HTML/2004-10-12-charter
http://www.w3.org/2001/sw/BestPractices/HTML/2004-10-12-tf.html

Certainly, these documents need updating. Specifically they do not  
mention strongly enough that one of our main goals is reducing data  
duplication to help build maintainable HTML. That said, they're far  
more pertinent than the old link you're looking at. At the very  
least, the new links correctly list me as the task force chair, so  
Dom doesn't take the fall for my insanity :)

>>  and we're trying to find the time to put together all the  
>> pointers that clarify this requirement from all of our discussions  
>> and input from customers over the past 6 months.
>
> I look forward to more of that.
>
> It's risky to get into detailed design discussion in advance of  
> having requirements clear. Sometimes it's a good risk to take, but  
> sometimes not.

It's only risky if we are stuck discussing process for the sake of  
process, rather than the issue at hand. Sometimes requirements emerge  
as new customers join the debate and the task force adapts to the  
needs of the community. If anything, this task force has been  
diligently working to shoot down complicated alternatives, restrict  
the scope of work, and generally have a minimal impact while trying  
to solve issues that have been dogging the RDF and HTML communities  
for 6 years.

So, here are the pertinent questions and my best attempt at answering  
them according to Task Force discussions:

1) Should HTML authors be able to designate abbreviations for common  
RDF namespaces, like Dublin Core?

The task force believes the answer is YES. Taking into account the  
requirement that hand-authoring HTML with RDF/A be reasonably doable,  
it's inconceivable to require authors to fully cite the Dublin Core  
namespace URI in every property of every page. Web pages would not be  
maintainable without them. Customers like the IPTC wouldn't even  
consider RDF/A without these abbreviations.

2) Should these abbreviations be able to handle all valid RDF URIs?

The task force believes the answer is YES, again, as per the  
requirement that our solution allow for maximal RDF expression. This  
means QNames don't quite cut it. (Not to mention that the TAG says  
QNames shouldn't be used to abbreviate URIs.)

3) Should this abbreviation syntax overload the QName syntax?

Well, now there's the rub. We initially thought so, and I still think  
so, but there are good arguments against it, and we're currently  
discussing alternative syntax.

Which parts do you disagree with, and why?

-Ben
Received on Monday, 28 November 2005 17:29:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:15:00 GMT