finally a bnode with a uri

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.

Trackbacks

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 RDFer.com 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 SemanticWeb.org, 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.

Comments and Trackbacks

0 comments are currently in the approval queue.

Comments are disabled for this post.

Earlier Posts

Later Posts

Archives/Search

YYYY or YYYY/MM
No Posts found

Feeds