uid-brainstorming

From Microformats Wiki
Revision as of 16:14, 26 April 2006 by DanielChudnov (talk | contribs) (→‎Experience: unAPI retrieves objects, not just metadata)
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)
  • 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

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 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.

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

See Also

Related Discussion