Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Vocabularies
We've already seen how RDF creates powerful metadata by standardizing metadata elements. Vocabularies make certain kinds of metadata even more powerful by providing a predefined list of values that these elements can hold. Vocabularies are known by many different names: taxonomies, authority files, reference data, controlled vocabularies, and ontologies, to name a few. Boiled down to its essentials, however, a vocabulary is a list of predefined values. RDF provides the ability to represent those lists (through RDF schema), even if the list has some complex structure as with an ontology.
Let's look at language as an example. The Dublin Core element language defines "A language of the intellectual content of the [given] resource." A RDF descriptor to do so might look something like this:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<rdf:Description rdf:about="">
<dc:language>en</dc:language>
</rdf:Description>
</rdf:RDF>
The Dublin Core recommendations for usage of this element direct you to some IETF and ISO documents (RFC 3066 and ISO 3166, respectively) that recommend a set of codes to use as the value of this element. The designation en stands for English, but if I wanted to be more specific I could have used en-GB for "Great Britain English" or en-US for "United States English" (and as a U.S. expatriate living in England, I can attest that there is a big difference). This is a "best practice," because it isn't strictly a rule governing the element's usage—you could easily make up your own language codes, but the best practice for maximum interoperability potential is to use a code out of the recommended vocabulary.
Interoperability is a funny thing. It's a laudable goal, and everyone agrees in principle that it's a good idea, but it's often a struggle to actually get different groups to agree on standards to interoperate with. Interoperability also usually costs a bit more and takes a bit longer and often isn't necessary to meet immediate-term business requirements. Likewise, there's a point of diminishing returns with interoperability—different for every project—where you're just expending time and energy for the principle of interoperability and not for any actual business reason.