grouping-brainstorming

tacoore

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>

Pro:

• Supports all types of grouping

Con:

• Anchors are used, displaying links that may confuse the person that is browsing.
• Using IDs are not very microformatty and only support one ID.

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

Cons:

• Needs the concept of keywords.
• More verbose than is needed. ManuSporny 21:18, 14 May 2007 (PDT)
• Difficult to recognize if something is a grouping member until reading the entire identifier. ManuSporny 21:18, 14 May 2007 (PDT)

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.

Option 7: id-class grouping

This problem solution proposal was put forward by Chris Griego:

  <span id="internal-event" class="hset vcalendar">Internal</span>
  and <span id="with-client-event" class="hset vcalendar">With-Client</span> Events
  <ol>
  <li class="with-client-event vevent"><span class="summary">FOO Sales
  Pitch</span> [...]</li>
  <li class="internal-event vevent"><span class="summary">Company
  Picnic</span> [...]</li>
  <li class="with-client-event vevent"><span class="summary">BAR Photo
  Shoot</span> [...]</li>
  </ol>

Using the hset class names attaches special meaning to the element's ID value, marking it as the machine-readable group name, and then any other element in the document with a class name that matches the ID should be considered a set member. The class attribute is a natural grouping mechanism, by simply marking contacts across the internet with 'vcard' we've grouped them in the category of contact information.

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.
• It splits the specification of a set into two parts (id and class).
• It is impossible to define two top-level sets (option #3 allows this).
• It mixes identifiers and class names (option #3 doesn't need this).
• It uses IDs - something Microformats want to avoid (option #3 doesn't need this).
• It is more complex than option #3, requiring greater cognitive load on the author.

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