finally a bnode with a uri

Custom auto-generated custom auto-... RDF forms

Still looking for the best approach...
After my last post, I spent some more time on the custom RDF templates, trying to generalize and automate as much of the form generation process as possible.

The first step was to create a re-usable parent-class for custom templates with methods for standard tasks such as the retrieval of property labels and comments, as well as the automatic creation of simple properties.
Additionally, the list of available templates is now created from a little configuration file where each template definition consists of three simple fields: a label, a target class, and an identifying name to later find the custom template class. The target class is used to make sure that the template can be used with resources of a certain type (or inferred sub-type) only.

Upon form creation, the custom template class is instantiated, and a "get_fld_infos" method returns an array of form field parameters that can be used to generate input fields, textareas, checkboxes, and the related labels and property comments. E.g. the following code snippet creates a simple input field:

When a custom form is submitted, the generic template class checks for each form field if the custom class has a "custom creation" method defined, otherwise it will assume that the field is a standard field with either a literal or a URI value. (The script then does ontology look-ups to determine the value type of the property.)

For any non-simple field/property, the custom template has to provide a special method to create the triples "manually". I still had several almost identical methods that did nothing but splitting "one-entry-per-line"-textarea values into single values. So I added an option that allowed me to use textareas for a list of URIs/values, without having to write custom creation methods (by marking a field definition with a simple "is_list"=>true).

So, the only thing that actually remained were blank nodes, i.e. where the template just "asks" for a single value (e.g. a doap:revision identifier), but the script has to create a bnode of a certain type, plus a property with the submitted value (e.g. doap:release -> doap:Version -> doap:revision ->value).

However, that's also a pattern I could generalize, moving the create_bnode_property method in the parent class. I still need the custom methods, but they are rather small now. Only the connecting property, the class, and the properties of the bnode have to be defined.

I've built a custom DOAP-template today, it is generated from a single 7K php class. And the form still looks ok, too. Give it a try and describe your SemWeb project, the template is now available at in the "Quick-add" section, after creating/selecting a foaf:Project or a doap:Project.

Comments are disabled for this post.

Earlier Posts

Later Posts


No Posts found