|
List Info
Thread: PROPOSAL: keep it simple; make it extensible?
|
|
| PROPOSAL: keep it simple; make it
extensible? |
|
2006-11-18 21:36:06 |
Rather than trying to devise a microformat (hThing or hItem)
that can
describe any thing (or at least any physical thing), with
all the
possible or probable properties that might entail: would it
perhaps be
better to define a re-usable wrapper, and say that any
microformat(s) or
properties inside that wrapper apply to that thing?
Say:
<span class="hitem">
[hReview]
[other uFs]
</span>
Then apply secondary classes to the hItem as microformats
are developed
in future, say:
<span class="hitem wine">
[hReview]
[other uFs]
</span>
We could then use:
<span class="hitem">
<span
class="[property-name]">
<span
class="value">[n]</span>
</span>
</span>
or
<span class="hitem">
<span class="property">
<span
class="type">[property-type]</span>
<span
class="value">[n]</span>
</span>
</span>
for various properties or property-types ("abv",
say) as and when
they're required:
<span class="hitem wine">
[hReview]
<span class="abv">
<span
class="value">7.8</span>
</span>
</span>
or
<span class="hitem wine">
[hReview]
<span class="property">
<span
class="type">abv</span>
<span
class="value">7.8</span>
</span>
</span>
Or, where no "secondary class" exists, parsers
would simply infer that
the properties apply to the item:
<span class="hitem">
[hReview]
<span class="property">
<span
class="type">abv</span>
<span
class="value">7.8</span>
</span>
</span>
or could extract the nature of the item from a tag:
<span class="hitem">
<a rel="tag"
class="hitem-type"
href="http://
www.example.com/wine>Wine</a> News
[hReview]
<span class="property">
<span
class="type">abv</span>
<span
class="value">7.8</span>
</span>
</span>
or class:
<span class="hitem">
<span
class="hitem-type">Wine</span> News
[hReview]
<span class="property">
<span
class="type">abv</span>
<span
class="value">7.8</span>
</span>
</span>
Such properties could then be proposed and agreed more
speedily then
entire uFs.
Items could be nested, with any properties in the inner item
applying to
that, and not the outer item(s).
Alternative names could be "hThing" or
"hObject".
This post contains several "blue sky" proposals,
which can be considered
separately, if not as a whole.
(Note: "wine" and "abv" are used for
illustration only, and not to imply
any endorsement or otherwise to the current "wine"
proposal)
--
Andy Mabbett
Say "NO!" to compulsory ID Cards:
<http://www.no2id.net/>
Free Our Data: <http://www.freeourd
ata.org.uk>
_______________________________________________
microformats-discuss mailing list
microformats-discuss microformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss
|
|
| PROPOSAL: keep it simple; make it
extensible? |
|
2006-11-18 21:53:34 |
The fact that this effort seems vague and non-specific to
begin with
seems to preclude it from ever gaining adoption;
additionally, finding
existing behavior would be a challenge, not to mention the
limited
semantic usefulness of knowing that something is a
"thing" or "item".
What *specific* problem, captured in the wild, is this work
looking to solve?
Chris
On 11/18/06, Andy Mabbett <andypigsonthewing.org.uk>
wrote:
>
> Rather than trying to devise a microformat (hThing or
hItem) that can
> describe any thing (or at least any physical thing),
with all the
> possible or probable properties that might entail:
would it perhaps be
> better to define a re-usable wrapper, and say that any
microformat(s) or
> properties inside that wrapper apply to that thing?
>
> Say:
>
> <span class="hitem">
> [hReview]
> [other uFs]
> </span>
>
> Then apply secondary classes to the hItem as
microformats are developed
> in future, say:
>
> <span class="hitem wine">
> [hReview]
> [other uFs]
> </span>
>
>
> We could then use:
>
> <span class="hitem">
>
> <span
class="[property-name]">
> <span
class="value">[n]</span>
> </span>
>
> </span>
>
> or
>
> <span class="hitem">
> <span class="property">
> <span
class="type">[property-type]</span>
> <span
class="value">[n]</span>
> </span>
> </span>
>
> for various properties or property-types
("abv", say) as and when
> they're required:
>
> <span class="hitem wine">
>
> [hReview]
>
> <span class="abv">
> <span
class="value">7.8</span>
> </span>
>
> </span>
>
> or
>
> <span class="hitem wine">
>
> [hReview]
>
> <span class="property">
> <span
class="type">abv</span>
> <span
class="value">7.8</span>
> </span>
>
> </span>
>
>
> Or, where no "secondary class" exists,
parsers would simply infer that
> the properties apply to the item:
>
> <span class="hitem">
>
> [hReview]
>
> <span class="property">
> <span
class="type">abv</span>
> <span
class="value">7.8</span>
> </span>
>
> </span>
>
> or could extract the nature of the item from a tag:
>
> <span class="hitem">
>
> <a rel="tag"
class="hitem-type"
> href="http://
www.example.com/wine>Wine</a> News
>
> [hReview]
>
> <span class="property">
> <span
class="type">abv</span>
> <span
class="value">7.8</span>
> </span>
>
> </span>
>
> or class:
>
> <span class="hitem">
>
> <span
class="hitem-type">Wine</span> News
>
> [hReview]
>
> <span class="property">
> <span
class="type">abv</span>
> <span
class="value">7.8</span>
> </span>
>
> </span>
>
>
> Such properties could then be proposed and agreed more
speedily then
> entire uFs.
>
>
> Items could be nested, with any properties in the inner
item applying to
> that, and not the outer item(s).
>
>
> Alternative names could be "hThing" or
"hObject".
>
>
> This post contains several "blue sky"
proposals, which can be considered
> separately, if not as a whole.
>
>
> (Note: "wine" and "abv" are used
for illustration only, and not to imply
> any endorsement or otherwise to the current
"wine" proposal)
>
> --
> Andy Mabbett
> Say "NO!" to compulsory ID
Cards: <http://www.no2id.net/>
>
> Free Our Data: <http://www.freeourd
ata.org.uk>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discussmicroformats.org
> http://microformats.org/mailman/listinfo/microforma
ts-discuss
>
--
Chris Messina
Citizen Provocateur &
Open Source Ambassador-at-Large
Work: http://citizenagency.com
Blog: http://factoryjoe.com/blog
Cell: 412 225-1051
Skype: factoryjoe
This email is: [ ] bloggable [X] ask first [ ]
private
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss
|
|
| PROPOSAL: keep it simple; make it
extensible? |
|
2006-11-18 21:54:50 |
My current plan is (and has been) to keep it as simple as
possible and
_not_ to try to solve the "everything" problem. In
particular, my
current thinking is here [1] which basically says do the
same thing
with "item" from hReview/hListing as was done to
"adr" and "geo" from
hCard, add a missing field or two ("description"
in particular) and
then expect that future microformats (hWine) will composite
on top of
that.
The property-name/property-value thing I think is totally
out of scope
for _I_ want to do! I understand the potential value of that
and it's
probably worth an entirely exporatory series of wikipage of
it's own
(and there's lots of examples that can be drawn upon from
out on the
net, plus the work that's been done on microformats-rest).
If you
think it's worth tackling, I'll certainly contribute
examples from
what I've seen on the net.
I think that you've inverted the parent-child relationship
between
(say) a review and a item; that is, it is more natural to
expect the
item to be a child/attribute of the review rather than the
other way
around.
Regards, etc...
David
[1] http://microformats.org/wiki/item-brainstorming#DavidJ
anes
On 11/18/06, Andy Mabbett <andypigsonthewing.org.uk>
wrote:
>
> Rather than trying to devise a microformat (hThing or
hItem) that can
> describe any thing (or at least any physical thing),
with all the
> possible or probable properties that might entail:
would it perhaps be
> better to define a re-usable wrapper, and say that any
microformat(s) or
> properties inside that wrapper apply to that thing?
>
> Say:
>
> <span class="hitem">
> [hReview]
> [other uFs]
> </span>
>
> Then apply secondary classes to the hItem as
microformats are developed
> in future, say:
>
> <span class="hitem wine">
> [hReview]
> [other uFs]
> </span>
>
>
> We could then use:
>
> <span class="hitem">
>
> <span
class="[property-name]">
> <span
class="value">[n]</span>
> </span>
>
> </span>
>
> or
>
> <span class="hitem">
> <span class="property">
> <span
class="type">[property-type]</span>
> <span
class="value">[n]</span>
> </span>
> </span>
>
> for various properties or property-types
("abv", say) as and when
> they're required:
>
> <span class="hitem wine">
>
> [hReview]
>
> <span class="abv">
> <span
class="value">7.8</span>
> </span>
>
> </span>
>
> or
>
> <span class="hitem wine">
>
> [hReview]
>
> <span class="property">
> <span
class="type">abv</span>
> <span
class="value">7.8</span>
> </span>
>
> </span>
>
>
> Or, where no "secondary class" exists,
parsers would simply infer that
> the properties apply to the item:
>
> <span class="hitem">
>
> [hReview]
>
> <span class="property">
> <span
class="type">abv</span>
> <span
class="value">7.8</span>
> </span>
>
> </span>
>
> or could extract the nature of the item from a tag:
>
> <span class="hitem">
>
> <a rel="tag"
class="hitem-type"
> href="http://
www.example.com/wine>Wine</a> News
>
> [hReview]
>
> <span class="property">
> <span
class="type">abv</span>
> <span
class="value">7.8</span>
> </span>
>
> </span>
>
> or class:
>
> <span class="hitem">
>
> <span
class="hitem-type">Wine</span> News
>
> [hReview]
>
> <span class="property">
> <span
class="type">abv</span>
> <span
class="value">7.8</span>
> </span>
>
> </span>
>
>
> Such properties could then be proposed and agreed more
speedily then
> entire uFs.
>
>
> Items could be nested, with any properties in the inner
item applying to
> that, and not the outer item(s).
>
>
> Alternative names could be "hThing" or
"hObject".
>
>
> This post contains several "blue sky"
proposals, which can be considered
> separately, if not as a whole.
>
>
> (Note: "wine" and "abv" are used
for illustration only, and not to imply
> any endorsement or otherwise to the current
"wine" proposal)
>
> --
> Andy Mabbett
> Say "NO!" to compulsory ID
Cards: <http://www.no2id.net/>
>
> Free Our Data: <http://www.freeourd
ata.org.uk>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discussmicroformats.org
> http://microformats.org/mailman/listinfo/microforma
ts-discuss
>
--
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://www.onamine.com
http://blogmatrix.bl
ogmatrix.com
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss
|
|
| PROPOSAL: keep it simple; make it
extensible? |
|
2006-11-18 22:02:13 |
My primary goal is to document an existing behavior, that
items are
referred to and used in microformats today. If you'll care
to look at
the examples found so far and also the usage in existing
microformats,
you'll see that this is clearly an _existing behaviour_,
insofar as
hListing and hReview are used at all.
A nice benefit is providing a vocabulary for _new_
microformats to
refer to items in a consistent manner with _existing_
microformats.
You'll note that I started this discussion talking about
that we may
just be looking at a design pattern, though as mentioned in
my
previous letter I think this is something on par with
"adr" and "geo",
that is, an extraction from something that is already
happening.
Regards, etc...
On 11/18/06, Chris Messina <chris.messinagmail.com> wrote:
> The fact that this effort seems vague and non-specific
to begin with
> seems to preclude it from ever gaining adoption;
additionally, finding
> existing behavior would be a challenge, not to mention
the limited
> semantic usefulness of knowing that something is a
"thing" or "item".
>
> What *specific* problem, captured in the wild, is this
work looking to solve?
>
> Chris
>
--
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://www.onamine.com
http://blogmatrix.bl
ogmatrix.com
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss
|
|
| PROPOSAL: keep it simple; make it
extensible? |
|
2006-11-18 22:10:56 |
Fair enough. Awhile back I talked to Tantek about
"micro-patterns" as
opposed to data-bearing formats.
This seems more a discussion of design patterns and
templates than of
formats, but I'll give the examples a look over.
Chris
On 11/18/06, David Janes <davidjanesblogmatrix.com> wrote:
> My primary goal is to document an existing behavior,
that items are
> referred to and used in microformats today. If you'll
care to look at
> the examples found so far and also the usage in
existing microformats,
> you'll see that this is clearly an _existing
behaviour_, insofar as
> hListing and hReview are used at all.
>
> A nice benefit is providing a vocabulary for _new_
microformats to
> refer to items in a consistent manner with _existing_
microformats.
> You'll note that I started this discussion talking
about that we may
> just be looking at a design pattern, though as
mentioned in my
> previous letter I think this is something on par with
"adr" and "geo",
> that is, an extraction from something that is already
happening.
>
> Regards, etc...
>
> On 11/18/06, Chris Messina <chris.messinagmail.com> wrote:
> > The fact that this effort seems vague and
non-specific to begin with
> > seems to preclude it from ever gaining adoption;
additionally, finding
> > existing behavior would be a challenge, not to
mention the limited
> > semantic usefulness of knowing that something is a
"thing" or "item".
> >
> > What *specific* problem, captured in the wild, is
this work looking to
> solve?
> >
> > Chris
> >
> --
> David Janes
> Founder, BlogMatrix
> http://www.blogmatrix.com
> http://www.onamine.com
> http://blogmatrix.bl
ogmatrix.com
> _______________________________________________
> microformats-discuss mailing list
> microformats-discussmicroformats.org
> http://microformats.org/mailman/listinfo/microforma
ts-discuss
>
--
Chris Messina
Citizen Provocateur &
Open Source Ambassador-at-Large
Work: http://citizenagency.com
Blog: http://factoryjoe.com/blog
Cell: 412 225-1051
Skype: factoryjoe
This email is: [ ] bloggable [X] ask first [ ]
private
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss
|
|
| PROPOSAL: keep it simple; make it
extensible? |
|
2006-11-21 09:09:00 |
In message <H2fLkr4Gz3XFFwF8pigsonthewing.org.uk>,
Andy Mabbett
<andypigsonthewing.org.uk> writes
>
> <span class="hitem wine">
> [hReview]
> [other uFs]
> </span>
Another potential advantage to "hItem" would be an
alternative to the
"include"; for instance, an album on Amazon, say:
<http://www.amazon.co.uk/o/ASIN/
B000I0SGSA/ref=pd_rvi_gw_1/026-5782158-8338825>
could use
<div class="hitem album">
<span class="title">Ibm 1401 - a
Users Manual</span>
<span class="artist">Johann
Johannsson</span> [1]
<div class="hreview">[first
review]</div>
<div class="hreview">[second
review]</div>
<div class="hreview">[third
review]</div>
</div>
Where each hReview uses the title and artist (marked up also
according
to hReview) from its parent hItem.
[1] hcard committed for clarity
--
Andy Mabbett
Say "NO!" to compulsory ID Cards:
<http://www.no2id.net/>
Free Our Data: <http://www.freeourd
ata.org.uk>
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss
|
|
[1-6]
|
|