uid-brainstorming

UID Brainstorming

This page is for brainstorming about ideas, proposals, constraints, requirements for a UID microformat.

Authors

• Tantek Çelik
• Ed Summers

Experience

• a microformat for indicating something *is* an identifier rather than the solved problem of providing a microformat *for* identifiers (RFC 2396)

• Tantek has had conversations with LiveClipboard folks and upcoming.org who have had questions about how to do UID properly in hCard and hCalendar. So a separate microformat that those two could call out to would serve a real need.

• It would be useful for autodiscovery puposes to be able to follow a network resolvabale UID and extract more metadata from the referenced UID. Having a well defined UID pattern would prevent an explosion of rel values: rel-vcard, rel-vevent, etc.

• Efforts such as unAPI have a real need for marking up identifiers so that they can be used for retrieving identified objects.

• Greasemonkey and other browser based scripts could make real use of URIs found in pages as opposed to resorting to elaborate regexen. See Jon Udell's LibraryLookup project.

• GoogleScholar embed identifiers in their citations and it would enable moving citations from the browser to a citation manager greatly if there were a way to mark them up.

Goals Requirements

• a method of publishing an asserted globally unique identifier for a piece of content or a referenced item

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 that are 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 rather than 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?

Proposals

Just use UID from hCard

• Tantek proposed that we see if we can reuse uid from hCard, similar to how we have reused geo and adr from hCard.
• In particular we should define per the RFC2426 and RFC2445 definitions of UID, and also state that UID identifies the singular thing which this microformat is about (primary reference). (Thanks Joe Andrieu for this wording).
• Since microformats are about things published on the *Web*, we can say:
  • UIDs SHOULD be URLs and if you cannot use a URL (for whatever reason), then you SHOULD at least use a URI, thereby indicating our preference for UIDs which can be resolved to a network location, and barring that, UIDs which follow the URN registry.

Use rel-bookmark from 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.

Create a URI microformat

• 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

References

• adr
• geo
• hAtom
• hCard
• hCalendar
• abbr-design-pattern

See Also

• IANA URN Namespaces - RFC2141, RFC3406
• IANA Uniform Resource Identifer (URI) Schemes
• COinS for putting attaching openurl context objexts to a span.
• unAPI has a technique for embedding IDs in html so that they can be retrieved from an unAPI service.
• Tag URI an algorithm that lets people mint identifiers that no one else using the same algorithm could ever mint.

Related Discussion

• UID, URL, live microformats
• format for identifiers