Category Archives: Technical Issues

New Host

Since the beginning of the project, we’ve been running our own web server. After a significant number of local service outages on the part of Time Warner this year, particularly in July, we finally decided that had to change.

As of today, we’re running on Dreamhost. Dreamhost isn’t perfect, but they offer a nice package of services, reasonably good support and, with the right promo code, the price was right. So we’re going to give it a try for a while.

Moving from a host where we had complete control of the Apache and MySql servers to a shared host where we don’t has required some minor configuration changes to the blog and the wiki, and some significant changes to trac and subversion, but no changes to the Registry. As a side effect of the wiki tweak, we can have prettier URLs — http://metadataregistry.org/wiki/index.php?title=Main_Page becomes http://metadataregistry.org/wiki/Main_Page. Links will default to the new style, although the older form will still work in order to keep older bookmarks working too.

We updated trac and subversion to the latest stable releases, moved trac from a lighttpd server to Apache and moved subversion from a subversion server to Apache as well. This has changed the user authentication process for both services, hopefully for the better.

Mail is working again

If you tried to request your password and nothing happened, it’s because mail was broken on the server. Actually I had closed the port in the firewall a very long time ago and since a password request is the only thing that normally uses mail on the Registry, I hadn’t noticed.

Today I needed to register as a new user with this here blog (same server) and I didn’t get a password emailed to me! Oh, the sorrow.

It’s fixed now. Oh, the joy.

Blogging the DC2005 Architecture WG Meeting

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