De grote meerderheid van de mensen die op het wereldwijde web surfen, zijn op zoek naar informatie.
Echter, deze informatie is niet altijd even duidelijk voor computers. Daarom werd de metadata in het leven geroepen, dit is een korte beschrijving van de inhoud.
Maar zoals je weet zijn de hiervoor ontworpen meta keywords en description dusdanig ontoereikend en misbruikt, dat ze de dag van vandaag veel minder waarde hebben voor bijvoorbeeld zoekmachines. (alhoewel de description meta wel degelijk nog een nut heeft voor de resultatenpagina van een zoekmachine, kortweg SERP genoemd).
Doordat computers nog altijd geen Artificiële Intelligentie bezitten, moeten we alle informatie voor hen interpreteerbaar maken. Dit heet semantiek (opgelet: Buzzwoord 
).
Dus hoe zorgen we ervoor dat onze inhoud begrepen wordt door software?
Naast het juist toepassen van html tags en attributen voor wat ze bedoeld zijn, blijkt het gebruik van beschrijvende markup (metadata) onmisbaar te zijn. De enige manier om dit te bereiken is door deze beschrijvende elementen in een afgesproken standaard vast te leggen.
Één van deze standaarden heet dublin core, ondertussen al tot versie 1.1 doorontwikkeld. Deze standaard maakt gebruik van de rdf namespace in xHtml.
Nu, wat is een
namespace? (dit is randinformatie en mag je overslaan)
Het gebruik van een namespace in xHtml zorgt ervoor dat je, door een
url uri op te geven als verwijzing naar een standaard, een reeks vastgelegde namen/tags/attributen tot jouw beschikking krijgt.
Je breidt het xHtml document dus uit, dit is de betekenis van de X in eXtensible HTML in een notendop. Deze standaard kan je zelf aanmaken, of je kan er één gebruiken die door een grotere organisatie werd vastgelegd én hierdoor dus ook algemeen gekend is/op meer plaatsen op dezelfde manier kan worden toegepast.
Hierdoor kan je, door het volgen van deze afspraken en de naamgeving, een uniforme manier van werken creëren op het wereldwijde web bij de aanduiding van bepaalde soorten inhoud. Dublin Core is zo’n standaard.
Hoe voeg je nu in de praktijk metadata toe aan een xHtml document?
Een nogal drastische mogelijkheid is om het xHtml document uit te breiden met de rdf namespace, en op die manier de Dublin Core te implementeren, maar hierdoor werken we uiteindelijk met onzichtbare metadata.
Dat wil zeggen: net zoals de gewone meta keywords en description behoort deze metadata niet tot de zichtbare inhoud, en is deze dus ontoegankelijk/onzichtbaar voor de gewone bezoekers.
Hierdoor is de kans groter dat deze informatie niet gebruikt/geverifieerd/onderhouden wordt, of verschilt van de daadwerkelijke inhoud.
En aangezien we uit eerder gemaakte fouten leren, en willen aantonen dat de inhoud die we samenvatten voor de computers wel degelijk behoort tot de inhoud die we aanbieden, is er een onderling afgesproken standaard ontwikkeld om de metadata te koppelen aan de inhoud (we embedden deze dus 
).
Aan de slag
Je declareert eerst het gebruik van embedded RDF in een profile attribuut in je head tag:
<head profile="http://purl.org/NET/erdf/profile">
Hiermee delen we alle hierin geintresseerde software mee dat deze vorm van metadata in dit document aanwezig is. We vertellen in dit geval dat alle informatie in de inhoud van het document zelf aanwezig zal zijn, volgens een nog nader te bepalen standaard (lees: een schema).
De uri http://purl.org/NET/erdf/profile verwijst hierbij naar het exacte type metadata en de eventuele versie die gebruikt zal worden, en kan je zien als een soort constante.
Volgende stap is het vertellen welke vastgelegde afspraken we zullen gebruiken om de inhoud te beschrijven. We hebben de keuze uit:
- <link rel=”schema.dc” href=”http://purl.org/dc/elements/1.1/” />
- <link rel=”schema.terms” href=”http://purl.org/dc/terms/” />
- <link rel=”schema.foaf” href=”http://xmlns.com/foaf/0.1/” />
- <link rel=”schema.bio” href=”http://vocab.org/bio/0.1/” />
- <link rel=”schema.contact” href=”http://www.w3.org/2000/10/swap/pim/contact#” />
- <link rel=”schema.air” href=”http://www.daml.org/2001/10/html/airport-ont#” />
- <link rel=”schema.rss” href=”http://purl.org/rss/1.0/” />
- <link rel=”schema.rel” href=”http://purl.org/vocab/relationship/” />
- <link rel=”schema.geo” href=”http://www.w3.org/2003/01/geo/wgs84_pos#” />
- <link rel=”schema.doap” href=”http://usefulinc.com/ns/doap#” />
- <link rel=”schema.rdfs” href=”http://www.w3.org/2000/01/rdf-schema#” />
- <link rel=”schema.wn” href=”http://xmlns.com/wordnet/1.6/” />
Hier zitten de meest gebruikte schema’s van dit ogenblik bij, in dit voorbeeld gaan we dieper in op de dublin core:
<link rel="schema.dc" href="http://purl.org/dc/elements/1.1/" />
<link rel=”schema.terms” href=”http://purl.org/dc/terms/” />
Deze 2 schema’s zetten we vervolgens tussen de <head></head>-tags, zodat het profile verder verduidelijkt wordt met de gebruikte schema’s.
Het schema dat we nu gebruiken, dublin core 1.1, bevat de volgende beschrijvende elementen als basis
| Naam |
Beschrijving |
| contributor |
Iets of iemand die heeft bijgedragen aan bepaalde zaken |
| coverage |
Beschrijving van iets of iemand die als bron heeft gediend |
| creator |
Iets of iemand die verantwoordelijk is voor de inhoud |
| date |
Tijdstip of tijdspanne die in je inhoud wordt vermeld, met als formaat JJJJ-MM-DD |
| description |
Een vrije beschrijving van de inhoud |
| format |
Beschrijving van het formaat van iets zoals: de bestandsgrootte, afmetingen, mime-type, .. |
| identifier |
Een unieke titel voor je inhoud, mag maar 1 keer voorkomen |
| language |
Taal van de inhoud, liefst volgens RFC 3066 (bvb: en, nl-BE, Duits) |
| publisher |
Iets of iemand die de inhoud beschikbaar maakt |
| relation |
Een gerelateerde bron, gerelateerde inhoud |
| rights |
Informatie betreffende de rechten over de inhoud |
| source |
Een bron waar de inhoud onder andere van is afgeleid |
| subject |
Een beschrijvende, eventueel algemene titel voor je inhoud |
| title |
Een naam die wordt gegeven aan de inhoud, waaronder deze algemeen bekend is |
| type |
Een categorie of achterliggend genre van de inhoud |
Er zijn nog een 20-tal andere namen gedefinieerd, maar we gaan daar in dit artikel niet dieper op in. Dit zijn de belangrijkste namen, die de basis van de dublin core vormen.
Het is belangrijk om weten dat je niet verplicht bent om alle bovenstaande namen tegelijk te gebruiken in embedded RDF. Dat zou overkill zijn, en is juist één van de beweegredenen van deze embedded vorm. Want alle embedded RDF kan omgezet worden naar RDF, maar niet alle RDF kan naar eRDF omgezet worden.
Nu we het type metadata (embedded rdf) en het schema (dublin core 1.1) bepaald hebben, wordt het tijd om alle beschrijvende inhoud te gaan aanduiden met de juiste naam.
Wel, hoe duiden we de beschrijvende inhoud aan?
We zorgen dat de beschrijvende inhoud van een geldig class attribuut voorzien wordt. En indien er meerdere onderwerpen in het document aanwezig zijn, kan je ze scheiden door een ID attribuut aan een parent element toe te kennen (is vooral het geval bij het friend of a friend schema).
Nu, de waarde van het class-attribuut is natuurlijk aan enige voorwaarden verbonden, maar een ID dient slechts als afbakening. Neem nu volgend voorbeeld:
<h1 class="dc-title"> <span class="dc-author">Ben</span>'s Blog </h1>
<p> Dit voorbeeld werd geschreven op <abbr class=”dc-date” title=”2006-12-30″>30 december</abbr>, en <span class=”dc-type”>niewjaar</span> komt er binnen <span class=”dc-date”>1 dag</span> aan! </p>
Zoals je kan zien is de (voor hoofdletters en gewone letters ongevoelige) classname opgedeeld in 2 delen, gescheiden door een koppelteken.
Vóór het koppelteken komt de namespace te staan, in dit geval dc (genoemd naar dublin core, en gedeclareerd in het head gedeelte).
Nà dit koppelteken komt dan een van de door de standaard afgesproken namen.
Uiteindelijk wordt een classname op de volgende manier gevormd:
class="namespace-naam".
Over het algemeen geldt dat de tekst die in het element staat, gelijk is aan de waarde van dat element. Maar wat als je de software een voor hun leesbaarder formaat wil voorschotelen?
De oplossing hiervoor zit in de <abbr> tag. Hierbij geldt dat alles wat in het title attribuut staat, als te prefereren formaat gekozen wordt. En wat in het element zelf staat, is dan zogezegd de door mensen leesbare (human readable) versie.
Maar het is natuurlijk zo dat alle logische vormen geldig zijn, zo wordt een tijdstip/tijdspanne in het voorbeeld op verschillende manieren voorgesteld en zijn ze allemaal even geldig. Het formaat dat tussen het title attribuut staat is echter volgens de ISO normen gevormd (JJJJ-MM-DD, hier kan je eventueel het aantal uren aan toevoegen indien dit nodig is ) en hierdoor nog beter interpreteerbaar voor computers.
Ik wil echter nog iets toevoegen aan de metadata, maar dit staat niet in de inhoud?
Je kan nog altijd onzichtbare metadata toevoegen aan je document, maar overweeg dan eerst dat als het niet in je inhoud voorkomt, het misschien niet het vermelden waard is als informatie over je inhoud?
Probeer bijvoorbeeld je licentie (indien anders dan de standaard copyright) zichtbaar in je document te plaatsen. Je kan toch niet verwachten van iedereen dat ze de nodige technische knowhow of tools hebben om onzichtbare metadata te ontsluieren?
Een voorbeeld van onzichtbare eRDF (in een meta tag):
<meta name="dc.license" content="Verwijzing naar het licentiemodel" />
Zoals je ziet bestaat het name attribuut uit namespace.naam (met een . als scheidingsteken in plaats van een -), en de content uit de beschrijving.
Als je wil, kan je ook een voorbeeld van deze vorm van metadata bekijken (*kuchsluikreclame ).
Ik meen me te herinneren dat verschillende bedrijven zoals Google hun interesse hebben getoond in het ondersteunen van standaarden zoals de Dublin Core, maar deze is ondertussen waarschijnlijk in het achterhoofd verdwenen .
Het is daarom aan ons, als personen van het jaar, om deze standaard tesamen met microformats te doen opleven. Viva la revolution!
In de nabije toekomst zal er dus waarschijnlijk een xslt document volgen om deze informatie te extraheren, in de vorm van een gratis tooltje. Stay tuned.
De meta keywords lijkt dus z’n beste tijd gehad te hebben, tenzij iemand er nog een nuttige toepassing voor weet?
