representative-hcard-brainstorming

From Microformats Wiki
Jump to navigation Jump to search

representative hCard brainstorming

Proposals for indicating on pages that represent individual people which hCards represents that person. Part of the representative-hcard effort.


summary


current proposal

This proposal is the most current and has evolved from a number of other proposals to auto discover the representative hCard for a page, that is the hCard that is the person (or organization) that the page represents.

url uid source and rel me

By Ryan King, Tantek Çelik 2007-10-23.

The basic technique for finding the representative hCard for a page:

  1. uid=url=source. use the first hCard on the page which has uid=url=source. That is, the uid property value of the hCard is also a url property value for the hCard, and that URL is the URL of the page as well.
  2. rel="me" on class="url". otherwise use the first hCard which has a rel="me" class="url". That is, the first hCard that has a url property on an a href which also has rel="me". Since a rel-me hyperlink MUST be from a page that represents a person to another page that represents the same person, if that "to" page is a url property value for an hCard then that hCard MUST be representative of both the "to" page and the page that the hCard is on.
  3. otherwise no representative hCard can be identified.

user scenario

User scenario: Here is a scenario that outlines a proposed representative hCard auto-discovery process:

  1. I (as user) give the URL of my homepage or hCard or other profile URL, to a site that wants a profile icon
  2. That site goes and gets it (e.g. using hKit), and then:
    1. checks to see if there is an hCard with a "url" property equal to its "uid" property which is also the same as the URL of the page. if an hCard contains such a URL==UID that also points to the current page, then it is likely that the hCard is about the current page. (if there is more than one such hCard on the page, use the first such hCard.)
    2. if no such hCard was found, the site checks to see if there is an hCard with a "url" property on a rel="me" hyperlink (since rel="me" only works from a whole page to a whole page. if an hCard contains such a URL, then that hCard must represent the page. see XFN identity consolidation for more details.), and uses it if it finds it. (if there is more than one such hCard on the page, use the first such hCard.)
    3. otherwise uses the first hCard it finds. while this does not provide an explicit representative hCard, at least it falls back to providing *an* hCard which will work in many cases, e.g. profile URLs which have a single hCard like on Flickr and Technorati.
  3. The site looks in the hCard for a "logo" property and uses the first one if it finds any.
  4. Otherwise it looks for a "photo" property and uses the first one if it finds any.
  5. Otherwise the site uses a default icon, but subscribes to the URL with the hCard and checks it for a "logo" or "photo", say, once a day.


other proposals

Other (some historical) thoughts to auto discover the representative hCard for a page, that is the hCard that is the person (or organization) that the page represents.

rel me and url source else first

Originally collaboratively evolved on the hcard-brainstorming page:

  1. rel="me" on class="url". check to see if there is an hCard with a "url" property on a rel="me" hyperlink (since rel="me" only works from a whole page to a whole page, if an hCard contains such a URL, then that hCard must represent the page. see XFN identity consolidation for more details.), and uses it if it finds it. (if there is more than one such hCard on the page? for now use the first such hCard.)
  2. url=source. check to see if there is an hCard with a "url" property that points to the current page, and use it if you find it. similar to the above rel="me" case, if an hCard is pointing to the current page, then it is likely that the hCard is about the current page. (if there is more than one such hCard on the page? for now use the first such hCard.)
  3. otherwise use the first hCard you find (which in cases of profile URLs which have a single hCard like on Flickr and Technorati, will work as expected). (what about pages that don't represent individual people but have hCards? won't this result in false positives?)

user scenario

User scenario: Here is a scenario that outlines a proposed representative hCard auto-discovery process:

  1. I (as user) give the URL of my homepage or hCard or other profile URL, to a site that wants a profile icon
  2. That site goes and gets it (e.g. using hKit), and then:
    1. checks to see if there is an hCard with a "url" property on a rel="me" hyperlink (since rel="me" only works from a whole page to a whole page, if an hCard contains such a URL, then that hCard must represent the page. see XFN identity consolidation for more details.), and uses it if it finds it. (if there is more than one such hCard on the page? for now use the first such hCard.)
    2. checks to see if there is an hCard with a "url" property that points to the current page, and uses it if it finds it. similar to the above rel="me" case, if an hCard is pointing to the current page, then it is likely that the hCard is about the current page. (if there is more than one such hCard on the page? for now use the first such hCard.)
    3. checks to see if there is an <address> hCard (thus meaning contact for the page), and uses it if it finds it. (what if there is more than one such hCard on the page? e.g. such as the multiple address hCards for hAtom entries. for now use the first such hCard.)
    4. otherwise uses the first hCard it finds (which in cases of profile URLs which have a single hCard like on Flickr and Technorati, will work as expected).
  3. The site looks in the hCard for a "logo" property and uses the first one if it finds any.
  4. Otherwise it looks for a "photo" property and uses the first one if it finds any.
  5. Otherwise the site uses a default icon, but subscribes to the URL with the hCard and checks it for a "logo" or "photo", say, once a day.

class=representative vcard

Use of an additional class name, say class="representative vcard" (as an alternative to, or in addition to, the above patterns), would deal with the problems with the above proposals, as raised on representative-hcard-issues. It would also be quickly reusable for class="representative vevent" and other such microformats. A rule would require only one use of class="representative", per microformat, per page. Andy Mabbett 16:10, 2 Feb 2008 (PST)

  • As per Semantic XHTML Design Principles, wouldn't id="representative" be better than a class? TobyInk 09:01, 18 Feb 2008 (PST)
    • A page could have a representative hCard and a representative hCalendar (or some other pair of representative microformats); but ID can only be used once. A workaround (I state this for the record, not as a recommendation) would be ID="representative-hcard", etc. Andy Mabbett 09:31, 18 Feb 2008 (PST)

  • +0 (combined +1 and -1).

    +1: I believe the idea of class="representative" may be worthy of consideration at some point, as it provides a pattern that would automatically work for any microformat.

    -1: However for currently documented real-world cases of hCards it appears that the current proposal is sufficient, and similar rules can be used for hCalendar events, since hCalendar also has uid and url classes.

    Thus per the microformats design principle of minimal-vocabulary, we should avoid introducing another term (until there is a demonstrated need for something like representative hReview), but given potential future utility, it may be wise to reserve the term representative for this use at some point.

    Tantek 18:20, 3 June 2009 (UTC)

author hcard / contact hcard

TobyInk 10:24, 22 Mar 2008 (PDT):

Related to the concept of a representative hCard are the concept of the author hcard and contact hcard for a page. In many cases, all three will be the same hCard, though sometime they will differ. Here are some ideas for how to identify the author and contact hcards. (This section perhaps should be spun off as its own page?)

author hcard

An hCard linked to with rel="author" (for hysterical raisins, rev="made" should also be recognised), is the author hCard. A page may have multiple authors. rel="author" and rev="made" are defined by HTML 5.

hAtom already uses class="author vcard" to identify the feed author, which also has the advantage (or maybe limitation) that it does not have an existing 'applies to the whole page' semantic like rel does (consider a page of blog posts with different authors).

contact hcard

An hCard found in an <address> element represents the contact for the page, or for a major section of the page.

It is important to note that <address> is block level and may only contain inline elements, so is very hard to include into existing designs.

using XFN "me" link from page to hcard element

First add an id attribute to the element that carries the "vcard" class.

Then either publish this in the HEAD section of the page:

<link rel="me" href="#some_element_id" title="Contact Information" >

or publish this in the BODY of the page:

<a rel="me" href="#some_element_id">Contact Information</a>

Borrows the semantics of XFN's "me" relationship, saying "this element represents the same person as this page". Allows the page to link to the hcard rather than the other way around.

Can in theory be used to say that an hcard on a completely different page is the representative hcard for this page. Could be useful to avoid duplicating information if, for example, the site already has a "Contact Me" page:

<a rel="me" href="/contact.html#contactinfo">Contact Me</a>

The above doesn't necessarily imply that contact.html itself represents the same person as this page. contact.html might itself be about contacting several different people or departments.

If the hcard is indeed on a different page, it can reciprocate the link by linking back from within the hCard, ideally within the hCard "url" field. If the hCard is on the page it represents, this reciprocal link is implied. rel="me" should not be included on this link unless the page containing the hcard represents the same person as the target of the link, to avoid confusing XFN-only (i.e. non-hCard) parsers.

related pages

Retrieved from "http://microformats.org/wiki/index.php?title=representative-hcard-brainstorming&oldid=38949"