finally a bnode with a uri

Pimping my RIDE, and shifting down

RDF Instance Data Editing
You all know MTV's Pimp My Ride show where they tune a car until you almost forget its original purpose. While working on my RIDE I sometimes got the impression of maybe also adding too many features to it and losing overall usability.

My main problem was that I had a list of requirements that couldn't be implemented with custom forms in a reasonable amount of time:
  • auto-generating tooltip-like information for each form field
  • separating the RDF editing front-end from the (OWL) model, so that changing the model doesn't force me to adjust the editor
  • offering editing forms for more than 15 different resource types and at the same time making sure that any possibly "fitting" property can be attached to a selected resource
  • being able to define validation and auto-adjust procedures at the model- and not at the forms-level.
  • keeping the editing UI scalable by offering multi-page forms, and filters on namespaces, properties, and property values

However, other requirements were also that
  • people not too familiar with all those RDF characteristics (blank nodes, striping, etc.) and the various different RDF vocabularies should also be able to create and maintain resource descriptions.
  • the UI should not get too big and should not have too many options which rather confuse than help

The latter appeared trickier to implement to me than the more technical requirements, but let's start at the beginning of the list:

auto-generating tooltip-like information

The editor needs an API that allows it to retrieve rdfs:comment annotations for a given property URI. Once such an interface to the OWL model is available (I'm using OWLchestra for this), generating the info texts is easy. Even the creation of a multilingual interface is straight-forward as long as the annotations are available in different languages.

separating the RDF editing front-end from the (OWL) model

The editing forms are created on the fly. This requires the availability of label and comment information for each property. It's also neccessary (for my tool), that each property has a defined domain and range (this can be rdfs:Resource, though). Literal properties should have a datatype set which is needed to auto-generate the different widgets (single-line text fields vs. checkboxes vs. multi-line textareas). I've tweaked my OWL editor so that custom datatypes (with possibly custom widgets) can be created. (I'm still considering a switch to Dan Connolly's new rdfIcal design, which uses timezone datatypes. If I moved to the new design I could create a custom datatype for dtstart/dtend and a widget where users could enter date, time, and timezone.)

offering editing forms for many resource types with different sets of possible properties

As the forms are generated on the fly, there is no need to adjust the editor when new resource types are added to the model. However, I'm using drop-down lists to choose a class or property, so there is a limit for the number of classes and properties the system can support before things get clumsy. The initial model at the Beta site contains about 30 classes and 200 properties (collected on a relaxed term-shopping day ;). I managed to keep the drop-downs somewhat small by defining mappings between the different vocabularies and adjusting domains and ranges where possible, but I don't think I'll be able to add many more. At least not many generic properties with a domain of rdfs:Resource.

defining validation and auto-adjust procedures

Validation functions can be defined in two ways: OWLchestra's datatype editor allows to specify an external validation function for a datatype, and an annotation property can be used to "assign" an auto-adjust function to a property. I'm still not sure if this use of annotation properties is considered a hack, but they are very handy to define little hints whenever needed. And they allow me to standardize form validation, but also to add custom features such as auto-converting an entered email-address to a valid foaf:mbox or foaf:mbox_sha1sum.

keeping the editing UI scalable

In order to keep response times acceptable, I'm using two DHTML-generating PHP classes: A table class and a Tab box class. Using the table class, I don't have to worry too much about sorting and splitting the result sets on multiple views. The tab box class makes it possible to provide a consistent look and feel (I hope) for the lists, filters, details forms, and creation forms. The tabs can also be used to only load/refresh a certain part of the whole form, and to hide functionality that's not needed for the task at hand.

OK, now to the less-technical requirements:

"Easy editing" forms, more compact UI

I was happy when the forms started to work, but there surely is much space for improvements. Making certain fieldsets collapsible helped a little, but having to add properties one by one wasn't really cool. And although this is the only way to manage resources with many properties, and even after having added a "multi-edit" feature for properties, I'd still have preferred the foaf-a-matic over my tool to create an initial resource description, or a one-page form with limited functionality for a small resource description.

So I went back to the drawing-board and redesigned the main "overview tab" you see when you select a resource. It shows now a "quick-edit" form where you can edit up to 20 properties in one form. Properties of the same type are grouped. It's not possible to adjust the language of literals, to change the publication setting, or to update blank nodes. But the form is nice and small and each field still has rdfs:comment information where available.

Next to the "quick-edit" tab is another new tab labeled "quick-add". The quick-add tab enables the creation of semi-hard-coded *-a-matics. Selecting it will let you choose from a list of templates such as "Basic FOAF description", "A list of depictions", "Import PPD", or "Basic DOAP description". These templates are defined at the form level, but can still use labels and tooltip infos from the model. Each template field can be defined as being a "standard" field or a custom field. Standard fields will create simple triples, custom fields can be used to manually create bnodes or more complex triples (e.g. turning a simple IATA code value into a resource property contact:nearestAirport linking to an air:Airport resource with the entered air:iataCode.

So, after building this auto-generate-everything editor, I'm returning to (at least partly) custom forms. Funny. (Well, sooner or later I'm going to need the advanced features, though, the UI scalability argument still holds true.)

The templates are still experimental, some don't even work at all. But I dared uploading the whole stuff to, and if you like to give it a try and send me some feedback, comments, or bug reports, I'll really appreciate that. I can test the editor with windows browsers only, so I don't know how the app looks or works on other systems. (By the way, it's not possible to browse resource descriptions or site content yet, all you can do is signing-up, playing with the profile and the RDF editor, and generating RDF/XML.) If you don't want to register, you can alternatively use the account alec (with pwd tronnick). Alec is an RDF crash test dummy and will be around during the pre-beta phase.

Comments are disabled for this post.

Earlier Posts


No Posts found