uid-brainstorming: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
Line 49: Line 49:
* Tantek proposed that we see if we can reuse uid from [[hcard|hCard]], similar to how we have reused [[geo]] and [[adr]] from [[hcard|hCard]].
* Tantek proposed that we see if we can reuse uid from [[hcard|hCard]], similar to how we have reused [[geo]] and [[adr]] from [[hcard|hCard]].


=== create a URI microformat ===
=== 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.
* 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.

Revision as of 02:04, 26 April 2006

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, resolvability or uniqueness will be necessary because these issues are addressed by various URI specifications.

References

See Also

Related Discussion