As part of the effort for adding RDFa in core and in order to improve the linkage of content on the Web, it is important to be able to link taxonomy terms to their meaning from popular concept repositories such as dbpedia or freebase and therefore enable the power of linkage via RDF. The recent release of the CommonTag format make such concept linking easier using RDFa.
From http://commontag.org/About:
People use tags to organize, share and discover content on the Web. However, in the absence of a common tagging format, the benefits of tagging have been limited. Individual things like New York City are often represented by multiple tags (like “nyc”, “new_york_city”, and “newyork”), making it difficult to organize related content; and it isn’t always clear what a particular tag represents—does the tag “jaguar” represent the animal, the car company, or the operating system?
Taking advantage of the freshly committed #413192: Make taxonomy terms fieldable, this patch adds a field to the tags bundle (see example screenshot). It's my first patch for the brand new fieldable taxonomy terms, unsure whether the hook_install() / hook_uninstall() are the best place for field creation... This term concept URI can later be output along with the node terms in RDFa. One could think of having several concepts associated to a term, but let's keep things simple, as this should rather be achieved by using multiple terms (and their associated concept URIs).
Comment | File | Size | Author |
---|---|---|---|
taxonomy_term_uri1.patch | 1.02 KB | scor | |
Comments
Comment #1
scor CreditAttribution: scor commentedpatch needs review. tagging with RDF.
Comment #2
Anonymous (not verified) CreditAttribution: Anonymous commentedI'm reading about CommonTag now. Is this field the same as ctag:means in CommonTag?
In Drupal, this is basically synonymy with an external vocabulary, right?
What about terms that have synonyms in the same vocabulary?
Comment #3
Anonymous (not verified) CreditAttribution: Anonymous commentedDernit. Drupal.org zaps issue changes that happen between form building and form submission.
Comment #5
scor CreditAttribution: scor commentedyes, in most cases you would want to use the ctag:means property for this field, which would look very similar to the Multiple Tags for the same document from the CommonTag specs.
where U2 and ZooTV are 2 tags which both have their concept URI from freebase. Note however that this issue is not about exposing these in RDFa which will be another issue, but solely to store these in the system as part of the RDF model for the terms.
right. One application of this could be the Encyclopedia of Life which might want to use Drupal's taxonomy system to categorize their content, and map it to a set of reference vocabularies such as the ones provided by dbpedia, freebase or more specialized ones related to their domain.
Are you referring to the same vocabulary within Drupal, or in general? What's the status on this issue in the taxonomy module? you could use the same ctag:means within the same application (Drupal) without problem, however it is important to also refer to external ones to prevent your site to become a data silo.
Comment #6
Anonymous (not verified) CreditAttribution: Anonymous commentedThis patch should probably be done against the default install profile instead of taxonomy.install. If I use the expert/minimal profile to install drupal and then enable Taxonomy module, the fields are created for the "tags" bundle but that bundle doesn't exist. The tags vocabulary is created in the default install profile. It's interesting that it doesn't break at all, and if I create a tags vocabulary, the concept URI field is available on the add term form.
On the issue of term synonyms, I don't know the status of any patches related to synonymy right now. Probably the race is wide open now that we have #413192: Make taxonomy terms fieldable. Synonyms would presumably be another kind of field to add to terms. (And synonyms could be text fields or term fields once #412518: Convert taxonomy_node_* related code to use field API + upgrade path is ready.)
I know that linking outside is important, but it would also be nice to avoid the inside/outside distinction entirely. A synonym is a synonym whether it's in my Drupal vocabulary or it's in dbpedia. There's not much code right now that does anything with Drupal's term synonyms.
Comment #7
febbraro CreditAttribution: febbraro commentedAny chance to change the cardinality to something other than 1 to 1 (such as unlimited)? For example, I can see the need to attach an OpenCalais Linked Data URI to a taxonomy term, but another module might want to attach another (different) URI to the same term.
Comment #8
Anonymous (not verified) CreditAttribution: Anonymous commentedFrank:
I think I had the same concern, but I think scor is proposing something that is intrinsic to tagging.
If there's a basic URI that we need to attach to all terms whether (1:1 or 1:∞) then let's figure out what to call it. If a module can add fields to the vocabularies it creates, it won't be hard to do this in hook_install, will it?
There's a few modules that currently or potentially copy vocabularies to a Drupal site. Is this a URI field that would only ever apply to those kinds of vocabularies?
After #491190: Provide a taxonomy term field type, I'd like to start working on some issues around tagging, too. I hadn't thought of Calais in the same context as tagging, but it kinda is. The terms aren't hierarchical, synonyms have a particular relevance, and there are all kinds of tag-specific RDF features to consider.
ADDED AFTER POSTING:
scor is proposing adding a field that expresses this relationship:
http://commontag.org/Specification#means
Should we not implement the entire specification?
Comment #9
febbraro CreditAttribution: febbraro commentedWith respect to the specifics of a Calais integration with terms, this URI would be a Linked Data URI that is dereferencable to an RDF document containing Linked Data and other owl:sameAs links to get to freebase, dbpedia, etc. So in effect it is the same as ctag:means, in that it is linking to other resources that mean the same thing but may have different data.
You are right though, it is easy enough for a module to add a field that is specific to just what it needs, but I figured if there were general concepts being captured as a field (like a sameAs/means kind of value) that we should reuse instead of proliferating new fields.
Comment #10
Anonymous (not verified) CreditAttribution: Anonymous commentedThe thing is that I don't know if we should reuse fields because they are *kinda* the same thing.. and I don't have the judgment to say "these are the same thing."
is "owl:sameAs" ...ahem... the same as "ctag:means?"
Comment #11
scor CreditAttribution: scor commentedI would not interchange owl:sameAs and ctag:means because they have different semantics. Typically with ctag:means, you are linking ctag:Tag to a concept or a resource. owl:sameAs is too strong and could have bad effects, like asserting the tag is the same as a foaf:Person for example.
Comment #12
Anonymous (not verified) CreditAttribution: Anonymous commentedScor,
Does this mean that we also need to describe a tagging vocabulary's term names as "ctag:Tag?" Should Drupal's core tagging feature do more to implement the specification? Is Common Tag the best semantic vocabulary for tags? The only one? Maybe I should find you in IRC.
Comment #13
pncuong CreditAttribution: pncuong commentedI 'm very new in drupal 7, but my work is concerned with the extraction of semantic information from web pages (blogs, coments, etc.) not only for durpal but also for others . I use pyRDFa service to extract some my durpal7 content. I found that the result presents two separated data set that are not linked each other so i can't query about "all pages talk a bout a topic (i.e Cat)". The data i got something like:
---- first part
http://www.w3.org/2004/02/skos/core#:Concept
http://www.w3.org/2004/02/skos/core#:prefLabel
SocialSemanticWeb
rdfs:label
SocialSemanticWeb
----- second part
sioc:Post
http://rdfs.org/sioc/types#:BlogPost
content:encoded
............
sioc:has_creator
.......
sioc:UserAccount
foaf:name
........
dc_terms:title
.....
---------------------------------
I would like to add a property to a Post to make the link between the two like:
sioc:topic
(i.e. SocialSemanticWeb)
-----------------
I'd tried to add a field rdf mapping in node.module but it didn't work:
'reference_terms' => array(
'predicates' => array('sioc:topic'),
'type' => 'rel',
)
What can i can do? Any one can help me?
Thanks
Comment #14
scor CreditAttribution: scor commented@pncuong please create a separate support request for this at http://drupal.org/node/add/project-issue/drupal?tags=RDF
Comment #15
scor CreditAttribution: scor commentedmoving this to D8, though this can naturally be achieved in D7 with custom fields and a bit of custom code
Comment #16
colanSubscribing.
Comment #17
ceefour CreditAttribution: ceefour commentedSubscribing/voting!
Comment #18
ebremer CreditAttribution: ebremer commentedtaxonomy_term_uri1.patch queued for re-testing.
Comment #20
ebremer CreditAttribution: ebremer commentedComment #21
scor CreditAttribution: scor commentedIt would be similar to adding such field yes. read the thread above from #5 onwards, where it explains that the way it would be exposed in RDFa is not necessarily meant to be decided yet (in particular whether the link should point to the local term page or to the third party, that should be up to the site admin).
Comment #22
Anonymous (not verified) CreditAttribution: Anonymous commentedSince this can be achieved simply by adding a field to the taxonomy, I don't see an advantage to adding it in core... particularly since not all Drupal taxonomies are used for semantic tagging. Sometimes taxonomy is simply used for access control or menu handling.
If no one objects, I would like to close this issue as won't fix.
Comment #23
scor CreditAttribution: scor commentedI agree using a field is good alternative for now, if there is support later this issue can be reopened if needed. The Entity RDF post explains how this can be achieved using a field and tokens.