[uf-discuss] geo shorthand in anchor
Sarven Capadisli
If a "geo" property lacks explicit "latitude" and "longitude"
subproperties, then the "geo" property is treated like any other string
property (e.g. following rules for parsing <abbr title>, <img alt>
etc.), where that string value has the same literal syntax as specified
in RFC 2426 section 3.4.2: single structured value consisting of two
float values separated by the SEMI-COLON character (ASCII decimal 59),
specifying latitude and longitude, in that order.
My question is, whether the following is, should, or should not be a
valid geo representation:
<a href="http://www.geonames.org/6077243" title="45.5140800;-73.6111000"
class="geo">Montréal, Quebec, Canada</a>
-Sarven
_______________________________________________
microformats-discuss mailing list
microforma...@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Brian Suda
> My question is, whether the following is, should, or should not be a
> valid geo representation:
>
> <a href="http://www.geonames.org/6077243" title="45.5140800;-73.6111000"
> class="geo">Montréal, Quebec, Canada</a>
--- that's a good question. Since the semantics of an "a" element are
for the href, but GEO doesn't make sense as a URI, i would say that it
would default to the visible text, just as if you had:
<span title="45.5140800;-73.6111000" class="geo">Montréal, Quebec, Canada</span>
There isn't a compelling argument to take the @title over the node
value, "Montréal, Quebec, Canada"
does that make sense?
-brian
--
brian suda
http://suda.co.uk
Sarven Capadisli
> On Sun, Dec 27, 2009 at 5:51 PM, Sarven Capadisli <in...@csarven.ca> wrote:
> > My question is, whether the following is, should, or should not be a
> > valid geo representation:
> >
> > <a href="http://www.geonames.org/6077243" title="45.5140800;-73.6111000"
> > class="geo">Montréal, Quebec, Canada</a>
>
> --- that's a good question. Since the semantics of an "a" element are
> for the href, but GEO doesn't make sense as a URI, i would say that it
> would default to the visible text, just as if you had:
>
> <span title="45.5140800;-73.6111000" class="geo">Montréal, Quebec, Canada</span>
>
> There isn't a compelling argument to take the @title over the node
> value, "Montréal, Quebec, Canada"
>
> does that make sense?
> -brian
>
Yea, it does. Thanks for brining up the semantics of <a> for @href.
As far as geo links are concerned, I think it does make some sense as a
URI.
So, the next question is, should parsers pick up the geo data from the
anchor, ignore, or do whatever they want with it?
-Sarven
Brian Suda
> Yea, it does. Thanks for brining up the semantics of <a> for @href.
>
> As far as geo links are concerned, I think it does make some sense as a
> URI.
>
> So, the next question is, should parsers pick up the geo data from the
> anchor, ignore, or do whatever they want with it?
--- the better question is, "are people publishing it this way?" If
collect enough example, then we can make a better determination.
-brian
--
brian suda
http://suda.co.uk
Sarven Capadisli
> On Wed, Dec 30, 2009 at 8:50 PM, Sarven Capadisli <in...@csarven.ca> wrote:
> > Yea, it does. Thanks for brining up the semantics of <a> for @href.
> >
> > As far as geo links are concerned, I think it does make some sense as a
> > URI.
> >
> > So, the next question is, should parsers pick up the geo data from the
> > anchor, ignore, or do whatever they want with it?
>
> --- the better question is, "are people publishing it this way?" If
> collect enough example, then we can make a better determination.
>
> -brian
AFAIK:
The StatusNet platform as of version 0.9RC1 e.g.,
http://identi.ca/notice/17811123
Potentially, publicly documented sites at
http://status.net/wiki/ListOfServers on update.
http://*.status.net/ as well.
-Sarven
Brian Suda
> AFAIK:
>
> The StatusNet platform as of version 0.9RC1 e.g.,
> http://identi.ca/notice/17811123
>
> Potentially, publicly documented sites at
> http://status.net/wiki/ListOfServers on update.
--- great, can you add/start a page on the wiki to document these?
that way we can find common formats and any emerging syntaxes.
-brian
--
brian suda
http://suda.co.uk
Sarven Capadisli
> On Wed, Dec 30, 2009 at 10:09 PM, Sarven Capadisli <in...@csarven.ca> wrote:
> > AFAIK:
> >
> > The StatusNet platform as of version 0.9RC1 e.g.,
> > http://identi.ca/notice/17811123
> >
> > Potentially, publicly documented sites at
> > http://status.net/wiki/ListOfServers on update.
>
> --- great, can you add/start a page on the wiki to document these?
> that way we can find common formats and any emerging syntaxes.
>
> -brian
>
Added to
http://microformats.org/wiki/geo-brainstorming#latitude_longitude_shorthand_and_geo_link for now.
I left it out of http://microformats.org/wiki/geo-examples-in-wild and
http://microformats.org/wiki/geo-examples thinking that only the
acknowledged representations should be listed there. Am I right?
-Sarven
Tantek Çelik
> On Wed, 2009-12-30 at 22:30 +0000, Brian Suda wrote:
>> On Wed, Dec 30, 2009 at 10:09 PM, Sarven Capadisli <in...@csarven.ca> wrote:
>> > AFAIK:
>> >
>> > The StatusNet platform as of version 0.9RC1 e.g.,
>> > http://identi.ca/notice/17811123
>> >
>> > Potentially, publicly documented sites at
>> > http://status.net/wiki/ListOfServers on update.
>>
>> --- great, can you add/start a page on the wiki to document these?
>> that way we can find common formats and any emerging syntaxes.
>>
>> -brian
>>
>
> Added to
> http://microformats.org/wiki/geo-brainstorming#latitude_longitude_shorthand_and_geo_link for now.
Sarven thanks very much for documenting that on the wiki - that page
is a good place to capture existing publishing patterns regarding geo
information.
> I left it out of http://microformats.org/wiki/geo-examples-in-wild and
> http://microformats.org/wiki/geo-examples thinking that only the
> acknowledged representations should be listed there. Am I right?
Yes that's right. The "examples-in-wild" pages are for documenting
uses of existing microformats on real world web pages.
One quick bit of feedback on this thread (which I'll also note on the
wiki next to the examples added) - use of the title attribute for
semicolon separated lat-long may not be the user-friendliest thing to
do.
Given microformats experience with various uses of the the title
attribute - a good rule of thumb is to check to make sure that the
content you are putting into the title attribute is both reasonably
human readable and listenable.
Thanks,
Tantek
Sarven Capadisli
> One quick bit of feedback on this thread (which I'll also note on the
> wiki next to the examples added) - use of the title attribute for
> semicolon separated lat-long may not be the user-friendliest thing to
> do.
>
> Given microformats experience with various uses of the the title
> attribute - a good rule of thumb is to check to make sure that the
> content you are putting into the title attribute is both reasonably
> human readable and listenable.
I've noted my observations on your observations
http://microformats.org/wiki/index.php?title=geo-brainstorming&diff=41657&oldid=41586
re: your notes in the Wiki, could you explain how
(<span class="geo">lat:<span class="latitude">45.5140800</span>;
long <span class="longitude">-73.6111000</span></span>)
is more user friendly than
title="45.5140800;-73.6111000" ?
I see two things there:
1. changing the problem i.e., intended visible readable text content
2. "45.5140800" and "-73.6111000" as text values is no more human
readable and listenable than as "45.5140800;-73.6111000" title value.
-Sarven
Tantek Çelik
> I've noted my observations on your observations
> http://microformats.org/wiki/index.php?title=geo-brainstorming&diff=41657&oldid=41586
Thanks Sarven, you raised some good questions - I've followed up on
the wiki as well.
> I see two things there:
>
> 1. changing the problem i.e., intended visible readable text content
In general we should seek to make content more visible when possible.
> 2. "45.5140800" and "-73.6111000" as text values is no more human
> readable and listenable than as "45.5140800;-73.6111000" title value.
But that's not the exact comparison of the renderings, leaving out the
key difference, the labels:
lat:45.5140800; long:-73.6111000
which is then more readable/listenable/understandable than a pair of
semicolon separated numbers. it may not be perfect, but it is an
improvement.
Thanks,
Tantek