On Tue, 2004-09-21 at 13:02, Frédéric Glorieux wrote:
> Je vais y arriver. Je pourrais me permettre de citer ce thread comme
> justification des choix prescrits ? En espérant que cette réflexion
> serve aussi vos projets...
Bien entendu.
>
> > Il y a des attributs, même "propriétaires" qui sont devenus suffisamment
> > habituels pour ne pas nécessiter de doc :-) ...
>
> L'enjeu est de produire du Dublin Core qui ne perturbe pas un engin
> standard de "moissonnage" (ex:nourir une base SQL de propriétés avec les
> noeuds textuels), et qui fournit de la valeur ajoutée pour ceux qui le
> veulent.
>
> Un autre exemple :
>
> Je cite
> <http://norman.walsh.name/2004/09/20/newLaptop.rdf>
>
> J'y lis
> <rdf:RDF ...>
> <rdf:Description
> rdf:about="http://norman.walsh.name/2004/09/20/newLaptop">
> <dc:creator
> rdf:resource="http://norman.walsh.name/knows/who#norman-walsh"/>
> </rdf:Description>
> </rdf:RDF>
>
> ou rdf:resource="http://norman.walsh.name/knows/who#norman-walsh" ne
> renvoit pas à un rdf:about dans le document
> comme
>
> <cc:license rdf:resource="http://creativecommons.org/licenses/by-nc/2.0/"/>
Tout à fait. Un document RDF n'a pas besoin d'être "complet", ce serait
contraire à la philosophie de RDF de l'exiger.
C'est au contraire une liste d'assertions élémentaires que l'on peut
compléter en lisant d'autres documents RDF.
Un des beautés de RDF est que la fusion de documents RDF est automatique
et immédiate (ce qui n'est pas le cas des documents XML) : on réunit
tout simplement plusieurs listes d'assertions.
C'est ce qui fait que RDF est aussi intéressant pour des applications
comme RSS, FOAF, DOAP, ... où on a besoin de réunir un "web" de
documents contenant chacun une petite part de "vérité".
> (Ce qui me convient très bien)
>
> par contre
>
> <t:person
> rdf:resource="http://norman.walsh.name/knows/taxonomy#PersonName;SteinWilliam"/>
>
> renvoit à
>
> <rdf:Description
> rdf:about="http://norman.walsh.name/knows/taxonomy#PersonName;SteinWilliam">
> <rdf:type
> rdf:resource="http://norman.walsh.name/knows/taxonomy#PersonName"/>
> <t:source
> rdf:resource="http://norman.walsh.name/2004/09/20/newLaptop"/>
> <t:firstname>William</t:firstname>
> <t:surname>Stein</t:surname>
>
> </rdf:Description>
>
> Pour je suppose créer l'entrée sur la personne à l'occasion de cette
> page, sans pour autant changer la forme de l'enregistrement de
> métadonnées, qui n'est pas plus enrichi qu'avant. Si cet exemple est
> conforme, cela me convient très bien.
Venant de Norm Walsh, je ne doute pas qu'il le soit :) ...
Il est conforme avec ce que je disais à propos de la séparation des
références et des déclarations.
> > Il n'y a pas d'avantage sur un plan strictement XML mais en adoptant une
> > syntaxe RDF vous permettez une deuxième lecture de votre document à un
> > niveau "RDF", par des outils RDF où il n'est plus vu comme un arbre mais
> > comme un graphe.
>
> Je crois que ce qui m'intéresse en premier lieu c'est que les
> métadonnées informent le public. Autrement dit, connaître l'auteur d'un
> texte, c'est important. Trouver une bio de cet auteur, c'est encore
> mieux. Depuis cette bio, avoir une biblio de ces travaux en ligne (au
> moins sur ce serveur), c'est vraiment utile. Je ne sais pas si choisir
> un espace de noms RDF peut m'y aider, mais je souhaite le même genre de
> navigation sur des concepts, ou des lieux.
Personnellement, je pense que vous auriez intérêt à utiliser RDF pour
tout ce qui est métadonnées, mais cela implique de payer "l'impôt RDF"
ajourd'hui pour un hypothétique bénéfice dans l'avenir.
L'utilisation de RDF permet comme je l'ai dit plus haut d'être certain
que vous pourrez facilement fusionner vos informations avec d'autres
informations saisies au format RDF (par exemple des canaux RSS décrivant
des nouveautés dans les mêmes domaines ou des documents FOAF décrivant
les auteurs de vos documents).
En chargeant vos métadonnées et les données complémentaires dans une
base RDF (en mémoire ou sur disque), vous pourrez immédiatement faire
des rapprochement entre tout cela.
A vous de voir si vous voulez payer l'impôt, mais il n'est peut-être pas
si cher qu'on veut bien le dire!
> > Si vous n'avez pas besoin de cette deuxième lecture, c'est effectivement
> > un impôt inutile pour vous. Sinon, cela ouvre d'autres portes.
>
> Je trouve excellent le mécanisme des mots clés xmlfr.
>
> >>Par exemple, pour signifier qu'un texte à une
> >>illustration privilégiée, qu'est-ce que vous conseilleriez ?
> >
> >
> > C'est un cas où l'attribut xlink:arcrole pourrait avoir une utilité,
> > comme dans :
> >
> > <lien xlink:type="simple"
> > xlink:arcrole="http://exemple.org/types/illustration+privil%e9gi%e9e/"
> > xlink:href="http://exemple.org/illustration/image.jpg">mon
> > illustration</lien>
> >
> > Mais il y a beaucoup de variations autour de cela, à commencer par:
> >
> > <illustration.privilégiée xlink:type="simple"
> > xlink:href="http://exemple.org/illustration/image.jpg">mon
> > illustration</illustration.privilégiée>
> >
> > et les variantes "maison" sont, me semble t-il, aussi "auto-documentées"
> > :
> >
> > <lien type="illustration+privilégiée"
> > href="http://exemple.org/illustration/image.jpg">mon illustration</lien>
> >
> > ou
> >
> > <illustration.privilégiée
> > href="http://exemple.org/illustration/image.jpg">mon
> > illustration</illustration.privilégiée>
>
> Il n'y pas un standard RSS pour associer une vignette à une ressource ?
Pas à ma connaissance, mais RSS 1.0 est si extensible...
>
> >> >>où l'on utilise xsi:type comme équivalent <meta scheme="...
> >> >>très important pour des metadonnées publiques
> >> >
> >> >
> >> > Je n'aime pas beaucoup, mais je suis allergique aux "QNames" de manière
> >> > générale :-) ...
> >>
> >>En Dublin Core/XML, j'aurai voulu dire un truc du genre
> >>
> >><dc:relation xlink:href="./ma+photo.jpg" xlink:type="simple"
> >>xsi:type="image/jpeg">Tu veux ma photo ?</dc:relation>
> >>
> >>Mais image/jpeg n'est pas un QName ? :o(
> >
> >
> > Non, et c'est plutôt une bonne chose!
> >
> >
> >>Me voilà condamné au propriétaire ? C'est tout de même triste d'avoir un
> >>xml DC moins expressif que du html:meta.
> >
> >
> > Est-ce que
> >
> > <dc:relation xlink:href="./ma+photo.jpg" xlink:type="simple" >Tu veux ma
> > photo ?</dc:relation>
> >
> > n'est pas propriétaire de toute manière dans la mesure où cela ne semble
> > pas bien conforme à http://dublincore.org/documents/dc-xml-guidelines/?
> >
> > Il semble que l'utilisation de XLink qui était conseillée en 2002
> > (http://www.ukoln.ac.uk/metadata/dcmi/dc-xml-guidelines/2002-01-31/) ne
> > l'est plus dans la dernière version de ce document...
>
> Sans vouloir jouer sur les mots, j'ai l'impression que des "guidelines"
> sont là pour donner des idées aux applications pilotes, laissant faire
> l'évolution naturelle pour voir ce qui tient. Mais bon, ce n'est pas une
> raison pour aller dans le sens contraire :o) Mais le DCMI essaye un peu
> trop de vendre ses termes, qui sont soit trop étendus, soit pas assez.
> Beaucoup d'institutions regrettent qu'ils aient abandonné leur modèle
> arborescent (date.created, date.issued, relation.IsVersionOf.translation
> ), cela permettait de l'indexation très fine sans effrayer les vieilles
> applis (l'investissement logiciel dans les institutions culturelles est
> lent) .
Oui, mais si vous utilisez les "mots" DC pour construire des phrases
dont la structure est différente de ce que font les autres applications,
quelle intéropérabilité pouvez vous atteindre?
>
>
> >>Tant que j'y suis est-ce que @xml:lang supporterait une locale comme
> >>celle ci <http://oss.software.ibm.com/icu/userguide/locale.html> ?
> >>
> >>J'ai besoin de dire des chose comme
> >><dc:creator xml:lang="??">Confucius</dc:creator>
> >><dc:creator xml:lang="zh_Latn">Kong Zi</dc:creator>
> >><dc:creator xml:lang="zh">"Le même en caractère chinois"</dc:creator>
> >>
> >>Et je vous en passe, j'ai des pharaons en égyptien ancien transcrit,
> >>avec leur nom biblique en araméen...
> >
> >
> > Je ne suis pas un spécialiste de ces questions, mais la recommandation
> > XML 1.1 fait référence à la RFC 3066 :
> >
> > http://w3.org/TR/2004/REC-xml11-20040204/#sec-lang-tag
> >
> > et cette RFC (http://www.ietf.org/rfc/rfc3066.txt) insiste sur le fait
> > que l'on doive chercher à identifier un langage tel que nous le parlons
> > :
> >
> > The language tag always defines a language as spoken (or written,
> > signed or otherwise signaled) by human beings for communication of
> > information to other human beings. Computer languages such as
> > programming languages are explicitly excluded.
> >
> > Le document auquel vous faites référence mélange au contraire le langage
> > utilisé (deux premiers caractères) et le script en faisant référence à
> > Unicode.
>
> Non, non. On parle vraiment d'écritures à destination humaine. Par
> exemple un nom d'auteur arabe peut être écrit en alphabet arabe (sans
> voyelles), en arabe transcrit en latin (avec voyelles, source
> généralement conservée dans les catalogues, car la version arabe peut
> s'en déduire, pas le contraire, et je ne vous parle pas de la
> transcription choisie qu'il faudrait préciser), ou même en alphabet grec
> (si un grec cherche dans sa langue et son clavier une photo ayant
> rapport à Al Farabi).
>
> > Cela mériterait confirmation mais ça ne me semble pas bien conforme à
> > l'esprit de la RFC 3066.
>
> Je crois que j'en ai trop besoin...
Vous pourriez reformuler la question dans un thread spécifique : les
spécialistes de la question (s'il y en a sur cette liste) n'ont
peut-être pas lu ce thread sur liens, RDF et XLink!
Eric van der Vlist
--
Carnet web :
http://eric.van-der-vlist.com/blog?t=category&a=Fran%C3%A7ais
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------
--
Devenez redacteur <XML>fr et contribuez au developpement du
xml francophone (http://xmlfr.org/infos/redacteurs/) !
Liste de diffusion "xml-tech@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet technique lie a XML.
Pour resilier votre abonnement, envoyez un message contenant
la commande "unsubscribe" a xml-tech-request@xmlfr.org
(mailto:xml-tech-request@xmlfr.org?Subject=unsubscribe)
Received on Tue Sep 21 13:24:12 2004
