grouping-brainstorming

Discussion Participants

Editors

• Manu Sporny, Bitmunk - Digital Bazaar, Inc.

Contributors

• Manu Sporny
• Danny Ayers
• Rudy Desjardins
• Scott Reynen

Purpose

It is useful to understand the relationship between objects on a website. A blogger may want to describe several different objects on a web page and group them explicitly. It is important that the structure of the page not affect this grouping as network relationships are often not hierarchical (HTML is always hierarchical).

Where an object resides in a network of relationships can clarify its purpose. For example, an audio album can have a number of audio tracks. It is desirable that the tracks and the album can be associated with one another without needing to be hierarchically grouped. The same goes for chapters in a DVD movie, sections of a podcast, and a set of geographic points.

Grouping relationships are fundamental to how we understand object interactions. The purpose of this brainstorming session is to create possibilities for a grouping proposal.

Possible Solutions

Option 1: Implicit grouping

<div class="haudio">
   <span class="collaborator hcard fn">Ammonite</span>
   <span class="work-title">Reconnection</span>
   <div class="haudio">
      <span class="work-title">Sunset</span>
   </div>
</div>

Pros:

• Less verbose for grouping markup.
• No extra collection Microformat necessary.

Pro/con:

• Grouping is handled on a uF by uF basis. Might not be consistent.

Cons:

• Impossible to know if nested microformats belong to the group.
• Does not allow for sparse (unstructured) grouping.

Option 2: Explicit id-based grouping

<div id="reconnection" class="haudio">
   <span class="collaborator hcard fn">Ammonite</span>
   <span class="work-title">Reconnection</span>
</div>
[...]
<div id="reconnection.sunset" class="haudio">
   <span class="work-title">Sunset</span>
</div>

Pros:

• Explicitly defined groups.
• Grouping is solved for all Microformats.
• Allows for sparse grouping.

Cons:

• New type of Microformat/design pattern may emerge.
• Parser may have to become more complex.
• Use of id isn't very microformatty.

Option 3: Explicit class-based grouping

<div class="haudio grouping.reconnection">
   <span class="collaborator hcard fn">Ammonite</span>
   <span class="work-title">Reconnection</span>
</div>
[...]
<div class="haudio grouping.reconnection.sunset">
   <span class="work-title">Sunset</span>
</div>

Pros:

• Explicity defined groups.
• Grouping is solved for all Microformats.
• Fits more with the Microformat way than Option #2
• Allows for sparse grouping.

Cons:

• Parser may have to become slightly more complex.

Option 4: id-class grouping with anchors

<div class="haudio" id="reconnection">
  <span class="collaborator hcard fn">Ammonite</span>
  <span class="work-title">Reconnection</span>
</div>
[...]
<div class="haudio reconnection">
  <span class="work-title">Sunset</span>
  Part of <span class="part-of"><a name="#reconnection">Reconnection</a></span>
</div>

Option 5: class-based grouping with keywords

<div class="haudio reconnection">
  <span class="collaborator hcard fn">Ammonite</span>
  <span class="work-title">Reconnection</span>
</div>
[...]
<div class="haudio reconnection.member">
  <span class="work-title">Sunset</span>
</div>

Pros:

• Uses class instead of id.
• Supports the class attribute being used as an implicit indication of set-membership.
• Indicates the direction of the relationship, ie: which item is the container, as opposed to just using 'albumname' as a class value for both album and song, which would ambiguously indicate that both things are part of a group called 'albumname'.
• Is subject-agnostic - this approach can be used for any type of grouping where one item is contained by another.
• Works for N-N relationships, ie: class="album.member soundtrack1.member soundtrack2.member".

Option 6: per-microformat grouping

It has been proposed that we should not attempt to create a grouping mechanism that spans all Microformats. Scott Reynen writes:

My current proposal is to keep grouping semantics specific to each
individual microformat.  In this case, albums could be identified by
something like class="album", audio tracks by something like
class="audio-track", and parsers could simply recognize that albums are
groups of tracks, just as hatom parsers recognize that feeds are groups
of entries.  Of course, I still think hatom could cover most of the
semantics of audio downloads.

Pros:

• Grouping can be fine-tuned to the particular Microformat
• We avoid the name-spacing issue entirely.

Pro/Con:

• There wouldn't be a standard method of grouping items.

Cons:

• Grouping hell - a new mechanism of grouping would have to be created for every Microformat.
• Many different methods of grouping would look almost exactly the same, leading to redundant, per-uF methods of grouping. ManuSporny 06:33, 2 May 2007 (PDT)
• This would lead to an explosion in uF class names: album, speech, podcast, audio-track, speech-section, podcast-part, video, video-clip, geo-set, waypoint, etc.
• Due to the explosion in class names, it would be difficult for web developers to remember every method of grouping.

Possible Uses

This section describes potential applications for an audio info microformat.

Transformational Uses

It may be desirable to process an audio blog using a transformational tool, such as XSLT, to produce a different representation that can be used elsewhere - such as in a REST invocation.

Archival Uses

Being able to scrape information from a web page and store it long term may be desirable for search companies.

See Also

• grouping-examples
• grouping-formats
• grouping-proposal