There was a discussion about the possibility of creating copies of the dc namespace elements in the dcterms namespace. Despite my personal strong support, Andy decided that there wasn’t a strong consensus for or against and that it might be best to table the suggestion until some of the other architecture ‘earthquakes’ subsided.

Domains and ranges…
* Domain is a class of resources that a property can be used to describe
* Range is the class of resources that are allowed as values of a property
* goal: making explicit what is currently implicit

dc:creator was the prime example in which the creating ‘entity’ is generally presumed to be the equivalent of the ‘name’ attribute of the more abstract creator entity. In other words a string such as “Jon Phipps” which is, according to the definition, incorrect. So what’s really at the URI that identifies dc:creator? Don’t worry, it’s an RDFism (I’m not yet a fan). Well, talk about a sticky wicket!

The 1.5 hour discussion that ensued finally devolved into a choice between explicitly defining range and domain attributes for the existing dc URIs, thus breaking any applications that used that element incorrectly, or creating an entirely new set of URIs for dc, thus permanently branching dc and leaving data rendered using the current URIs to stew in their own global incorrectness. Se ha tirado alguien de pedo? (pardon my spanish) Alistair suggested creating a new namespace for the new URIs and declaring that namespace to be a private playground, giving the architecture group and other early implementors some time to get dc’s RDFishness more fully baked. No conclusions had been reached by the end of the meeting but Andy was definitely starting to look a bit fried around the edges.

Tom said later that at the beginning of the discussion 30 people thought they understood what was being discussed, but as the discussion wore on, that became 10 people, and then 5, then 2, and finally one, who explained it to everyone, this explanation being understood by 10, and then after a bit maybe 30. Rinse, repeat.

The most often expressed reason for the whole exercise was to make dc more attractive to folks who refused to use it because it was too fuzzy. My humble opinion? Well, I’m so glad you asked… Go ahead and do the new URIs, clearly identify them as a draft spec that WILL change, don’t break the current URIs, change the definition of the new URIs as much as you want, but make them very public. It’s important to keep the needs of metadata providers distinct from the needs of metadata consumers.

If both providors and consumers operate only in the same domain, then how they cook their metadata doesn’t matter. But consumers of other people’s metadata will always have to deal with a wide variety of flavors indefinitely. There’s no way around this, no way to make their life easy — look at how many browsers still support HTML 1.0 and how many web pages must be written to work in Netscape 4 or IE 3. Consumers will just have to deal.

Providers (this includes the group that dc is concerned with attracting) on the other hand will appreciate the tightened spec, even if it’s unstable — look what happened with XQUERY (yes I know there’s a bunch of people really unhappy with how long that’s been in draft) — and will move toward it. Plus everyone’s RDF is not fully baked and trust me, they’re as used to dealing with a changing spec as the dc architecture folks would like them to be. And besides, some people like and find value in fuzzy (me for one). Just my $.02