uid-brainstorming

From Microformats Wiki
Revision as of 02:02, 26 April 2006 by Ed Summers (talk | contribs) (added xiaoming's proposal for a uri microformat)
Jump to navigation Jump to search

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)

Goals Requirements

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

Thoughts

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* rather than *must* be a URL. 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>

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.

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/resovlable/uniqueness, because these issues are addressed by various URI specifications.

References

See Also

Related Discussion