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
urluri 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?
Beetje ingewikkeld artikel
zijn er al programma’s/websites/zoekmachines die deze informatie nuttig uitlezen? Met nadruk op nuttig.
Description is -zoals je zelf ook al zei- nog wel belangrijk. Websites met weinig tekstuele inhoud worden er van afhankelijk, voorbeelden als Flash websites, tabeldata, fotoboeken etc.
Meta keywords… ik weet het niet, ik vergeet ze steeds vaker…
Ik moet Arjan gelijk geven, lijkt me erg ingewikkeld zonder dat ik meteen een praktische toepassing ken.
In hoeverre overlapt dit met Microformats? Daar kan je wel al leuke dingen mee doen, zoals de Tails extensie voor Firefox of de Microformats bookmarklet. Dat is alleszins een veelbelovende beweging, die het web hopelijk wat sneller voorwaarts zal duwen dan de logge W3C…
Arjan: De enige tool die ik op dit moment voor eRDF gebruik, is die van Talis. En er zijn hier helaas nog geen nuttige toepassingen voor
behalve dan ‘in theorie’.
Michiel: Ik vermoed dat embedded RDF aan de basis van microformats ligt.
In die zin dat je bij eRDF eerst namespaces moet declareren, zodat je vervolgens classnames en dergelijke kan gebruiken om inhoud aan te duiden.
Microformats verschillen hierin doordat ze die eerste stap overslaan, en direct vastgelegde namen/relaties gebruiken in een document. Dit scheelt al een drempel, en vergemakkelijkt het aanduiden van bepaalde data.
Ze kunnen ook perfect op zichzelf bestaan in een document, wat de uitwisselbaarheid ervan alleen maar ten goede kan komen.
De operator toolbar is ook een leuk initiatief , en zo heeft bvb Technorati een mooie tool om een hCard te extraheren.
[...] Net zoals je informatie toegankelijk kunt maken voor computers met eRDF, mag je de mensen zélf niet vergeten (voor wie de informatie eigenlijk bestemd is). [...]
Microformats zijn geen toepassing van eRDF, http://structuredblogging.org/ is dat wel.
Microformats is er zelfs een beetje een reactie tegen RDF en grote, ambitieuze pogingen om alles in schema’s te gieten. Hun grote kritiek is dat meta-data toevoegen aan xhtml niet werkt omdat:
- het niet zichtbaar is, dus mensen niet gemotiveerd zijn het te gebruiken of het na een tijd toch vergeten
- die mensen die het dan wel gebruiken meestal … spammers zijn (denk maar aan de meta description tags in html)
Microformats zijn kleine toevoegingen aan al bestaande html, zodat die zowel door mensen als door machines leesbaar wordt. Structuredblogging, dat rond dezelfde tijd ontstond, is ondertussen zowat doodgebloed, maar ook het succes van microformats moet je relativeren: de meeste mensen en webmasters hebben er nog nooit van gehoord, en de tools die het gebruiken, blijven vooralsnog beperkt tot de webgeeks. Het is wachten tot Microsoft er zich achter zet (wat ze beloofd hebben BTW…).
Structured Blogging is een mooie vondst
zal de mogelijkheden van deze plug-in voor RDF zeker eens bekijken. Microformats implementeer ik het liefst zélf in de editor, net als eRDF (werkje voor na de examens, wanneer ik m’n wordpress template zal aanpassen).
Nu uitgekomen is dat Firefox slechts 1x per jaar een grote update zal uitbrengen verwacht ik dat Internet Explorer hetzelfde zal doen.
En de mensen uit Redmond zullen waarschijnlijk de functies van de operator toolbar in hun eigen browser implementeren. Wat een goed iets is, natuurlijk.
Embedded RDF is juist ontwikkeld als reactie op RDF, en het feit dat dit onzichtbare metadata is. Microformats zijn praktisch op dezelfde manier geimplementeerd, alleen zonder een bijhorend schema/namespace uitbereiding (waardoor de drempel om deze standaarden toe te passen ineens veel lager wordt). Naast dat de implementatie verschilt, hebben beide standaarden hebben overigens een totaal ander doel
beetje zoals met appels en peren vergelijken.
Maar zelfs met eRDF én Microformats kan je valsspelen. Denk maar bijvoorbeeld aan het verbergen met css door :before of :after, of display:none (een eigenschap die je html uit de pageflow hoort te nemen), of met javascript.
Zo wacht ik nu al ‘ongeduldig’ af wanneer ik het eerste misbruik hiervan voor bijvoorbeeld blackhat SEO tegenkom..
De description tag heeft nu nog slechts een functie om in bepaalde gevallen in de zoekmachine resultaatpagina weergegeven te worden. Maar de description tag was verder inderdaad onzichtbare metadata, waar men daarnaast niets mee kon aanvangen door spammers.
Deze nieuwe initiatieven zijn niet alleen voor zoekmachines bruikbaar (indien er van spam geen sprake is), maar ook voor mensen/software zélf bieden ze een belangrijke meerwaarde.