[uf-new] collection-design-pattern proposal
danny.ayers at gmail.com
Tue Apr 24 15:55:56 PDT 2007
On 25/04/07, Manu Sporny <msporny at digitalbazaar.com> wrote:
> Danny Ayers wrote:
> > On 24/04/07, Manu Sporny <msporny at digitalbazaar.com> wrote:
> >> collection: a non-localized, unstructured grouping of items.
> >> list : a localized, structured grouping of items.
> > Hmm, <ul> is semantically an unordered grouping...
> Almost correct. <ul> is a /localized/ unordered grouping. We are
> attempting to find a way to do both non-localized, localized, structured
> and unstructured grouping of items.
> <ul> + xoxo solves the problem of localized unordered groups.
> <ol> + xoxo solves the problem of localized ordered groups.
> Both the scenarios above don't solve the problem of grouping items like so:
> <li>Related Item 1</li>
> <li>Related Item 2</li>
> ... A text or HTML ...
> <li>Related Item 3</li>
> <li>Related Item 4</li>
> How can we show that all four of those items are in the same group?
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.
Do you have any examples of data/markup where this wouldn't be
> >> The following is needed beyond the examples you gave:
> >> - The ability to relate items that are not local to one another in an
> >> HTML page.
> > doesn't this do that:
> > <ul>
> > <li>here</li>
> > <li><a href="#elsewhere">an item</a></li>
> > </ul>
> It kinda does do that. There are two reasons I think that proposal is
> not desirable:
> 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:
<li><a name="one">one item</a></li>
<li><a name="two">another item</a></li>
<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.
> 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.
> >> - The ability to relate items on an unstructured basis.
> > Sorry, I don't understand what you mean - isn't a collection a
> > structure by definition?
> A collection and a list are both structures by definition, yes. I should
> have used different vocabulary to define the concept.
> When I said structured - I was talking about a strict hierarchical
> representation. The XML and HTML text formats have a strict hierarchical
> representation. They are deterministic data structures. They are lists.
> When I said unstructured - I was talking about a loosely coupled
> association. An example of this is the concept of a Set in mathematics.
> These are collections.
> Did that help clarify what was meant by "unstructured"?
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. If you want conceptual
associations that are out of band when it comes to the (X)HTML, I
can't help thinking of RDF ;-)
More information about the microformats-new