finally a bnode with a uri

Posts tagged with: dc

SKOS + DC + Linked Data = Semantic Tagging?

Using Dublin Core terms to link SKOS concepts to Linked Data entities
Still looking for a simple way to tag concrete resources (to-do items, people, locations) with personal concepts (e.g. "non-profit", "research", "semweb"), and also with other non-conceptual resources (clients, projects), I skimmed through the fresh SKOS Recommendation. I'm still a fan of SKOS and frequently wonder about semweb apps where the internal models are grounded in pluggable, personal(!) SKOS schemes, instead of coordination-intensive RDF Schemas or OWL ontologies. I don't know if such an approach could really work, I guess network effects benefit more from rather tightly defined relations and identifiers. Mainly just to have it written down somewhere (this is really not well thought out yet), here are some of the related entry points and considerations:
  • Tagging should be personal.
    While I like the idea of grounding tags in existing dictionaries such as DBPedia, tags seem to work best when they are as user-defined and informal as possible. Last year, I experimented with a tool that allowed me to tag things with other people's delicious tags. It just felt wrong, I wanted my "own" tags. (I think the latest Faviki release is a nice example for combining the best of both worlds).
  • SKOS supports personal tags
    Concepts in SKOS are sort-of scoped (or "namespaced"). If I describe a "Fun" concept, it is defined as seen by the creator of the concept URI, i.e. I can annotate it with ':Fun dct:creator <#me> ; dct:created "2009-08-19"' etc, even though the general idea of Fun was clearly not invented by me, and definitely before today.
  • Tags should be safely portable
    Thanks to URIs, SKOS concepts can be ported to other applications, and they can be grouped and organized in so-called concept schemes, i.e. I could have a "Waving" in a "Dance" concept scheme, and also in a "Netiquette" scheme.
  • There is a need to merge tag sets
    If tags are used to organize all sorts of personal things, it should be possible to merge them into a unified model. Mainly for personal use ("personal world view"), but also for sharing with other people and linking to their views. This is again possible thanks to SKOS being based on RDF, URIs, and very loose semantics.
  • There is a need to tag real-world objects with concepts
    This is partly obvious. Tags are a means to an end. But while they are already widely used to annotate document-like resources (web pages, photos, etc), I'd also like to tag things like my projects, people in my address book, and similar non-documents. From the SKOS Primer: While the SKOS vocabulary itself does not include a mechanism for associating an arbitrary resource with a skos:Concept, implementors can turn to other vocabularies So, whatever predicate URI we are going to use, it's not going to be provided by SKOS directly.
  • Maybe Dublin Core terms can link non-documents to concepts
    This is a slightly controversial conclusion/assumption, given that DC terms are mainly associated with document metadata. But after exploring the DCMI website, I can't find any clear evidence that their terms can't be used more generally. Both the Usage Guide (thanks to Masahide for the pointer) and the Abstract Model actually support this thought. The Usage guide mentions that "DC metadata can be applied to other resources as well" (but notes that the suitability may depend on the particular context at hand), and the Abstract Model states that the notion of a Dublin Core "resource" is equivalent to "Resource" defined in RDF Schema, which can be anything, even including Literals. So, we can most probably use dct:subject or dct:relation to tag a project or person with a SKOS concept.
  • There is a need to associate concepts with real-world objects
    If we organize our personal concept space with SKOS, we may also want to more formally specify our personal concepts, so that other applications or people can merge them with their tags. Therefore, we need a predicate that can relate concepts to non-concepts such as DBPedia identifiers. Such a mechanism could maybe also help with RDF's general problem of URI aliases. I could have a personal, canonical concept URI for a resource and use it as a container for the resource's various aliases. Again, SKOS does not provide a predicate for this use case, so we've got to look elsewhere.
  • Maybe Dublin Core terms can link concepts to real-world objects
    Another possibly controversial conclusion, but again there is supporting text in the DCMI specs: "A value associated with the Dublin Core Subject property is a concept (a conceptual entity) or a physical object or person (a physical entity)". So, if the value of dc:subject can be a non-document, we can say things like :Berlin a skos:Concept; dct:subject dbpedia:Berlin .. This is very interesting because it could allow us to use dct:subject in both ways: for the tagging of things, and also for grounding tags. FOAF has a handy primaryTopic term, which could work in this context, too, but unfortunately, its scope is (currently) set to foaf:Document. DanBri also suggested the creation of a dedicated skos:it (or similar) predicate which would be even better.
  • Sometimes I'd like to "tag" real-world objects with real-world objects
    Don't know if tagging is still the right word here, but what I mean is a generic relation for arbitrary things in a common application context. Often, we can do better by specifying the relation between two resources, but in other cases, a simple, maybe just temporary link, is better than laziness leading to a completely non-annotated resource. Given the two DCMI-related findings above, we could maybe conclude that a predicate like dct:relation can also be used to relate a project to a person, or the other way round, without having to invent a new predicate.

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.


No Posts found