1. Make sure you have sufficient wireless connections and bandwidth for the main paper presentations, not just the meetings and workshops. This means full bandwidth availability for 200+ contiguous high-bandwidth users. This is the 3rd DC conference that I’ve attended (0 for 3) that had trouble with this, but it’s a more significant problem now. With live blogging and microblogging on the rise consistent access is critical.
2. Make sure that there is power available for at least half the participants in every venue. Ten outlets for 300 people, or 2 outlets for 50 people in the workshops is just not enough.
3. Prominently and ubiquitously recommend an official conference tag for use on social networks.
4. Include a T-shirt in the conference swag. This will promote the fact that you were the host far into the future. Even if you don’t want to spend the money to include a t-shirt for everyone, make one available for an additional fee (not recommended but better than no t-shirt — DC2008 had an especially nice t-shirt but it was only available for conference staff).
5. Give the conference staff, and especially tech support, hats or radically different t-shirts and instruct them to wear their t-shirts/hats at all times that they might be in contact with attendees
6. Provide an official IRC channel, record it, and make the archive available on the conference web site (like code4lib)
7. Provide an official conference social network, such as CrowdVine
8. Officially video all of the open meetings, workshops, and plenary sessions for either live-streaming or future upload to YouTube. Make sure every presenter knows that they will be recorded and that the video will be publicly available at some point. Let attendees know that too.
9. Provide as much of the conference-related information and proceedings as possible on at least a memory stick (DC2008 did this). A conference-branded (rather than vendor-branded) thumb drive that is as big as you can afford would, like the t-shirt, promote your hosting of the conference well into the future.

Got dog?

After the SKOS face-to-face in Amsterdam last October and after my mother’s 6-week stay with us after knee surgery in January, it looked like I’d be home for a while, and life in general had calmed down. So in April we adopted a ‘puppy‘ from the Humane Society — a smart, 6-month old, 60-pound Labradoodle who came partially trained but with some bad habits. We think the bad habits — which included opportunistic newspaper/magazine shredding, furniture destruction, and wildly tearing around the house at top speed — may have contributed to his being left at the pound by his previous parents.

Nearly all of these habits have been cured or outgrown in the last 3 months and he’s gotten quite a bit of extra training, so Toby‘s turning into a pretty good dog (thank goodness). Getting him there has taken more work than we expected — our previous dog was 15 when he died and the dog before that was 17, so we’d totally forgotten how much work a puppy can be — and there’s still a lot of work to do. He ‘chews up’ quite a bit of of my day and isn’t always a pleasure, but it’s still nice to have a dog around again.

In May the relative ‘calm’ ended.

Got gas?

There’s natural gas in our area and we’ve been fending off ‘opportunities’ to lease the mineral rights to our 20 acres for years. This was easy because lease prices have always been in the sub-$100/acre range, but in May lease offers suddenly shot up to $2,500/acre and more, with royalties as high as 18% of gross, and it became a less easy decision. A local coalition formed to negotiate terms with the gas companies and there have been many meetings, discussion groups, and controversy.

The recent rush is largely due to a combination of a new deep discovery — the Marcellus Shale, 2 miles down — high gas prices, and improvements in horizontal drilling and extraction processes. The ‘improvements’ involve pumping millions of gallons (per well) of water, chemicals (many toxic), and sand into the shale at high pressure to force out the gas — a process know as fracing, a word familiar to fans of Battlestar Galactica with much the same meaning. This has raised questions about where the water will come from, and where it will go when it’s extracted along with the gas. The extracted water is very salty, sometimes mildly radioactive and laced with chemicals — as many as 10,000 gallons of toxins per well.

The state regulators are demonstrably clueless, the state legislature is eager for gas company money (recently making it much easier to get a drilling permit), and despite the promise of a nice chunk of change we’re very worried that our quiet rural area is on the verge of destruction. The Governor has required the regulators to do a thorough environmental review before granting new drilling permits, so that helps. But many of our neighbors have already signed leases, and we can be forced into a no-restrictions lease under current legislation if 60% of a drilling area has been leased. We’re probably going to sign a highly restrictive lease so that we have some control, but it’s a constant background worry.

Got job?

In April a review of my grant indicated that Cornell would run out of money to pay me by the end of May, so we adjusted my salary to .2 FTE, meaning I get paid for one day a week, and will certainly be leaving Cornell when my grant runs out in September. I’ve had to focus more on consulting and haven’t been able to work continuously on the Registry this summer as I had planned. Although I’m still working on it 20 or more hours a week, I feel much less focused and much less productive.

Got married????

In May, my mother (85) announced that an old family friend (Rodney, 89, widower) had asked her to marry him and she’d said yes. The wedding would be in September, she was moving to Cooperstown (90 minutes away) after the wedding, and would we sell her house and help dispose of the contents. The house was built by my paternal grandfather in the 1920′s and she’s lived there for 60 years, so there’s a lot of contents. Two weeks later, they moved the wedding date to June 29 and since she wouldn’t be spending the summer at the cottage on the lake, she asked if could we take over maintenance of that too. Things got busy in a hurry, and we put the house on the market, helped her move, and cleaned up the house (still chock full of stuff) for a series of open houses. We still haven’t decided what to do about the cottage, and it’s just sitting there this summer, open but neglected. The house, in a nation-wide falling real estate market, has generated a lot of interest but hasn’t sold and I worry we overpriced it.

Got sick

The week before my mother’s wedding in June, my mother-in-law (Olga, 87, who lives near New York City, 3 hours away from us) ended up in the hospital with diverticulitis. Fortunately my sister-in-law was with her at the time, but my wife (Barb) still rushed down to help out (nobody in our family is ever alone in the hospital). Olga, feeling much better, went home from the hospital the day before my mother’s wedding (Barb drove directly from NYC to the wedding).

One week later (we’re into early July) Olga was back in the hospital suffering from a reaction to the antibiotics she was given for the diverticulitis — she was extremely weak and having trouble with her heart. This time we all went down and helped ease her transition into a nursing home for what was initially supposed to be just a short stay for rehabilitation. We had high hopes that she’d be able, and maybe even willing, to stay there permanently since it didn’t look like she’d ever be able to go back to her 3rd-floor walkup apartment and continue to live alone.

Barb and I and her sisters took turns going to NY for 3 weeks until it looked like things were stable, the nursing home staff could be trusted (or not), and we were fairly confident of the quality of her care. But we’d only left her alone in the nursing home for less than a week, when she was taken to the emergency room, suffering from pneumonia, and an overdose of blood thinner, coughing violently and vomiting blood. The same day, Olga’s sister-in-law (Alice, 90, my wife’s father’s sister), who had been in the same nursing home, went to a different hospital with pneumonia, a blood thinner overdose, and an infected gall bladder. I packed up my office so I could work if possible, and we rushed down to NY where we proceeded to shuttle back and forth between the two hospitals.

Got guest!

After a week in the hospital, we brought Olga home to live with us permanently (that was 2 weeks ago). She continues to be too weak to do stairs and all of the bedrooms are on the second floor, so we’ve converted the dining room into a bedroom of sorts until we can figure out a better arrangement. Setting her up with a new complement of physical therapists, visiting nurses, and doctors has been quite a challenge and it’s a very good thing that my wife’s a school social worker — she knows the agencies and has the summer off. We’re also making arrangements to clean out Olga’s apartment and redistribute the contents.

My wife’s aunt died last week, unable to survive off the respirator that surviving the pneumonia had required, and Olga, Barb, and I made yet another trip to NY for the funeral. The wake and funeral service may have been the last chance Olga’s many friends will have to chat with her and it was nice to see how many did — there’s was a significant traffic jam in the church after the mass as mourners said hello and goodbye.

Meanwhile, back in Cooperstown, my new stepfather returned from the honeymoon and almost immediately went into the hospital. His back had been bothering him for several weeks, and the long car ride home from New Jersey pushed him over the edge and after several days at home of worsening pain my mom called 911. After a couple days of tests the doctors diagnosed a large abscess on his spine and 9 hours of surgery and two weeks later he appears to be on the mend. Olga, Barb, and I drove up there on Sunday to visit them and had a lovely brunch with my mom at the Otesaga Hotel on lake Otsego.

Get gone…

This week has been all about trying to clear up loose ends because tomorrow my wife and I leave for two weeks on Vancouver island for a much needed vacation. My wife’s sisters will take turns coming down from Albany to stay with Olga so we can relax a bit. One of her sisters arrived today with her puppy, which will be ‘interesting’.

Get back…

When we get back I need to quickly put together a short talk I’m giving with Ed Summers at the CENDI/NKOS workshop in Washington September 11th. The last time I attended a meeting out of town on September 11 was in NYC in 2001. I hope this one is much, much less eventful. And almost immediately after that I head for Berlin (the one in Germany) to attend the Dublin Core annual conference where, uniquely, I’m not presenting or helping to present a paper. Maybe, just maybe, after that things will calm down.

It’s been quite a summer.

For purposes of discussion, we have a draft schema property interface that defines some basic metadata schema property properties. We started the conversation because I was trying to get away from the “property property” nomenclature and because I couldn’t quite figure out the best way to extend the too-simple model to incorporate repeatable, typed notes/annotations.

Over the course of the discussion we came to a few conclusions:

• What we’re really discussing is an Application Profile in the old DC sense of that term (it has since been changed to “Description Set Profile” to reflect the more DCAM-centric viewpoint of the current DC Community) in which we’re defining schema property restrictions, namespaces, and usage requirements: There can be only one token, definition, label, type and they’re required; ‘Type’ utilizes a controlled vocabulary containing the concepts ‘property’ and ‘subproperty’; etc.
• We have a Schema Properties Vocabulary registered that identifies these schema property description ‘terms’ as ‘concepts’, but this isn’t really correct because they’re actually properties of a metadata schema ‘property’ (and so we’re back to property properties <sigh>) and as such they should be registered as an Application Profile rather than a Vocabulary.
• The properties of each schema we register should be based on its own Application Profile, since there will be many different requirements and we’d like to provide some flexibility. For instance the RDA schema may need to have an additional property property that declares a relationship between the property and a FRBR entity.
• We can’t register a Metadata Schema Properties Application Profile until we can register a Schema
• In order to register a metadata schema we need a generic Metadata Schema Properties Application Profile
• We’re stuck with “property properties”
• This stuff makes my head hurt

In the interest of moving forward, stopping the spinning, and headache relief we’re going to pretend that a generic Metadata Schema Property Application Profile (MSPAP — pronounced ‘ems-pap’) exists and slap something together and make the interface fairly inflexibly tied to it. At some point in the future we’ll (hopefully) make it flexible enough to be based on any registered MSPAP.

So how do you create a standard methodology that supports both approaches? A dozen years or so ago, Dublin Core provided a particularly elegant solution: a ‘simple’ set of ‘core’ metadata elements that could be ‘qualified’ by a 2nd set of elements that represented extensions of the simple 15 but could still be understood by those systems that didn’t want to mess with the extensions (using the unfortunately named DC principal of ‘dumb-down‘).

This 2-layer standard makes it possible for systems that can’t handle the more complex qualified DC to continue to interoperate with systems that use the richer extensions. It also makes it possible for catalogers to indulge their understandable desire for perfection and completeness while allowing relatively simple-minded systems like search engines to use their data with minimal conversion. Despite the fact that such conversions inevitably result in less precise metadata, the semantic integrity of the metadata is maintained because the people designing the standard thought hard about whether each qualified statement would retain its semantics in a less semantically-rich (dumber) environment. It also makes it possible to easily convert domain-specific simple DC to qualified DC by applying a few simple rules, meaning that systems that require qualified DC can still make use of simple DC.

So how does this relate to RDA? Well, one of the things that every community trying to define an RDF-based standard has to deal with is legacy data and systems that have traditionally stored property values as literals (strings usually) when identifying the property value as a resource may be far more desirable in RDF. One of the more important considerations is whether the ‘range‘ (what a RDF reasoner may logically infer the object of the statement to be) of an RDF statement (a single triple) will be a ‘resource’ (always a URI), or a ‘literal’ (never a URI), or no defined range at all. It’s an important distinction because many systems, when trying to build a complete graph from a set of RDF statements will attempt to ‘lookup’ (dereference) URIs, and won’t do that if a URI is the object of a statement whose range is defined as a literal. The same thing happens when a system attempts to incorrectly dereference a literal that it must infer to be a URI because of the range definition.

One solution to the problem is to not define a range at all, or define multiple ranges. This throws any system trying to understand how to process a triple a mild curve — the answer to whether the object of a statement is a URI has to be ‘maybe it is, maybe it isn’t’ rather than a simple yes/no. Meaning that the system will be forced to test it to determine the answer, or simply not care — different reasoners take different approaches.

But what happens to interoperability when every producer of metadata is free to put anything they want in the object of that statement? It gets much tougher. It’s still possible but, like simple DC, making life simpler for producers of the statements puts more burden on the consumers.

RDF provides a relatively painless way out of this by providing a way to define a property as a sub-property of another property. In much the same way that a simple ‘dumb’ DC element definition provides the ‘semantic floor’ for the more complex qualified DC statements that represent sub-properties of it. So to solve the ‘Is the object a resource or a literal?’ problem, might it work to define the base property as having no range or multiple ranges and define two sub-properties of it, each of which would have a specific resource or literal range. A reasoner would always be able to infer that data in either case of the sub-property would be the semantic equivalent of the base property, while allowing each system producing the metadata to maintain the data in whatever domain-specific way it needed — literals or resources.

I’ve watched for years from the sidelines while the DCMI community chewed on this. It’s an especially significant problem for them since they’re not in a position to actually redefine the standard — any decision they make that doesn’t involve starting over means that somebody’s system breaks. This is one reason why, in attempting to extend the specificity of domains and ranges to the original 15 elements, DCMI chose to copy the original 15 to the DCTERMS namespace–giving implementers the option of more clearly specified elements without breaking the applications of those already using the Simple DC set without ranges. They didn’t have the luxury of being able to add yet another layer to the standard. The RDA effort doesn’t appear to be handicapped in this particular way.

Please note that I’m a person who has spent a significant amount of professional time moving data from system to system, and no time generating the metadata in the first place.

The PHPEd IDE offers a remote debugger for your PHP projects. The remote debugger is installed on your web server as a PHP module, and sends the debugging information back to your development computer where PHPEd is running. Because of this, you can debug your code in the environment where it will be living, with the same database, permissions, and http server.

The setup for remote debugging is not difficult, but I think this step-by-step article will help anyone who is using the same setup as I am. Just to be clear, that setup is:

* PHPEd 5.0
* Rackspace Hosted: RedHat Enterprise Linux 4 ES
* PHP 5.2.3
* PuTTY 0.60

Nth Design.

We’re very, very proud of her.

On Saturday, we had a great time wandering around the Italian Market Festival (I found myself missing the Italian neighborhood I sort of grew up in) and then to celebrate we went to dinner at Bar Ferdinand for excellent tapas and a good wine selection. Very noisy on a Saturday night, but highly recommended.

If she looks a little tired in the picture it’s because she put in a large number of all-nighters in the last few weeks.

From the Call for Tender page:
“DCMI Call for Tender 2007-03: Wiki format for application profiles convertible into XML”
From the DCMI home page:
“Call for tender for a machine-processable application profile format”

I don’t think that these two descriptions are describing the same thing at all. Of course, that just reflects my sense that “machine-processable application profile” doesn’t mean “application profile that can be scraped from a wiki page and expressed as XML”.

I’m more inclined to think that a “machine-processable application profile” means a DCAP that can be directly used to validate data that has been created with the intention of conforming to a specified DCAP (or is it DSP? — I wish that they wouldn’t suddenly change the terminology just to fit the model).

Increasingly, I’m viewing ”machine-processable application profile” as meaning machine-processable-DCAP-derived data-entry forms (XFORMS) used to generate DCAP-conformant XML data that can be validated using a machine-processable-DCAP-derived RELAX NG schema, W3C XML Schema, or Schematron ruleset. RDF triples would then have to be derived from the validated XML.

The intermediate XML validation is necessary because a sensibly efficient way to validate RDF against a DCAP currently doesn’t exist. Although Alistair‘s notion of rules-based RDF validation based on SPARQL query assertions looks like it might work in a Schematron-like way. This would then imply the ability to derive SPARQL queries from a machine-processable DCAP.

While the idea of a wiki-based DCAP editor is conceptually interesting, it would seem to me that a tender to produce exemplars of the above based on the current DCAP XML expression would be far more useful in actually providing useful test cases for determining the validity and utility of that expression.

David Huynh of MIT, responsible for wonders such as Timeline and Exhibit has made a short screencast demoing his latest marvel, Potluck. It’s currently a research prototype though appears very close to being web-ready. When you’ve seen the screencast I think you’ll agree with me – it’s awesome .

Potluck.

We’re happy to announce that the Danbury Library in Danbury, Connecticut has become the first library in the world to put LibraryThing for Libraries on its live catalog…

Underneath, the data comes from LibraryThing and its members. We’ve cleaned some of it up–Abby, our head librarian, and Jenny Anastasoff, a local librarian who’s intern with us, have been hunting down and excluding personal or irrelevant tags.* But its strength is the strength of LibraryThing’s people and their collections—200,000 members, 13 million books and 17 million tags.

Thingology (LibraryThing’s ideas blog): Danbury, CT kicks off LibraryThing for Libraries!.