finally a bnode with a uri

Posts tagged with: doap

Got some SemWeb DOAP 'n' FOAF?

Starting to collect RDF descriptions of SemWeb projects at
All baby steps, but I've activated a DOAP editor, an RDF/XML loader, and a basic browser store dump at Would be great to get some DOAP files describing SemWeb projects in there, and maybe some FOAF files as well. That'd make coding the browsers more fun and a bit more real-world-ish.
Thanks for your help!

Term Shopping for Trackbacks and Projects

Describing trackbacks, and projects with basic vocabularies.
I already mentioned the nice HTTP vocab I'm using to describe page views in RDF. I had to add some custom properties to cover things like visits and access hosts, but the main part of the statistics module is built on top of the W3C vocab. The more I work with RDF, the less I feel comfortable with homegrown terms (although they can be handy for prototyping) and thus spend quite some time on the vocabulary market. Here are two other use cases I was gladly able to model with existing vocabs.


I wanted to add support for incoming trackbacks to SemSol's blog module. Trackbacks consist of 4 parameters:
  • title (title of the remote post)
  • excerpt (excerpt of the remote post)
  • url (permalink of the remote post)
  • blog_name (name of the remote blog)
Additional local information:
  • date/time of the trackback (i.e. now)
  • permalink of the local post (derived from the trackback URL)
After a fruitful IRC chat with John "SIOC" Breslin, I'm now using (something similar to) the following code:
<$url> a rss:item ;
       an:annotates <$permalink> ;
       dc:title "$title" ;
       dc:description "$excerpt" ;
       dc:date "$now" ;
       dc:source [ dc:title "$blog_name"] .
I could have used rss:description instead of Dublin Core's but thought the structure could more easily be extended to local comments this way. Anyway, as you can see, trackbacks can nicely be described with DC, Annotea, and RSS 1.0.

Projects, Tools, Applications

The second use case comes from where I'd like to make some of the project and tools data collected during 2005 available. Additionally, I want to provide easy editing forms to let members describe and annotate RDF software. For, we invented an swo:Application class to separate (developer) tools from (end-user) apps. But while analyzing the dataset, I saw that there are additional resource types which fit under the generic "project" concept, e.g. lists or data dumps. I was already in the middle of making up a whole bunch of classes when I remembered an earlier DCMI discussion about the negligible difference between dc:type and rdf:type which referred to DCMI Type definitions. Long story short, DC Types (dctype) combined with FOAF (foaf), DOAP (doap), and the DAML Tool vocab (tool) can be used to describe a whole range of resources:
  • general projects (foaf:Project)
  • software projects (doap:Project, which covers non-OS software as well)
  • resource collections (dctype:Collection, dctype:Dataset)
  • software products (dctype:Software or dctype:InteractiveResource, these could be used to e.g. attach tool:price properties which would perhaps look a bit odd on projects)
  • tools (tool:Tool)
  • online services (dctype:Service)
Something like dct:isPartOf could perhaps even be used to model sub-projects, but I'm not 100% sure.

Bottom line, again: no need for new terms, it's (often) all there already.

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.


No Posts found