uid-brainstorming-fr

From Microformats Wiki
Revision as of 07:22, 19 December 2006 by ChristopheDucamp (talk | contribs) (translation to be achieved)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

UID Brainstorming

Cette page est pour brainstormer sur les idées, propositions, contraintes, exigences pour un microformat d'identificateur [[uid-fr|UID].

Auteurs

  • Tantek Çelik
  • Ed Summers

(traduction en cours Christophe Ducamp)

Expérience

  • un microformat pour indiquer quelque chose *est* un identificateur plutôt que le problème résolu de fournir un microformat *pour* les identificateurs (RFC 2396)
  • Tantek a eu des conversations avec les types de LiveClipboard folks et upcoming.org qui se sont posés des questions sur la façon de produire proprement des UID dans hCard et hCalendar. Ainsi un microformat séparé que ces deux appelleraient serviraient un besoin réel.
  • Il serait utile à des fins d'auto-découverte de pouvoir suivre un UID pouvant être résolu par le réseau et d'extraire plus de métadonnées de l'UID référencé. Disposer d'un modèle UID bien défini empêcherait une explosion des valeurs rel : rel-vcard, rel-vevent, etc.
  • Les efforts tels que unAPI ont un vrai besoin de baliser les identificateurs de façon qu'ils puissent être utilisés pour retrouver des objets identifiés.
  • Greasemonkey et d'autres scripts basés sur les navigateurs pourraient faire un réel usage des URIs trouvés dans les pages à l'inverse de retrier pour élaborer regexen. voir le projet LibraryLookup de Jon Udell.
  • GoogleScholar embarque les identificateurs dans leurs citations et cela permettrait de migrer les citations à partir du navigateur vers un gestionnaire de citations s'il y avait un moyen de les baliser.

Exigences des Objectifs

  • une méthode de publication un identificateur unique globalement certifié pour un morceau de contenu ou un item référencé.

Idées

UID + SOURCE -> permalink?

URL is used in hcalendar examples to point not to the permalink of the vevent, but to the permalink for the event home page. If the event home page contains the authorative hcalendar entry, that's fine. Alternatively the source attribute could be borrowed from vcard to mean "microformat permalink" instead of "permalink of the thing the microformat is about".

There seems to be a conflict between iCalendar and vCard rfcs as to what a url is. iCalendar says permalink of iCalendar object. vCard says identifying url (eg home page) of the person or object the vCard is about. vCard uses "source" for iCalendar's "url".

UIDs qui sont des URLs

It seems like in the 80% case (perhaps 99.99% case on the Web), a UID is going to be a URL, thus a common pattern will likely be things like:

<a class="url uid" href="http://example.com/contentspace/somenumber">the item</a>


SHOULD plutôt que MUST

A UID SHOULD be a URL rather than MUST. The UID microformat will ordinarily be a URL, but it should be flexible enough to allow it to contain non-network resolvable URIs.

UID + URL -> permalink?

Can you infer that if something is a URL and a UID that it is also a permalink? It seems so. I can't think of any semantic of "permalink" that isn't covered by the union of the semantics of URL and UID.

abbr pattern

Use the abbr-design-pattern to allow identifiers to be more fully described.

<abbr class="uid" title="urn:isbn:0950788120">0 9507881-2-0</abbr>

HTML ID attribute

How does/doesn't the ID attribute from HTML fit into all this? Can it be repurposed to help here?

Propositions

Utiliser simplement UID à partir de hCard

  • Tantek a proposé que nous regardions si nous pouvons réutiliser uid à partir de hCard, de la même façon que nous avons réutilisé geo et adr à partir de hCard.
  • En particulier nous devrions définir selon les définitions RFC2426 et RFC2445 de UID, et aussi déclarer que UID identifie la chose singulière que ce microformat traite (référence primaire). (Merci à Joe Andrieu pour cette formulation).
  • Parce que les microformats traitent de choses publiées sur le *Web*, nous pouvons dire :
    • Les UIDs DEVRAIENT être des URLs et si vous ne pouvez pas utiliser un URL (pour quelque raison), alors vous DEVRIEZ au moins utiliser un URI, indiquant par conséquent votre préférence pour les UIDs qui peuvent être résolues vers un lieu de réseau, et barrant cela, les UIDs qui suivrent l'enregistrement URN.

Utiliser rel-bookmark à partir de hAtom

hAtom currently uses the HTML standard rel-bookmark to identify its bookmark. This appears to be precisely eqivalent to the class combination "uid url". This does not appear to permit non-url uids, but if we are identifying the authorative id of a piece of microformatted data that we already have in-hand a non-url uid may never be required. Non-url uids (eg isbn) can still appear in citation formats without affecting the development of this "identify myself" microformat.

If rel-bookmark is not appropriate for this format, we should consider retrofiting this format back to hAtom. It may be appropriate to replace rel-bookmark with the separate url and uid classes, or to allow either form to be used.

Créer un microformat URI

  • Xiaoming proposed leaving UID intact in hcalendar and hcard, because whatever written in rfc2426/rfc2445 and their examples cannot be easily changed, and they seem to work well with hcalendar/hcard. Instead a new "URI" microformat should be established for the purpose of indicating something *is* an identifier in general.In this case you can easily reference URI RFC and no further elaboration about persistence, resolvability or uniqueness will be necessary because these issues are addressed by various URI specifications.
    • The problem with "just use URI" is that URI (or URL for that matter) merely is a *type* of data. What that data *means* to the microformat still needs additional semantics, and that's why we need a property name like UID (even if it is defined to be of type URI or URL) which specifies this particular semantic. Thanks to Joe Andrieu for asking the questions which lead to this clarification. - Tantek

Références

Voir aussi

Discussion en rapport