[uf-new] Revisiting grouping problem solution proposal: hset
Martin McEvoy
martin at weborganics.co.uk
Wed May 23 13:49:39 PDT 2007
On Wed, 2007-05-23 at 20:34 +0100, Martin McEvoy wrote:
> On Wed, 2007-05-23 at 14:19 -0400, Manu Sporny wrote:
> > Brian Suda wrote:
> > > On 5/22/07, Manu Sporny <msporny at digitalbazaar.com> wrote:
> > >> We need a way to create the concept of an audio collection (an album).
> > >> The same can be said for video and images - how do you relate these
> > >> items to one another?
> > >
> > > --- i completely agree
> >
> > Well, at least we agree on that :)
> >
> > > The Problem statement for your grouping is:
> > >
> > > It is useful to understand the relationship between objects on a
> > > website.
> > > ...
> > > that is too generic, OBJECTS on a WEBPAGE? for things like Events, we
> > > needed a container, so a CALENDAR container was created. For ENTRIES
> > > we created hFeed. These sort of groupings are handled at the format
> > > level, not a generalized hSet.
> >
> > We are starting to "solve" this container problem over and over again.
> > We've already created redundant container/grouping/set mechanisms:
> >
> > vcalendar for vevents
> > hfeed for hentry
> >
> > Where do we go from here?
> >
> > halbum for haudio
> > hpodcast for haudio
> > hfilm for hvideo
> > hmultimedia for haudio and hvideo combinations
> > htvseries for hvideo
> >
> > Every single one of these containers does the exact same thing - it
> > contains OBJECTS. Why are we calling them different things when they're
> > really the same thing. Why are we willing to pollute the Microformats
> > namespace with halbum, hpodcast, hfilm, hmultimedia, and htvshow? They
> > are just variations on the same theme - grouping.
> >
> > I understand your position, Brian. In general, Microformat grouping
> > should be developed on a case-by-case basis.
> >
> > However, when it is clear that we are going to have to create multiple
> > new Microformat elements that do the /exact same thing/ - we should
> > start to question if this problem should not be solved in a more general
> > way.
> >
> > >> I'm having a hard time understanding what is so complex about:
> > >>
> > >> hset.GROUP_ID.OBJECT_ID
> > >
> > > --- to me this makes no sense? in traditional programing languages the
> > > dot notation is used for member functions which are usually VERBS. The
> > > Person Object has a function getName(), Person.getName().
> >
> > No, in traditional programming languages, dot notation is used to
> > separate package names or object members and methods. It is the de-facto
> > method of grouping in most modern programming languages.
> >
> > C:
> > --------------------------
> >
> > void (*operation)();
> > struct foo
> > {
> > int bar;
> > operation do_operation;
> > }
> >
> > foo f;
> > f.bar = 5;
> > f.do_operation();
> >
> > C++
> > --------------------------
> >
> > class Foo
> > {
> > public:
> > int bar;
> > void doOperation() {};
> > }
> >
> > Foo f = new Foo();
> > f.bar = 5;
> > f.doOperation();
> >
> > Python
> > ---------------------------
> >
> > class foo:
> > def __init__(self):
> > self.bar = 0
> >
> > def do_operation(self):
> > pass
> >
> > f = Foo()
> > f.bar = 5
> > f.do_operation()
> >
> > C#
> > ----------------------------
> >
> > public class Foo
> > {
> > public int bar;
> >
> > public void doOperation() {};
> > }
> >
> > f = new Foo()
> > f.bar = 5;
> > f.doOperation();
> >
> > Javascript
> > ----------------------------
> > class Foo
> > {
> > var bar:Integer = 0;
> > function do_operation() {}
> > }
> >
> > var f = new Foo();
> > f.bar = 5;
> > f.do_operation()
> >
> > We would be adopting something that has stood the test of time - we
> > wouldn't be re-inventing the wheel.
> >
> > > The
> > > hset.GROUP_ID.OBJECT_ID tells me nothing.... not even XML or RDF or
> > > other mark-up languages use this? everything is done by nesting an
> > > OBEJCT_ID in a GROUP_ID in an hSet.
> >
> > It tells you one thing - that if something else has the same GROUP_ID,
> > it belongs to the same group. It tells you that there is a relationship
> > between two objects.
> >
> > > --- the simplest solution is just to choose a semantic class value for
> > > your container, we already have 'vcalendar', 'hfeed', which act in
> > > this capacity. Those are the simplest solutions, lets start there, and
> > > itterate.
> >
> > We did start there. Iteration has brought us to the understanding that
> > we are going to "solve" this problem over and over again if we don't do
> > something about it. Increasing the number of container elements will
> > only pollute the Microformats element space with unnecessary grouping
> > mechanisms that do the exact same thing.
> >
> > > We want to make this as easy as possible for publishers, not parsers.
> > > The vast majority of the people publishing microformats do not have
> > > PhDs in computer science. We tend to forget that something that seems
> > > easy for us might be completely over the heads of others.
> >
> > Using dot notion is not a foreign concept to anybody that has written
> > CSS. May I remind you that this is a common practice in CSS:
> >
> > h1.highlight {
> > color: yellow;
> > }
> >
> > This will make any <h1> element that has a class of 'highlight' to
> > appear yellow.
> >
> > If using dot-notation is such a big problem, we could always use a
> > different character, such as '-' or '_'.
> >
> > hset_foo
> > hset_foo_bar
> > hset_foo_baz-bat
> >
> > or
> >
> > hset-foo
> > hset-foo-bar
> > hset-foo-baz_bat
> >
> > or
> >
> > hset:foo
> > hset:foo:bar
> > hset:foo:baz-bat
> >
> > The suggestion to use '.' was made because it is the most common form of
> > denoting group membership, that doesn't mean we're stuck with it.
> >
> > -- manu
> >
>
> Its quite obvious that a simpler solution has to be found,
>
> Manu I get what you are trying to do I just think it is a bit much for
> many people to take on board, and a bit much for a microformat.
>
> So here is another ^^ simple proposal...
>
> Im trying to "Start with something *as simple as possible*, perhaps
> even *simpler*"
>
> Talking about rev attributes is kind of taboo for mF the same as
> "namespaces" but only because people generally misunderstand what rev
> means nothing else,
>
> In short rev means:
>
> rev = The relationship between the target URL and the current document
>
> HTML-401 says:
>
> "This attribute is used to describe a reverse link from the anchor
> specified by the href attribute to the current document."
>
> http://www.w3.org/TR/html401/struct/links.html#adef-rev
>
>
> we can create relationships in hset this way
>
> <h1>Album Title</h1>
>
> <a href="..." rev="part-of">track 1</a>
>
> <a href="..." rev="part-of">track 2</a>
>
> <a href="..." rev="part-of">track 3</a>
>
> This says our links are "part-of" the current document?
sorry this should be rev="has-part"
This says our link "has-part" or the current document
>
> Truthfully I don't think we would have to declare "hset" as the
> "part-of" should be enough for a phraser or browser to look for other
> parts and identify that this is a grouping or set on the current
> document.
>
> This proposal sets aside all hang ups about ".", id, and css.
>
> anyway feel free to comment flame, have fun ;)
>
>
> -Martin-
> > _______________________________________________
> > microformats-new mailing list
> > microformats-new at microformats.org
> > http://microformats.org/mailman/listinfo/microformats-new
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2171 bytes
Desc: not available
Url : http://microformats.org/discuss/mail/microformats-new/attachments/20070523/8ce835fe/smime-0001.bin
More information about the microformats-new
mailing list