rsvp-brainstorming

This article is a stub. You can help the microformats.org wiki by expanding it.

This is part of an effort to define an rsvp microformat for marking up rsvp notes posted on independent sites about or in-reply-to an event post. Per the microformats process:

• rsvp-examples
• rsvp-formats
• rsvp-brainstorming

analysis

From the news feed RSVP post example we know that event RSVP posts contain the following:

• attendee (photo, name, both linked to profile)
• RSVP status ("is going to")
• link to event post
• nested event post with:
  • photo
  • name (also linked)
  • start date and time
  • location (including venue, city/locality, state/region)
  • icons of other attendees (seven, likely most recent other RSVPs)
  • number of attendees
  • "Join" link (posts an RSVP to the event)
• web actions: "like", "comment", "share"
• time of RSVP
  • hyperlinked to permalink of RSVP post
• location when RSVP posted (little globe icon)

Much of this can be built from h-entry (for the RSVP), and h-event (for the nested event).

• h-entry
  • p-author h-card (for attendee photo, name, hyperlink)
  • dt-published (time of RSVP)
  • u-url (permalink to RSVP post)
  • p-location (re-use from h-event or p-geo h-geo, for pure latlong of where posted)
  • h-event (should this be on a specific property?)
    • u-photo (re-use from h-card)
    • p-name
    • dt-start (presumably optional dt-end)
    • p-location h-card (for venue, locality, region)
    • p-attendee h-card (for icons of other attendees, with alt text for names, and linked to their profiles)

The "action links" would be better represented as web actions:

• "Join"
• "Like" (favorite, bookmark)
• "Comment" (post a comment, reply)
• "Share" (post)

The only new things that an RSVP seems to need are:

• RSVP status ("is going to" from the example), which has been previously brainstormed here: hCalendar brainstorming: participation status
• and which event is this regarding - which seems very much akin to in-reply-to
  • an RSVP is just a reply to an event post, similar to a comment on a post

For the RSVP options it seem there are five distinct semantics

• Invited / has been invited, has not responded explicitly. You wouldn't post this yourself would you? Or do people post "I've been invited to ..." posts? Possibly. Examples?
• Yes / going
• No / explicitly not going
• Maybe / might be going, there's some intent to attend
• Tracking / interested - this appears to be distinct from Maybe. It's used by Plancast and Lanyrd, which don't have explicit "Maybe" options, and yet people use it differently than "Maybe". It's used almost to collect or recommend events - like bookmarking/linkblogging. Facebook allows you to similarly "Save" an event, e.g.

proposals

h-entry plus additions

Just use h-entry with a few extra properties

• h-entry
  • p-author h-card (for attendee photo, name, hyperlink)
  • dt-published (time of RSVP)
  • u-url (permalink to RSVP post)
  • p-location (re-use from h-event, substructure with h-card/h-adr/h-geo as needed)
  • u-in-reply-to (rel-in-reply-to) link to the event post
  • p-rsvp (new, enum, use <data> element or value-class-pattern)
    • "invited", "yes", "no", "maybe", "tracking", e.g. from the news feed example:
    • ... <data class="p-rsvp" value="yes">is going</data> to ..., or
    • ... <data class="p-rsvp" value="maybe">might go</data> to ...
    • ... <data class="p-rsvp" value="no">unable to go</data> to ...
    • ... <data class="p-rsvp" value="tracking">am tracking</data> ...

To keep it simple, we don't need need to markup the nested event - since it can be discovered at the in-reply-to link.

The re-use of p-location from h-event is probably something we should add to h-entry anyway - it certainly has use beyond RSVP posts.

Similarly, we should formally add u-in-reply-to to h-entry as it has shown usefulness for comment posts, now RSVPs, and will likely be useful for any other kind of post which is in regard to some other post.

Which leaves the only really new property p-rsvp.

h-entry plus additions discussion

• Is it worth introducing a separate/new h-rsvp top level microformat just for RSVPs for one new property?
  • I'm not sure it is worth introducing h-rsvp just for one new property. If further brainstorming shows RSVPs to need more than just one new property, we can reconsider. - Tantek
• Or should we simply add p-rsvp as an optional property to h-entry?
  • I'm leaning towards the latter, since that is fewer additions, and seems simpler. - Tantek
• Consider h-as-rsvp
  • Since RSVP is also a concept in activity-streams, and there has been some practice in the wild of annotating h-entries along with their activity stream object types (e.g. h-as-note, h-as-article, using -as- like a vendor prefix for activity streams concepts), it might be reasonable to annotate RSVP h-entry elements with h-as-rsvp as well. - Tantek