hCards for places

As I've noted on the wiki:

     <http://microformats.org/wiki/hcard-brainstor
ming#Named_locations>

the proposal to codify hCards for places by making the
"fn" and the
"extended-address" the same, though elegant, does
not work in all cases.

Consider an hCard for a City, "Birmingham,
England": Birmingham may be
the "fn" and the "locality", but it's
not an "extended-address".

Perhaps the rule should be that the hCard is for a place if
the "fn" is
on *any* address ("adr") child-component [1] (e.g.
"fn locality" or "fn
street-address")?

This would allow, for instance:


hCard for a small place:

        <foo class="vcard">
          <foo class="adr">
            <foo class="fn
extended-address">
                Hyde Park
            </foo>
          </foo>
        </foo>


hCard for a small town or city:

        <foo class="vcard">
          <foo class="adr">
            <foo class="fn locality">
                Boston
            </foo>
          </foo>
        </foo>


hCard for a state or county:

        <foo class="vcard">
          <foo class="adr">
            <foo class="fn region">
                Texas
            </foo>
          </foo>
        </foo>


hCard for a country:

        <foo class="vcard">
          <foo class="adr">
            <foo class="fn country-name">
                England
            </foo>
          </foo>
        </foo>


and even an hCard for a stand-alone postal code:

        <foo class="vcard">
          <foo class="adr">
            <foo class="fn postal-code">
                B1 1AA
            </foo>
          </foo>
        </foo>


The rule would require the two class names to appear
together on one
element, not merely that the values are the same; so, for
example, if a
model called "India" lives in the country
"India", these would be marked
up as separate attributes on two distinct elements:


        <foo class="vcard">
          <foo class="fn">
                India
          </foo>
          <foo class="adr">
            <foo class="country-name">
                India
            </foo>
          </foo>
        </foo>


[1] with the exception of "type", of course!

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

In message <LFX4o9lCqDeHFwnKpigsonthewing.org.uk>,
Andy Mabbett
<andypigsonthewing.org.uk> writes

>Perhaps the rule should be that the hCard is for a place
if the "fn" is
>on *any* address ("adr") child-component (e.g.
"fn locality" or "fn
>street-address")?
>
>This would allow, for instance:

Further testing shows that this pattern would have to be
excluded from
the "implied n optimisation" rule, which,
obviously, does not apply in
cases such as:

        <foo class="vcard">
          <foo class="adr">
            <foo class="fn locality">
                New York
            </foo>
          </foo>
        </foo>

Likewise "implied nickname optimisation":

        <foo class="vcard">
          <foo class="adr">
            <foo class="fn locality">
                Boston
            </foo>
          </foo>
        </foo>

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

I'm very late responding to this but...

Andy wrote:
> the proposal to codify hCards for places by making the
"fn" and the
> "extended-address" the same, though elegant,
does not work in all  
> cases.
>
> Consider an hCard for a City, "Birmingham,
England": Birmingham may be
> the "fn" and the "locality", but
it's not an "extended-address".
>
> Perhaps the rule should be that the hCard is for a
place if the  
> "fn" is
> on *any* address ("adr") child-component [1]
(e.g. "fn locality" or  
> "fn
> street-address")?

This strikes me as being pretty workable. I'm mentally
kicking the  
tyres and this seems like quite a robust solution.

I'd be interested to hear from Brian and/or Mike about how
tricky  
this might be to implement.

Effectively this would be creating a whole bunch of fn
shorthands.  
Right now we have:

fn org
fn nickname

With this solution we would also have:

fn post-office-box
fn extended-address
fn street-address
fn locality
fn postal-code
fn region
fn country-name

Bye,

Jeremy

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/


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

In message <AA5C1896-9B50-4730-BEAB-5143301EAD6Fadactio.com>, Jeremy
Keith <jeremyadactio.com> writes

>> Perhaps the rule should be that the hCard is for a
place if the
>>"fn" is
>> on *any* address ("adr") child-component
[1] (e.g. "fn locality" or
>>"fn
>> street-address")?
>
>This strikes me as being pretty workable. I'm mentally
kicking the
>tyres and this seems like quite a robust solution.

Thank you.

In that case, would people agree, or object, if we:

   1)   removed "or place" from the
"Organization Contact Info" section:

        <http://microformats.org/wiki/hcard#Organization_
Contact_Info>


   2)   added, after the section "Organization Contact
Info", a new
        section called "Place information", based
on the former, thus:

                If the "FN" and one of

                        "ADR"
                        "POST-OFFICE-BOX"
                        "EXTENDED-ADDRESS"
                        "STREET-ADDRESS"
                        "LOCALITY"
                        "REGION"
                        "POSTAL-CODE"
                        "COUNTRY-NAME"
                        "LABEL"

                are on the same element, (e.g.
class="fn
                extended-address"), then the hCard
represents a place
                and SHOULD be treated as such. In this case
the author
                also MUST NOT set the "N"
property, or set it (and any
                sub-properties) explicitly to the empty
string "". Thus
                parsers SHOULD handle the missing
"N" property, in this
                case by implying empty values for all the
"N"
                sub-properties.


   3)   changed the "Implied "n"
Optimization" rule:

        <http://microformats.org/wiki/hcard#Implied_.2
2n.22_Optimization>

        to:

                If "FN" and "ORG" are
not the same (see above); and "FN"
                is not on the same element as
"LABEL", "ADR", or one of
                the listed "ADR" child elements
(see above also); and
                the value of the "FN" property is
exactly two words...

        [I suggest that we make "above" and
"above also" links, or use
        the respective section names as linking text.]


   4)   changed the "Implied "nickname"
Optimization" rule:

        <http://microformats.org/wiki/hcard#Imp
lied_.22nickname.22_Optimization>

        to:

                Similar to the implied "n"
optimization, if "FN" and
                "ORG" are not the same; and
"FN" is not on the same
                element as "LABEL",
"ADR", or one of the listed "ADR"
                child elements; and the value of the
"FN" property is
                exactly one word, and there is no explicit
"N" property,
                then...


Note the addition, in (2) - (4), of "ADR", in its
own right, because:

        <foo class="vcard">
          <foo class="adr">
            <foo class="fn locality">
                New York
            </foo>
          </foo>
        </foo>

and:

        <foo class="vcard">
          <foo class="fn adr">
            <foo class="locality">
                New York
            </foo>
          </foo>
        </foo>

and

        <foo class="vcard">
          <foo class="fn adr">
            <foo class="locality">
                Dayton
            </foo>,
            <foo class="region">
                Ohio
            </foo>
          </foo>
        </foo>

are all equally acceptable.


Note also the inclusion of "LABEL", not previously
included in my
proposal, but logically of the same nature as
"ADR", and recommended for
use in place of "ADR" if the latter's required
granularity is not
possible, i.e.

        <foo class="vcard">
          <foo class="fn label">
              Dayton, Ohio
          </foo>
        </foo>


If there are any objections, please say to which of the
above points you
object, and whether you have a preferred alternative, or
object in
principle.


It is my view that items 3 and 4 are logical, and should be
done, even
if the first two are not adopted; since, say:

        <foo class="vcard">
          <foo class="adr">
            <foo class="fn locality">
                New York
            </foo>
          </foo>
        </foo>
and

        <foo class="vcard">
          <foo class="adr">
            <foo class="fn locality">
                Boston
            </foo>
          </foo>
        </foo>

are extremely unlikely to ever represent a person's name.

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

On 09/01/2008, Andy Mabbett <andypigsonthewing.org.uk>
wrote:
> In message <AA5C1896-9B50-4730-BEAB-5143301EAD6Fadactio.com>, Jeremy
> Keith <jeremyadactio.com> writes
>
> >> Perhaps the rule should be that the hCard is
for a place if the
> >>"fn" is
> >> on *any* address ("adr")
child-component [1] (e.g. "fn locality" or
> >>"fn
> >> street-address")?
> >
> >This strikes me as being pretty workable. I'm
mentally kicking the
> >tyres and this seems like quite a robust solution.
>
> Thank you.
>
> In that case, would people agree, or object, if we:
....

--- some additional time to review this would be nice.
Jeremy brought
this to my attention 2 days ago. Now we are asking to change
the spec.
More time is needed to fully look over the implications of
this
change.

thanks,
-brian


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

In message
<21e770780801082331w69a8f7fah5fc48b1f251c070email.gmail.com>, Brian
Suda <brian.sudagmail.com> writes

>On 09/01/2008, Andy Mabbett <andypigsonthewing.org.uk> wrote:
>> In message
<AA5C1896-9B50-4730-BEAB-5143301EAD6Fadactio.com>, Jeremy
>> Keith <jeremyadactio.com> writes
>>
>> >> Perhaps the rule should be that the hCard
is for a place if the
>> >>"fn" is
>> >> on *any* address ("adr")
child-component [1] (e.g. "fn locality" or
>> >>"fn
>> >> street-address")?
>> >
>> >This strikes me as being pretty workable. I'm
mentally kicking the
>> >tyres and this seems like quite a robust
solution.
>>
>> Thank you.
>>
>> In that case, would people agree, or object, if we:
....
>
>--- some additional time to review this would be nice.
Jeremy brought
>this to my attention 2 days ago.

The proposal was posted to the wiki and mailing list in the
early hours
of 31 December 2007:

  <http://microformats.org/
wiki?title=hcard-brainstorming&diff=prev&oldid=24038
>

  <http://microformats.org/d
iscuss/mail/microformats-discuss/2007-December/011169.html&g
t;

> Now we are asking to change the spec.
>More time is needed to fully look over the implications
of this
>change.

That's what you're being asked to do.

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

On 09/01/2008, Andy Mabbett <andypigsonthewing.org.uk>
wrote:
> If there are any objections, please say to which of the
above points you
> object, and whether you have a preferred alternative,
or object in
> principle.

--- i have updated my code locally and it seems to work
correctly. I
think we might be taking a backwards approach in editing the
spec.
Instead of defining a whole new sort of rule or short-cut,
what we are
really just doing is creating an exception when you follow
the
implied-n. The implied-n is triggered when there is no N.
All i did is
add an additional "AND FN is not on any ADR elements
(or LABEL)". So
the implied-n template is not called when FN is labeling a
place.I
think it is simple as that.

I suggest that we do NOT yet update the wiki until we get
some further feedback.

-brian

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

In message
<21e770780801101514x47ae185cl4703292c90d91ad9mail.gmail.com>, Brian
Suda <brian.sudagmail.com> writes

>On 09/01/2008, Andy Mabbett <andypigsonthewing.org.uk> wrote:
>> If there are any objections, please say to which of
the above points you
>> object, and whether you have a preferred
alternative, or object in
>> principle.
>
>--- i have updated my code locally and it seems to work
correctly.

Thank you. That's good to know, though not unexpected.

>I think we might be taking a backwards approach in
editing the spec.
>Instead of defining a whole new sort of rule or
short-cut, what we are
>really just doing is creating an exception when you
follow the implied-
>n. The implied-n is triggered when there is no N. All i
did is add an
>additional "AND FN is not on any ADR elements (or
LABEL)". So the
>implied-n template is not called when FN is labeling a
place.I think it
>is simple as that.

As I took pains to indicate in my proposal (items as
numbered):


   *    The spec should be updated to reflect the change you
describe
        (item 3).

   *    Implied-nickname is equally affected (item 4). For
example, in:

           <foo class="fn
locality">Birmingham</foo>

        "Birmingham" is not a nickname.


   *    The current "Organization Contact Info"
section:

          <http://microformats.org/wiki/hcard#Organization_
Contact_Info>

        says that it us used "for a company,
organization or place".
        This proposal would require that section to be
changed (item 1).


   *    The existence of the aforesaid "Organization
Contact Info"
        section implies that a matching "Place
information" section is
        equally required, not least for consistency (item
2).

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

On Jan 10, 2008, at 3:14 PM, Brian Suda wrote:
> On 09/01/2008, Andy Mabbett <andypigsonthewing.org.uk> wrote:
>> If there are any objections, please say to which of
the above  
>> points you
>> object, and whether you have a preferred
alternative, or object in
>> principle.
>
> --- i have updated my code locally and it seems to work
correctly.

Could you (or someone else?) please add some tests to the
test suite  
for this?

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

In message <FDBE85DC-AC37-48D8-A0B5-18C16F0E7F39theryanking.com>, ryan
<ryantheryanking.com> writes

>On Jan 10, 2008, at 3:14 PM, Brian Suda wrote:
>> On 09/01/2008, Andy Mabbett <andypigsonthewing.org.uk> wrote:
>>> If there are any objections, please say to
which of the above
>>>points you
>>> object, and whether you have a preferred
alternative, or object in
>>> principle.
>>
>> --- i have updated my code locally and it seems to
work correctly.
>
>Could you (or someone else?) please add some tests to
the test suite
>for this?

I'd be glad to, if you mean:

        <http://micro
formats.org/tests/hcard/>

How can files be uploaded?

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