[uf-new] collection-design-pattern proposal

[Manu Sporny]

Danny Ayers wrote:
> Ok, I see what you're getting at. But if those things are in the same
> group, then why not group them in the HTML? Let the browser display
> the items in the same group in proximity. Humans first and all that.

One of the beautiful aspects of Microformats are that there is very
little that is required. Most Internet standards make a differentiation
between "MAY", "SHOULD" and "MUST". Microformat rules have very few "MUST"s.

What you are proposing is:

If you want to performing item grouping in Microformats you "MUST" put
the items in very close proximity to one another.

That is restrictive. It is a rule that we don't need to impose on
anybody as there are several solutions that don't require that rule to
exist. The less rules that there are, the more flexible and adaptable
the standard.

> Do you have any examples of data/markup where this wouldn't be
> appropriate?

There are at least 80-150 examples on scissorkick.com, here's one of them:

http://www.scissorkick.com/2007/03/battles/

In the blog post, the following album and songs are mentioned:

Artist: Battles
Album : Mirrored
Songs : Atlas, Tonto

They are not in list format - they are mentioned in free verse at
different points in the post. The blog poster (as is with most of the
postings) goes to great length to italicize albums and place quotation
marks around songs. They have a desire to mark this information up - but
don't seem to want to do it using any sort of list mechanism.

There are also around 70,000 examples on Bitmunk that have this type of
sparse item layout in album descriptions:

http://www.bitmunk.com/view/media/6068744

Artist: Celldweller
Album : Celldweller (self-titled)
Songs : Stay With Me (Unlikely), Switchback, The Last Firstborn,
        Own Little World, So Sorry to Say, Welcome to the End

>> 1. You are creating a 1-1 relationship, not an N-N relationship. URLs
>>    can only point to a single location, thus they are incapable of
>>    providing grouping information by themselves.
> 
> Sorry, the WebArch wonk in me grumbles there: URIs name things, links
> provide relationships between things. In the example above, grouping
> information is provided by the HTML. Also there's no reason links
> can't point into a list:
> 
> <ul>
>   <li><a name="one">one item</a></li>
>   <li><a name="two">another item</a></li>
> </ul>
> 
> <a href="#one" rel="self">item one again</a>
> <a href="#two" rel="self">item two again</a>
> 
> - no, I'm not sure about rel="self", but maybe something along these
> lines might work.

That's not the problem that we are trying to solve. Let me re-state the
problem in a different way:

You have a group G, and several items (A, B, C, D). Each are mentioned
in different places on a web page, not necessarily in any order. How do
you specify that A, B, C and D belong to group G?

>> 2. You are constraining the site design by forcing the need to use a
>>    URI. It doesn't give the site designer an option - it's the
>>    Microformat way or the highway at that point.
> 
> If entities are worth identifying on the web, they should be given
> URIs. It's in the site designer's interest for it to be possible to
> refer to them from elsewhere on the web.

Yes, but there is a big difference between "MUST", "SHOULD" and "MAY".
The argument that you proposed states that they "MUST" be identified by
URIs to be able to be grouped.

> Yes, thanks.
> But for these non-local, loose associations, won't you end up with
> machine-readable relationships embedded in the markup that aren't
> human-readable? I don't personally have a problem with that, but it
> does seem to be, er, not very microformatty. 

Yes, you are correct - we do end up with some machine-readable
relationships that are not formatted in list form using HTML. They are,
however, human-readable. I'm not saying that partial information hiding
is a good thing... but I haven't come across any mechanisms that would
allow us to provide N-to-N relationship markup using purely visible
HTML. If somebody has a proposal for doing so, please do speak up as
Danny and several others have outlined this as an undesirable effect of
the proposed methods thus far.

-- manu