Makes my head hurt

I was talking with Diane this morning about building the schema portion of the Registry and I feel the need to write down some of what we discussed.

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.

TimeSlices and Versions

You can now retrieve a snapshot in time of the RDF or XSD serialization of a Concept/Scheme/Vocabulary by appending a ‘TimeSlice’ to the URI. For example: http://metadataregistry.org/uri/NSDLEdLvl/ts/20060422200002.rdf or http://metadataregistry.org/uri/NSDLEdLvl/ts/20060422200002.xsd will always and forever retrieve the SKOS/RDF or XML Schema representation of the NSDL Ed Level Vocabulary as it appeared at 2 seconds after 8PM on April 22, 2006 (2006-04-22 20:00:02). If you follow the above .rdf link you’ll notice that the concept URIs that the TimeSliced Vocabulary references have also had a TimeSlice appended: http://metadataregistry.org/uri/NSDLEdLvl/1001/ts/20060422200002.rdf in order to lock them into that precise point in time on an individual basis as well. We hope the utility of being able to reference a vocabulary at a particular point in time regardless of subsequent changes will be, well, useful.In order to make retrieving TimeSlices for specific events in the history of a vocabulary a bit handier, we added a TimeSlice link to every history event. You can specify a TimeSlice for any point in time regardless of its relationship to a history event, but the link just makes it simpler (it’s over on the right side of each line):

The Registry! :: NSDL Education Level Vocabulary :: History of ChangesUploaded with plasq‘s Skitch!

Named Versions

You’ll maybe also have noticed that there’s a ‘Name’ link nestled to the right of the RDF and XSD links. If you’re a Vocabulary Administrator, then you now have the ability to label a TimeSlice with a distinct version name. That link again is there to make it easy to reference a point in historical time and clicking on it pre-enters that TimeSlice into the Create new version form:

The Registry! :: Creating new versionUploaded with plasq‘s Skitch!There’s no limit to the number of versions you can create, and versions (unlike TimeSlices) can be deleted or edited by any Vocabulary Admin:

The Registry! :: NSDL Education Level Vocabulary :: List VersionsUploaded with plasq‘s Skitch!…although we think that either editing or deleting a version is likely to be a less-than-ideal practice. Still, we allow it — it’s your vocabulary after all.Once a named version has been associated with a TimeSlice, it will appear in the event history list just above the point in time it references:

The Registry! :: NSDL Education Level Vocabulary :: History of ChangesUploaded with plasq‘s Skitch!The RDF and XSD links on the right side of the version line now reference the version name:http://metadataregistry.org/uri/NSDLEdLvl/version/release+1.0.rdfBut this is where it gets a little incorrect… Since the named version URL is just a TimeSlice reference, it does a silent redirect to the referenced TimeSlice. It should probably do a 303 redirect instead. We’ll fix this later, unless it’s a show-stopper for one of our many users.

Improved user management

We’ve been promising for a while now that we’d make it easier, actually a better word is ‘possible’, for Vocabulary Owners to add ‘Members’ to Owner/Agents and ‘Maintainers’ to Vocabularies. We finally implemented it today! It’s unfortunate that it has taken us so long, since one of the primary goals of the Registry is to support multi-user vocabulary development, but it turned out to require more infrastructure twiddling than we thought it would.

If you’re a vocabulary owner and are logged in, you can add other registered folks as ‘members’ of your Owner/Agent and you can even make them administrators if you want:

The Registry! :: NSDL Registry :: List Members

The Registry! :: Editing NSDL Registry permissions for Diane Hillmann

Uploaded with plasq‘s Skitch!

We hope the process is pretty self-explanatory.

Once you’ve added a user as a member of your Owner/Agent group, you can add them to your vocabularies as Vocabulary Maintainers or Administrators.

The Registry! :: NSDL Registry Agents Vocabulary :: List Maintainers

The Registry! :: Adding maintainer to NSDL Registry Agents Vocabulary
Uploaded with plasq‘s Skitch!

We realize that this is still somewhat limited and of course the documentation is ummm, poor, but we’ll be doing more with user management shortly.

Just a test

This is just a test of “ScribeFire:

“ScribeFire is an extension for the Mozilla Firefox Web browser that integrates with your browser to let you easily post to your blog: you can drag and drop formatted text from pages you are browsing, take notes, and post to your blog.”

Registry News

We’ve updated the front page of the Registry to include a Registry-specific news feed from the Registry blog. You can subscribe to it right from (t)here and stay up-to-date with the Registry as we move it forward. Notes like this will be typical and probably pretty frequent over the next few months.