W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > July 2008

Re: RDF vocabulary best practices question...

From: Keith Alexander <k.j.w.alexander@gmail.com>
Date: Wed, 16 Jul 2008 14:38:56 +0100
To: "Manu Sporny" <msporny@digitalbazaar.com>, "RDFa mailing list" <public-rdf-in-xhtml-tf@w3.org>
Message-ID: <op.ueduo3nn63ayaz@>

> Is adding synonyms into your vocabulary a valid best practice?

I wouldn't call it a 'best practice'. It is a  design decision, though not  
one I would make probably. It might be worth noting that the SIOC  
vocabulary [1] started off with sioc:title, sioc:creator etc, but have now  
deprecated these in favour of advising authors to use the DC vocabulary.

The main downside is that applications that understand the semantics of  
dc:title need to get a copy of your vocabulary and do some reasoning in  
order to understand what to do with audio:title.

A simple example: Imagine you are writing code that tries to render any  
RDF data as HTML, and you want to render a 'label-like' property inside an  
<h1>. Currently, a common approach that will work most of the time is to  
look for a few well-known common label-like properties - rdfs:label,  
dc:title, foaf:name, rss:title. If people reuse existing vocabularies like  
DC, RDFS and FOAF, light-weight applications can get away with hard coding  
these semantics. But if vocabularies proliferate that subclass/subproperty  
or sameAs other vocabularies (instead of encouraging authors to use them  
in conjunction), then applications will have to become more sophisticated,  
retrieving, caching, and reasoning on vocabularies/ontologies dynamically  
-  which is cool and everything, but means  they take longer to write, and  
take more resources to run. It raises the barrier of entry.

Imagine you have an application geared up to deal with 'audio' vocab'd  
RDF, and then people start publishing loads of data using a 'funk'  
vocabulary which largely just creates synonmys of 'audio' terms.

Another cost of creating the synonyms is that your vocabulary document  
will be larger, making it harder for people to understand your vocabulary  
at a glance.

I do see your problem though - you want to appeal beyond the  
already-RDF-savvy audience, and reduce the amount of extra markup needed  
to publish audio data, so it may be that for your purposes, it is still  
better to create synonyms. If you don't create synonyms, there is still  
the problem of advising authors on what other vocabularies they might find  
useful in conjunction with yours. The approach we are taking with voiD[2]  
is to have a seperate Primer document explaining how to author data with  
the vocabulary.

Mixing and matching vocabularies within a resource description though, is  
a great advantage of RDF, and once you have used DC with AUDIO, you then  
know how to use it in lots of different places. In fact, authors may  
already be using DC elsewhere in the document they are adding AUDIO to, in  
which case, the synonymising effort will have been pointless.

> For
> example, is having audio:title specified as owl:sameAs dc:title  
> acceptable?

As Toby said, rdfs:subPropertyOf is more appropriate probably. Be aware  
that if audio:title owl:sameAs dc:title, any properties you then add to  
audio:title will also belong to dc:title (and doing that would be a bit  



[1] http://rdfs.org/sioc/ns
[2] http://community.linkeddata.org/MediaWiki/index.php?VoiD

Received on Wednesday, 16 July 2008 13:44:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:28 UTC