Le Vendredi 13 août 2010 à Paris
CC-BY-SA

RDFAoût, votre feuilleton de l'été : pendant un mois, 2 billets par semaine sur le RDFa, à l'attention des lecteurs connaissant déjà le HTML.

  • Épisode 1 : Au commencement était l'URI
  • Épisode 2 : Des triplets partout
  • Épisode 3 : Soyez brefs
  • Épisode 4 : De vieilles connaissances (1)
  • Épisode 5 : De vieilles connaissances (2)
  • Épisode 6 : Organiser la connaissance
  • Épisode 7 : Contenants, contenus et auteurs
  • Épisode 8 : Succès et limites

Notions abordées dans ce billet : Dublin Core, métadonnées... un billet plutôt court !

Des données sur les données

Il y a toujours eu un peu d'incompréhension à l'évocation de RDF et des métadonnées, car RDF a d'abord été créé comme un modèle de données spécifique aux métadonnées, avant de rapidement devenir un modèle de données général, à vocation presque universelle.

13 ans plus tard, cette confusion n'a pas disparu.

Les métadonnées sont les données à propos des données. C'est facile à comprendre. Prenez un document texte : les données sont le contenu textuel lui-même avec les titres, les paragraphes, les listes, les tableaux... les métadonnées sont son titre, son auteur, sa date de création...

Dans le vaste monde RDF, il existe plusieurs vocabulaires pour les métadonnées dont les plus connus sont issus du projet Dublin Core.

Souvenirs

L'usage de Dublin Core est très répandu, surtout en XML. Vous l'avez même peut-être déjà vu dans du code HTML, sous cette forme désormais obsolète (mais déjà basée sur un espace de nom et un préfixe, l'ancêtre du RDFa en quelques sortes) :

<link href="http://purl.org/dc/terms/" rel="schema.DC" />
<link href="http://www.example.org/disney" rel="DC.rights" />

Aujourd'hui, on écrirait ceci en RDFa :

<head xmlns:dc="http://purl.org/dc/terms/">
        <link rel="dc:rights" href="http://www.example.org/disney"/>
</head>

Ces deux exemples de code produisent le même triplet suivant :

Sujet Prédicat Objet
http://www.example.org/mickey http://purl.org/dc/terms/rights http://www.example.org/disney

Où la propriété http://purl.org/dc/terms/rights lie une ressource avec celle qui en détient les droits d'auteur ou d'exploitation.

Un vocabulaire double

Dublin Core Element Set

  • URI : http://purl.org/dc/elements/1.1/
  • Préfixe usuel : dc
  • 15 propriétés / 0 classes
  • Note : le vocabulaire historique

Dublin Core Terms

  • URI : http://purl.org/dc/terms/
  • Préfixes usuels : dc, dct, dcterms
  • 55 propriétés / 22 classes
  • Note : le vocabulaire étendu

En observant du code XML et/ou RDF utilisant Dublin Core, vous pouvez observer l'usage de deux URI différents pour Dublin Core. Il existe donc deux vocabulaires distincts :

  • Le premier, DC Elements Set, est apparu en 1998, quelques mois avant le RDF. Il ne comporte que des propriétés et ne permet de lier les ressources qu'il décrit qu'avec des valeurs littérales. Son usage est toujours très répandu même si ses limitations l'ont rendu obsolète. Il contient les propriétés les plus courantes : creator, date, description, format, language, subject, title...
  • Le second, DC Terms, a été formalisé en 2007 et étend le premier avec des classes, de nombreuses nouvelles propriétés et une révision des propriétés historiques, qui acceptent désormais aussi des ressources comme objet des triplets. C'est le vocabulaire que vous devez utiliser dans vos projets.

Par exemple, dc:creator peut désormais avoir comme objet une ressource de type foaf:Agent, et dc:subject une ressource de type skos:Concept.

FOAF ? SKOS ? Nous verrons ces nouveaux vocabulaires dans les prochains épisodes, en commençant par SKOS.

Commentaires

Pierre, Tu permets qu'à mon

Got

G
lespetitescases.net
Mercredi 18 août 2010 - 13:30

Pierre,

Tu permets qu'à mon tour, je fasse quelques remarques ;-)

1- la propriété dc:author n'existe pas en DC, il me semble que tu pensais plutôt à dc:creator (j'ai fait la même erreur dans mes premiers billets sur RDF ;-) ) ;

2- comme je te le disais en réponse à ton commentaire sur mon blog, les propriétés du DC elements SET ne contiennent pas de restrictions quant au co-domaine (c'est-à-dire le type de données ou la classe de la ressource en objet du triplet). Ainsi, tu peux utiliser indifféremment un ressource (c'est-à-dire une URI) ou un littéral.

3- Concernant dc:subject ou dcterms:subject, pas de co-domaine précisé, donc même chose, tu peux soit avoir un littéral, soit une ressource de type skos:Concept voire même une ressource d'un autre type.

4- Concernant dc:creator, le cas est plus complexe, il n'est pas explicitement exprimé le fait que le co-domaine de dc:creator est foaf:Agent. En fait, le co-domaine exprimé est dcterms:Agent (<rdfs:range rdf:resource="http://purl.org/dc/terms/Agent"/>) mais dans la mesure où dcterms:Agent est noté comme classe équivalente à foaf:Agent dans l'ontologie FOAF (cf. http://xmlns.com/foaf/spec/index.rdf) ce que tu dis est juste, mais par inférence.

5- Je pense moi aussi qu'il vaut mieux utiliser DC Terms plutôt que DC elements. Néanmoins, DC terms recelant quelques pièges puisque certains co-domaines sont précisés, il est parfois plus simple d'utiliser et de préconiser DC elements, surtout quand on débute dans ce vaste monde du Web sémantique.

Sur la structure du DC et les différents ensembles DC, je te conseille la lecture de ce billet chez Figoblog : http://www.figoblog.org/node/1911

Bonjour Got, pas de soucis

pierre

Profile picture for user pierre
Mercredi 18 août 2010 - 19:13

Bonjour Got, pas de soucis pour les remarques, j'en suis même demandeur car elles me permettent de progresser et d'améliorer la qualité de mes billets.

Mes réponses :

1. Oui, c'est une boulette qui a un air de déjà vu et qui est typiquement francophone (Wikipedia, Alsacréations...). C'est corrigé, merci.

2. Ça, c'est une sacrée remise en cause de ma vision des deux vocabulaires Dublin Core ! Je pensais que si on mettait une URI comme objet d'un triplet basé sur dc:subject (ce qui est évidemment possible), on obtenait "http://example.org/resource" et non <http://example.org/resource&gt;. Une mise à jour va s'imposer.

3. Effectivement, une ressource de type skos:Concept n'est ici qu'un exemple de ce qu'il est possible d'avoir comme objet de triplet. Mais c'est un bon exemple.

4. Je n'ai pas l'intention de traiter l'inférence dans cette série de billets (trop complexe et pas assez pragmatique pour ma cible).

5. Ce billet, comme tous les autres, est en effet destiné à ceux qui connaissent bien HTML mais peu ou pas RDF.

Je connaissais ce billet de Manue, une référence. Le prochain "épisode" de cette saga estivale concernera SKOS, je l'ai presque fini, mais je pense désormais que je vais bien le relire avant de le publier.

Et désolé pour le déterrage de vieux billet ! :-)

Pierre, Concernant "on

Got

G
lespetitescases.net
Mercredi 18 août 2010 - 23:02

Pierre,

Concernant "on obtenait http://example.org/resource" et non <http://example.org/resource&gt;, cela ne dépend pas du modèle mais de la façon dont tu sérialises/exprimes le triplet.

Imaginons que tu sérialises tes triplets en RDFa, si tu as <link rel="dc:subject" href="http://dbpedia.org/resource/Dublin_Core"/>, l'attribut @rel indique que l'objet est une ressource, donc cela correspond à <http://example.org/ta-page> dc:subject
<http://dbpedia.org/resource/Dublin_Core>.

En revanche si tu as <span property="dc:subject">http://dbpedia.org/resource/Dublin_Core</span>, l'attribut @property indique que l'objet est un littéral, donc cela correspond <http://example.org/ta-page> dc:subject "http://dbpedia.org/resource/Dublin_Core".

Du point de vue du vocabulaire Dublin Core, ces deux assertions sont justes, mais la deuxième ne signifie rien d'un point de vue logique et sémantique, car dans ce cas l'URI est une chaîne de caractère comme les autres. Est-ce
plus clair ?

Pour foaf:Agent en co-domaine de dc:creator, je suis d'accord que l'inférence est un mécanisme complexe, je voulais juste préciser qu'a priori le vocabulaire Dublin Core ne précise pas qu'il est possible d'avoir un foaf:Agent en objet de dc:creator mais que cela était possible par inférence avec le vocabulaire FOAF.

Pas de soucis pour le déterrage, ces billets sont aussi là pour ça ;-)

En effet, la sérialisation

pierre

Profile picture for user pierre
Vendredi 20 août 2010 - 07:53

En effet, la sérialisation explicite le type de nœud et ma réflexion était en amont, au niveau du schéma. Tu as répondu à mon interrogation avec cette phrase : cela ne dépend pas du modèle mais de la façon dont tu sérialises/exprimes le triplet.

C'est en effet plus clair et je reformulerai le paragraphe de ce billet qui est ainsi remis en cause. Mais d'abord, les autres épisodes !

It was wondering if I could…

Binasa

B
Lundi 27 février 2017 - 20:24

It was wondering if I could use this write-up on my other website, I will link it back to your website though.Great Thanks.

Le contenu de ce champ sera maintenu privé et ne sera pas affiché publiquement.
À propos des formats de texte

HTML simple

  • Les adresses de pages web et les adresses courriel se transforment en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.