Nested Microformats and Operator

I've recently started to look into using some microformats
on one of my 
projects and have been playing with Operator to get an idea
of how they are 
being used elsewhere.

Operator is a great way to see what microformats are
contained on a page, but 
I think it might confuse the average user when a page
contains a lot of 
nested data using core microformats such as hCard, adr,
hCalendar, etc.

For example on a LinkedIn public profile:
http://www.linke
din.com/in/steveganz

You see 1 hResume, 1 adr, 10 hCard's, and 7 hCalendar's.

In this case all the hCalendar events are from the
experience part of the 
resume.  I don't see any use for adding these to Google
Calendar or exporting 
them.  Also 9 of the hCard's wouldn't make sense to export
or add to Yahoo 
Contacts since they contain only very basic information.

An other example is a Google Maps search.  In this case each
result produces a 
hCard and contains an adr.  Ideally these would be combined
and shown as 
Contacts with addresses. Then each contact could be exported
or viewed in 
Google or Yahoo maps.

Have these types of issues been discussed before?  Is there
a way that a user 
script can hide nested data?

I understand the value of reusing the core microformats and
creating composite 
microformats.  I think that in many cases users will want to
interact with 
the primary composite format while still preforming actions
based on the 
nested content.

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

I wanted Jason to bring this up on the list because it is
an
interesting discussion.

We display lots of stop in Operator (especially in hResume)
that can't
actually be used.

hCalendars for experience are interesting, but unuseful as
hCalendars.
And hCards for
my employment at a past employer aren't terribly interesting
either.

Should there be a way for people to have this information
but not make
it available
as a vcard or vevent?

Mike

On 8/27/07, Jason Calabrese <mailjasoncalabrese.com>
wrote:
> I've recently started to look into using some
microformats on one of my
> projects and have been playing with Operator to get an
idea of how they are
> being used elsewhere.
>
> Operator is a great way to see what microformats are
contained on a page, but
> I think it might confuse the average user when a page
contains a lot of
> nested data using core microformats such as hCard, adr,
hCalendar, etc.
>
> For example on a LinkedIn public profile:
> http://www.linke
din.com/in/steveganz
>
> You see 1 hResume, 1 adr, 10 hCard's, and 7
hCalendar's.
>
> In this case all the hCalendar events are from the
experience part of the
> resume.  I don't see any use for adding these to Google
Calendar or exporting
> them.  Also 9 of the hCard's wouldn't make sense to
export or add to Yahoo
> Contacts since they contain only very basic
information.
>
> An other example is a Google Maps search.  In this case
each result produces a
> hCard and contains an adr.  Ideally these would be
combined and shown as
> Contacts with addresses. Then each contact could be
exported or viewed in
> Google or Yahoo maps.
>
> Have these types of issues been discussed before?  Is
there a way that a user
> script can hide nested data?
>
> I understand the value of reusing the core microformats
and creating composite
> microformats.  I think that in many cases users will
want to interact with
> the primary composite format while still preforming
actions based on the
> nested content.
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discussmicroformats.org
> http://microformats.org/mailman/listinfo/microforma
ts-discuss
>
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On 8/27/07, Mike Kaply <microformatskaply.com> wrote:

> And hCards for
> my employment at a past employer aren't terribly
interesting either.

I brought this up before[1]. While its the semantic thing to
do its
not overly useful.


> Should there be a way for people to have this
information but not make
> it available
> as a vcard or vevent?

I would say yes.


Would it be possible in the case of the hResume to ignore
the nested
hCards and hCalendars and to make a "primary"
hCard that could be then
downloaded?

I guess this then leads into the question (but may be off
topic): is
there a way for the entire hResume to be downloaded and not
just the
parts?

- Andrew

[1]http://microformats.org/discuss/ma
il/microformats-discuss/2007-May/009685.html
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

> Should there be a way for people to have this
information but not make
> it available
> as a vcard or vevent?

or a way to tell what kind of thing the vevent or vcard
represents?
(so that a parser can work out how it should be displayed
based on criteria 
chosen by the user)

I think there may be another similar problem with using
hCalendar data with 
nested hCards or adr's.

Is a nested hCard or adr or geo in a vevent for the
venue/location of the 
event
or is it for the organiser of the event
or for someone attending the event?

other possibilities exist too - such as where to get tickets
for an event...

Marking up the venue location is probably the most common
use of nested 
hCard in hCalendar but the other cases are certainly
possible.

How would a parser know which it is?



_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

> Should there be a way for people to have this
information but not make
> it available as a vcard or vevent?

The user-action class or new protocols proposed in the
Firefox 3  
thread could address this problem (10 hCards in an hResume).
 Since  
these pieces of microformatted content probably would not
contain a  
user-action (or link with a particular protocol), the
browser would  
not expose them to the user.

-Alex



On Aug 27, 2007, at 7:14 PM, Mike Kaply wrote:

> I wanted Jason to bring this up on the list because it
is an
> interesting discussion.
>
> We display lots of stop in Operator (especially in
hResume) that can't
> actually be used.
>
> hCalendars for experience are interesting, but unuseful
as hCalendars.
> And hCards for
> my employment at a past employer aren't terribly
interesting either.
>
> Should there be a way for people to have this
information but not make
> it available
> as a vcard or vevent?
>
> Mike
>
> On 8/27/07, Jason Calabrese <mailjasoncalabrese.com> wrote:
>> I've recently started to look into using some
microformats on one  
>> of my
>> projects and have been playing with Operator to get
an idea of how  
>> they are
>> being used elsewhere.
>>
>> Operator is a great way to see what microformats
are contained on  
>> a page, but
>> I think it might confuse the average user when a
page contains a  
>> lot of
>> nested data using core microformats such as hCard,
adr, hCalendar,  
>> etc.
>>
>> For example on a LinkedIn public profile:
>> http://www.linke
din.com/in/steveganz
>>
>> You see 1 hResume, 1 adr, 10 hCard's, and 7
hCalendar's.
>>
>> In this case all the hCalendar events are from the
experience part  
>> of the
>> resume.  I don't see any use for adding these to
Google Calendar  
>> or exporting
>> them.  Also 9 of the hCard's wouldn't make sense to
export or add  
>> to Yahoo
>> Contacts since they contain only very basic
information.
>>
>> An other example is a Google Maps search.  In this
case each  
>> result produces a
>> hCard and contains an adr.  Ideally these would be
combined and  
>> shown as
>> Contacts with addresses. Then each contact could be
exported or  
>> viewed in
>> Google or Yahoo maps.
>>
>> Have these types of issues been discussed before? 
Is there a way  
>> that a user
>> script can hide nested data?
>>
>> I understand the value of reusing the core
microformats and  
>> creating composite
>> microformats.  I think that in many cases users
will want to  
>> interact with
>> the primary composite format while still preforming
actions based  
>> on the
>> nested content.
>>
>> _______________________________________________
>> microformats-discuss mailing list
>> microformats-discussmicroformats.org
>> http://microformats.org/mailman/listinfo/microforma
ts-discuss
>>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discussmicroformats.org
> http://microformats.org/mailman/listinfo/microforma
ts-discuss

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

In message <002a01c7e934$88a2a480$116baccaCOMCEN>, Michael MD
<mdagnspraci.com> writes

>> Should there be a way for people to have this
information but not make
>> it available
>> as a vcard or vevent?
>
>or a way to tell what kind of thing the vevent or vcard
represents?
>(so that a parser can work out how it should be
displayed based on
>criteria chosen by the user)

Yes; greater granularity is good.

>I think there may be another similar problem with using
hCalendar data
>with nested hCards or adr's.
>
>Is a nested hCard or adr or geo in a vevent for the
venue/location of
>the event
>or is it for the organiser of the event
>or for someone attending the event?

Consider hCalendars, with class="location vcard"
for the event's venue.
It's the job of parsers to distinguish between such hCards,
and, say,

        class="attendee vcard"

and
        class="organizer vcard"

(I note that "attendee", "contact" and
"organizer" are listed in the
hCalendar spec, but not the cheat-sheet. Do any current
parsers
recognise them? Should we also have a "speaker" or
similar class?

-- 
Andy Mabbett
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

In message 
<1e76a9d60708272010x52264b3fjaefde6d2c4b14c59mail.gmail.com>, Andrew 
Jaswa <ajaswagmail.com> writes

>Would it be possible in the case of the hResume to
ignore the nested 
>hCards and hCalendars

Only if that's a user-configurable option, please. Some of
use Operator 
for debugging.

-- 
Andy Mabbett
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

In message <fVT9sQr$VA1GFwo1pigsonthewing.org.uk>,
Andy Mabbett
<andypigsonthewing.org.uk> writes

>I note that "attendee", "contact"
and "organizer" are listed in the
>hCalendar spec, but not the cheat-sheet.

Fixed; but their status needs to be codified; and examples
provided on
the relevant 'wiki' pages.

I note that the iCalendar RFC <http://www.ie
tf.org/rfc/rfc2445.txt>
states that :

        4.8.4.1

        ATTENDEE.

        Conformance: This property MUST be specified in an
iCalendar
        object that specifies a group scheduled calendar
entity. This
        property MUST NOT be specified in an iCalendar
object when
        publishing the calendar information (e.g., NOT in an
iCalendar
        object that specifies the publication of a calendar
user's busy
        time, event, to-do or journal). This property is not
specified
        in an iCalendar object that specifies only a time
zone
        definition or that defines calendar entities that
are not group
        scheduled entities, but are entities only on a
single user's
        calendar.

and:

        4.8.4.2

        CONTACT

        Description: The property value consists of textual
contact
        information. An alternative representation for the
property
        value can also be specified that refers to a URI
pointing to an
        alternate form, such as a vCard [RFC 2426], for the
contact
        information.

and:

        4.8.4.3

        ORGANIZER

        Conformance: This property MUST be specified in an
iCalendar
        object that specifies a group scheduled calendar
entity. This
        property MUST be specified in an iCalendar object
that specifies
        the publication of a calendar user's busy time. This
property
        MUST NOT be specified in an iCalendar object that
specifies only
        a time zone definition or that defines calendar
entities that
        are not group scheduled entities, but are entities
only on a
        single user's calendar.


So we need to decide whether we adhere to those rules or
adopt a more
relaxed approach, and leave it to parsers to adhere to them
when
exporting vEvents.

-- 
Andy Mabbett
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On 8/28/07, Mike Kaply <microformatskaply.com> wrote:
> hCalendars for experience are interesting, but unuseful
as hCalendars.
> And hCards for my employment at a past employer aren't
terribly interesting either.

--- well, thatīs the tricky part. It might be un-interesting
to you
personally right this minute but not for all times and all
people.

> Should there be a way for people to have this
information but not make
> it available as a vcard or vevent?

--- i think this falls into the "let the market sort it
out".
Microformats only define the markup. How it gets rendered in
a GUI,
what parts are extracted, how apps deal with nested data, is
 outside
the scope of the FORMAT.

If Operator chooses to be "smart" and not add
class="location vcard"
to the list of hCards because it is a VENUE address, then
that is
completely up to the application. The FORMAT itself does not
have
control of that. What will drive these answers is when
people WANT
operator to detect it and it doesnīt then they move to a
competitor's
plugin... if Operator wants more market share, then it
"gets smarter"
and uses more heuristics, checking if a
class="experience vevent"
exists and tries to deal with it appropriately. Just look
now, with
vCards, Outlook and Apple and others import or don't import
certain
fields... that is an application choice, not something
controlled by
the spec.

On 8/28/07, Michael MD <mdagnspraci.com> wrote:
> or a way to tell what kind of thing the vevent or vcard
represents?
> (so that a parser can work out how it should be
displayed based on criteria
> chosen by the user)

Microformats have ALWAYS been about pushing the hard work to
parsers
NOT the publishers. So i would suggest we avoid trying to
invent
anything which explicitly tells parsers "this is a
vcard, but not in
this circumstance, unless it is this a specific parser and
the day is
equal to the BBDAY in the vcard" That is WAY to much
work for
publishers, let the few parsers do all the heavy lifting.

by using things like class="education vevent"
parser can determine
further that it is a "typed" event of education.
How and What the
parser does, should (IMHO) be left up to the parser. Maybe a
"smart"
and a "verbose" mode.

On 8/28/07, Andrew Jaswa <ajaswagmail.com> wrote:
> Would it be possible in the case of the hResume to
ignore the nested
> hCards and hCalendars and to make a "primary"
hCard that could be then
> downloaded?

--- it certainly could. Nothing in the hCard/hCalendar spec
says that
you MUST display all data you found, even if it is annoying,
in error
and pisses off the user. Operator and other could attempt to
"be
smart" and not (or display differently) the data inside
an hResume.
The problem with "being smart" is that you will be
wrong too, and you
need to decide if you want to field Q&A and bugs about
why hCard ARE
or ARE NOT appearing, because depending how they choose to
"be smart"
someone will think it is the wrong way.

> I guess this then leads into the question (but may be
off topic): is
> there a way for the entire hResume to be downloaded and
not just the
> parts?

this is not really even public, but i spent some time
working on XSLT
to convert hResume to XML:
http
://suda.co.uk/projects/microformats/hresume/

On 8/28/07, Michael MD <mdagnspraci.com> wrote:
> Is a nested hCard or adr or geo in a vevent for the
venue/location of the
> event or is it for the organiser of the event
> or for someone attending the event?

--- there currently are parsing rules for singleton instance
of
properties. Both hCalendar and hCard can take a GEO
property. The
first GEO property found after the root property (vcard or
vevent)
will be used as the GEO for that instance. So something like
the
following code would NOT get confused:

- vevent
-- hcard & location
--- geo
-- vcard attendee
--- geo

this would correctly associate the GEO with the right
groupings.

that said, there has not been much work around attendees and
other
people properties associated with vevents. Partly due to
lack of
interest, implementations and focus on higher priority
things.

> Marking up the venue location is probably the most
common use of nested
> hCard in hCalendar but the other cases are certainly
possible.
>
> How would a parser know which it is?

--- i donīt see this as an issue. the iCalendar spec does
NOT have
structured data for the location, so the class="vcard
location", no
matter what follows, structured or unstructured would be
correctly
found by the iCalendar parser due to the
class="location" multiple
instances of a class="vcard" would not effect
this.

A "smart" parser could look for both the
"location vcard" combination
and ignore other class="vcards" that might be used
to describe people,
ticket sales, etc. But in some instances you actually DO
WANT those
other vcards to be pulled out by operated and displayed
somehow so you
can go get tickets.

On 8/28/07, Paul Wilkins <paul_wilkinsxtra.co.nz> wrote:
> A parser could provide the ability to extract just the
top-level elements.

--- correct, nothing prohibits this. The tricky thing is
that ADR and
GEO are independant, so inside an hCard they
should/shouldnīt be
ignored? for display reasons i agree, for export reasons you
should
keep as much data together. But generally, yes in Operator
you COULD
not display vevent and vcard that are nesting in an hresume
- that is
completely up to the parser.

> The other elements could be accessed from a tree view,
if you're looking
> at an overall structural view.

--- i like these suggestions. They are examples of ways to
solve the
problem, #1 independent of the spec or the format. #2 put
the work on
the parser, not the publisher, #3 can easily evolve with the
times,
the GUI, etc rather than potentially be baked incorrectly
into the
specs and ruin it for the future.

This is more of an discussion point for parsers and plugins
than for
the specs. My vote is to let the parsers do what they THINK
is best
and we vote collectively with our installs and/or bug
reports.

Also, if there are specific parsing questions, then please
take them
to the mf-dev list.

-brian

-- 
brian suda
http://suda.co.uk

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

I'm going to reply to a couple of posts:

> Only if that's a user-configurable option, please. Some
of use Operator
> for debugging.

I think the debug mode should always show all the available
microformat 
elements.


> A parser could provide the ability to extract just the
top-level elements.
>
> The other elements could be accessed from a tree view,
if you're looking
> at an overall structural view.
>
> If you're looking at hcards, they could be notated to
indicate which
> ones are embedded and which ones are not.

I like the idea of using a tree view.  It seems like the
presentation of 
nested elements should determinded by the user scripts for
the composite 
microformats.

For example the hResume script could some tell Operator not
to show the nested 
hCard's and hCalendar events and then display the nested
data in a tree like 
structure if it make sense to display the nested elements. 
This way the 
contact hCard of an hResume would be displayed as a nested
menu item if you 
are using the toolbar, but the other hCards and vevents
wouldn't be 
displayed.

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss