RE: [uf-discuss] Microformats in Google Maps
Hi Alex Have you tried my Minimap Firefox Addon?? It goes some way to what you were suggesting, in that it stores addresses/placemarks locally in your firefox profile, along with the url from where that address/location was from so that you can geographically browse. All placemarks are displayed in a sidebar map (optionally a fullscreen 'Map Tab' displays all the info) and from this sidebar you can open up the placemarks corresponding url in a new tab. Although microformats is not in the extension per se, there is an operator script that sends uf addresses or geo to the placemark list (why reinvent the wheel having two extensions parse the same page every time!). For websites not yet uf adr enabled, you just drag and drop the address text onto the sidebar to add. The extension also supports kml links including google MyMaps. http://firefox.spatialviews.com Shameless plug over, Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Faaborg Sent: 01 August 2007 19:31 To: Microformats Discuss; Kevin Marks Subject: Re: [uf-discuss] Microformats in Google Maps This is great, I'm really glad to see Google using microformats. Quick question about handing microformatted content back to Google Maps (using Operator, Firefox 3, etc): does your API support currently sending multiple items, and adding them to a particular map listed in My Maps? For instance, this would enable the user to select multiple hCards on a Web site and send them all to one of their maps. Or, to give a more advanced use case: a Web browser could automatically send all encountered hCards, adrs and geos to a map called Web History. The user could then turn this map on to view all of the pieces of information they recently encountered online geographically. This could be useful when planning a vacation, searching for real estate across multiple Web sites, etc. -Alex On Jul 31, 2007, at 3:37 PM, Kevin Marks wrote: http://googlemapsapi.blogspot.com/2007/06/microformats-in-google- maps.html Microformats in Google Maps Tuesday, July 31, 2007 at 4:28:00 PM Posted by Gregor J. Rothfuss, Maps Team and Kevin Marks, Apps Team If you have spent any time in certain corners of the web, you will have heard of Microformats: Clever uses of HTML that add machine-readability to everyday web pages while preserving human-readability. Microformats allow tools to make more sense of your web pages, while not changing the visual appearance for visitors to your site one whit. Today we're happy to announce that we are adding support for the hCard microformat to Google Maps results. Why should you care about some invisible changes to our HTML? By marking up our results with the hCard microformat, your browser can easily recognize the address and contact information in the page, and help you transfer it to an addressbook or phone more easily. Firefox users can install the Operator or Tails extension; IE or Safari users can use one of these bookmarklets. [...] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss This email was received from the INTERNET and scanned by the Government Secure Intranet Anti-Virus service supplied by CableWireless in partnership with MessageLabs. (CCTM Certificate Number 2006/04/0007.) In case of problems, please call your organisation's IT Helpdesk. Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes. + The Forestry Commission's computer systems may be monitored and communications carried out on them recorded, to secure the effective operation of the system and for other lawful purposes. + The original of this email was scanned for viruses by the Government Secure Intranet (GSi) virus scanning service supplied exclusively by Cable Wireless in partnership with MessageLabs. On leaving the GSi this email was certified virus-free ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] inappropriate behaviour (was: Discussion of public domain declaration template usage)
On 1/8/07 20:02, Andy Mabbett [EMAIL PROTECTED] wrote: Once again, there is the impression that microformats fora are being run by an unelected cabal, using arbitrary, personal interpretations of vague and unwritten rules, applied with no sense of even-handedness. Still, I suppose that's easier than actually addressing the governance and rights issues which I and others have raised. Apparently they travel in black helicopters too http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats in Google Maps
I don't think it's Operator that's at fault. I wrote a post about trying Google Maps (http://www.viewfromw6th.com/2007/08/microformats-getting-bigger.html) as soon as I heard they were using microformats. Looking up our company address I could not pull any meaningful data out using Operator, Tails or the LeftLogic bookmarklet. Though it's great news I'm a little saddened that Google couldn't get it right first time. Dave On 8/1/07, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Gregor J. Rothfuss [EMAIL PROTECTED] writes Unfortunately, now that I've checked, I find that it appears buggy. This search: http://tinyurl.com/38gbbl has 3 hCards, two are invalid and the other (in the pushpin pop-up) has: NAME:Great Barr School - Google Maps N:;; ORG;CHARSET=UTF-8:Address: FN;CHARSET=UTF-8:Address: ADR;CHARSET=UTF-8:;; i will look into it. Thank you. operator parsing behavior has changed in recent releases, and i had to change the markup a couple times to make it work. I'm not sure that Operator has anything to do with it. any suggestions what ought to be fixed? You could start by producing valid (X)HTML, and put your styles in an external style sheet - that at least would make it easier to debug! I don't know Javascript, so can't comment on any errors in that. -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats in Google Maps
Hi all,
converting a freeform address is definitely much easier nowadays with
all the geocode services out there, so nobody should have to develop
their own custom parser any more.
For example Google provides an excellent service so any publisher with
freeform address data should not only be able to generate a geocode from
that text but also retrieve a nicely sliced up structured address too.
e.g.
UNSTRUCTURED INPUT DATA: (To use the previous address example)
922 Aldridge Rd, Birmingham B44
GEOCODE CALL:
http://maps.google.com/maps/geo?q=922+Aldridge+Rd,+Birmingham
+B44output=jsonkey=YOUR_GOOGLE_API_KEY_HERE
STRUCTURED OUTPUT AS JSON (or other format as requested):
{name:922 Aldridge Rd, Birmingham
B44,Status:{code:200,request:geocode},Placemark:[{id:p1,address:922
Aldridge Rd, Birmingham, Birmingham, B44 8,
UK,AddressDetails:{Country:{CountryNameCode:GB,
AdministrativeArea:{AdministrativeAreaName:England,
SubAdministrativeArea:{SubAdministrativeAreaName:Birmingham,
Locality:{LocalityName:Birmingham,Thoroughfare:{ThoroughfareName:922
Aldridge Rd},PostalCode:{PostalCodeNumber:B44 8},Accuracy:
8},Point:{coordinates:[-1.903576,52.544932,0]}}]}
So now you have nicely structured hCard data:
div class=street-address922 Aldridge Rd/div !-- ThoroughfareName
--
span class=localityBirmingham/span, !-- LocalityName --
span class=regionBirmingham/span, !-- SubAdministrativeArea --
span class=postal-codeB44/span !-- PostalCodeNumber --
div class=country-nameEngland/div !-- AdministrativeAreaName --
But I'm sure I'm telling you all how to suck eggs 8)
Rob Manson
BTW Scott...I tried your auto_geo tool and got the following error:
Internal Server Error
The server encountered an internal error or misconfiguration and was
unable to complete your request.
Please contact the server administrator,
[EMAIL PROTECTED] and inform them of the time
the error occurred, and anything you might have done that may have
caused the error.
More information about this error may be available in the server error
log.
Additionally, a 404 Not Found error was encountered while trying to use
an ErrorDocument to handle the request.
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: Microformats in Google Maps
Andy Mabbett wrote: http://microformats.org/wiki/hcard-brainstorming#implied_adr_subproperties which strikes me as unworkable, being overly complex and not suitable for internationalisation (not just in non-English speaking countries, but outside the USA) I'm with Andy on this one. In fact, Tantek's proposed algorithm doesn't even solve the problem of parsing US addresses. Consider: div xml:lang=fr pContactez-nous a:/p div class=vcard div class=org fnAmbassade de France aux Etats-Unis/div div class=adr 4101 Reservior Road, N.W.br / Washington D.C. 20007br / Etats-Unis d'Amerique /div /div /div I recently had to write some code to transfer almost 500,000 addresses from a loosely formatted list to one which had separate fields for house name, address, town, county, country and postcode. Because these were almost entirely UK addresses, and I had a big database of all UK postal town and corresponding postcodes, I was able to get about 95% accuracy -- but that involved hundreds of lines of code. To cover a useful number of countries would require tens of thousands of lines of code. Requiring the use of heuristics to parse address data raises the barrier to entry for implementing hCard astronomically. Andy's suggestion of defaulting to extended-address is better, though given the semantics of extended-address, which appears to be for flat numbers, I'd prefer to default to street-address. How about: Where adr has content not enclosed in any explicit sub- properties, parsers MAY attempt to heuristically determine the address parts and, if appropriate, MAY ask the user to manually separate the address. Failing that, parsers MUST assume this content to be the street-address. -- Toby A Inkster BSc (Hons) ARCS [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.12-12mdksmp, up 42 days, 18:43.] Open Mobile Alliance DTD Oops! http://tobyinkster.co.uk/blog/2007/08/02/xhtml-mobile-oops/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Microformats in Google Maps
On 8/2/07 8:34 AM, Toby A Inkster [EMAIL PROTECTED] wrote: Andy Mabbett wrote: http://microformats.org/wiki/hcard-brainstorming#implied_adr_subproperties which strikes me as unworkable, being overly complex and not suitable for internationalisation (not just in non-English speaking countries, but outside the USA) I'm with Andy on this one. To be clear, I wanted to document it as a brainstorm to be critiqued, with severe doubts myself, from the second paragraph in that section, which I wrote: This may also be too difficult/complex to be dependable or interoperable, but it is worth at least documenting our considerations and analysis either way. In general, the documentation of such strawman thoughts and criticisms of such is just good science. Not every brainstorm should be taken as a proposal that is intended to be adopted. div xml:lang=fr Please add examples that show problems with it to the section with the brainstorm rather than the emails list. And no need to try to be comprehensive about showing problems with it, one or two examples will do for now, given the doubts expressed from the origin. I recently had to write some code to transfer almost 500,000 addresses from a loosely formatted list to one which had separate fields for house name, address, town, county, country and postcode. Because these were almost entirely UK addresses, and I had a big database of all UK postal town and corresponding postcodes, I was able to get about 95% accuracy -- but that involved hundreds of lines of code. To cover a useful number of countries would require tens of thousands of lines of code. This is a useful datapoint. Note that it doesn't prove difficulty (in that someone else may be able to write simpler/more efficient code, or not), but any such implementation experience is useful to capture. Requiring the use of heuristics to parse address data raises the barrier to entry for implementing hCard astronomically. Perhaps not astronomically, but I agree with your sentiment. ;) Andy's suggestion of defaulting to extended-address is better, though given the semantics of extended-address, which appears to be for flat numbers, I'd prefer to default to street-address. I'd prefer neither. I think there would be too much semantic dilution (or artificial semantic precision) by doing so (putting things that don't have a certain semantic into a field that implies that semantic). How about: Where adr has content not enclosed in any explicit sub- properties, parsers MAY attempt to heuristically determine the address parts and, if appropriate, MAY ask the user to manually separate the address. Failing that, parsers MUST assume this content to be the street-address. I'm not even sure about permitting the heuristic part. I think for now the simplest and most interoperable (and what I think implementations already do) is to make this an FAQ (because the spec already doesn't say to do anything with adr without any subproperty): http://microformats.org/wiki/hcard-brainstorming#adr_without_children_FAQ Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Microformats in Google Maps
We do that internally via some scripts so I'd be happy to contribute one if more than a couple of people are interested in it. It could be a nice parallel to the vCard to hCard converter I contributed too. Rob On Thu, 2007-08-02 at 14:46 +0100, Farndon, Tony wrote: Has anyone built a page that would allow anyone to enter a freeform address, it gets sent to googles geocoder, does it's magic on the json output and then creates a fully marked up adr with children (plus a geo span whilst it is at it) for them to copy and paste? If not, could one be produced to compliment the hcard creator? T. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats in Google Maps
ah. i have not implemented microformats for geocodes yet. they are stored and handled differently. if i get some of that 20% time (heh) i will add support for it. On 8/1/07, Rob Manson [EMAIL PROTECTED] wrote: Hi Gregor, I just followed the tinyurl link that Andy Mabbett posted to the list which lead to a Google Maps search: http://tinyurl.com/38gbbl Then did a view selection source on the address in the left hand panel. Hope that helps... Rob Manson ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[admin] Re: [uf-discuss] inappropriate behaviour (was: Discussion of public domain declaration template usage)
On Aug 1, 2007, at 1:02 PM, Andy Mabbett wrote:
In message [EMAIL PROTECTED], Andy Mabbett
[EMAIL PROTECTED] writes
Frankly Andy, due to your use of the {{subst}} method, you have
now added
additional time cost to determining if any page *you* edit in
particular is
consistently in the public domain or not with respect to all
other public
domain contributors.
Frankly, Tantek, that's bullshit.
I have just received an e-mail, from Frances Berriman, subject
Warning
of inappropriate behaviour on mf-discuss, citing the above
exchange of
26 July, in:
http://microformats.org/discuss/mail/microformats-discuss/2007-
July/010261.html
and telling me that:
Such an outburst (sic) requires (sic) a warning that if you
cannot contribute with respect and in an appropriate tone
on the
mailing list, you will receive a cooling off ban.
Perhaps Ms Berriman isn't familiar with British English vernacular
(which would be odd, I understand she lives here), but Rubbish,
nonsense is in the Oxford English Dictionary, and means rubbish,
nonsense. In any case, that was no outburst; but a considered
and apt
description of the comment to which I was responding; and I stand
by it.
The microformats admins have decided to ban Andy Mabbet from this
community (both email lists and wiki) for one week, due to continued
failure to adhere to the be nice guideline [1] after a private
warning.
[1] http://microformats.org/wiki/mailing-lists#Be_nice
Sincerely,
Scott Reynen
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats UI in Firefox 3
did you carry on working on the idea of showing whats a microformat in the page? There was talk of a mouse cursor change when a user hovers over. The last mockup i saw had an icon at the end of the address bar with action. I think both of those would be a good way forward. I started a thread a while ago about the idea of coming up with a more user friendly name/description for microformats. You supported the idea then, has there been any thought on it from the FF guys? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] XOXO Special Properties
I don't know if there's much interest in XOXO anymore, with sexier new h* monikers and all, but I seem to have great appreciation for this simple format. I am currently trying to understand how to best parse and understand the meaning of XOXO-ed content, and need some guidance/ideas on properties, specifically these: http://microformats.org/wiki/xoxo#Special_Properties Here are some thoughts on parsing of properties that I put down: http://microformats.org/wiki/xoxo-brainstorming#Parsing_Properties My intent is to use XOXO for configuration (remember plists discussion from a while back?) and I would like to make sure I don't write code that does something unacceptable or illogical. Since there is not much heard anymore about the glorious XOXO adventures, I am wondering if the world has moved on to something bigger and better? :DG ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] XOXO Special Properties
Hi Dmitri, On Aug 2, 2007, at 1:08 PM, Dimitri Glazkov wrote: My intent is to use XOXO for configuration (remember plists discussion from a while back?) and I would like to make sure I don't write code that does something unacceptable or illogical. Since there is not much heard anymore about the glorious XOXO adventures, I am wondering if the world has moved on to something bigger and better? I think XOXO is considered a solved problem (for some value of solved) which may be why there isn't much chatter. Your solution sounds reasonable to me -- have you compared it to the existing parsers? -enp ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: XOXO Special Properties
Can you point me to the existing tests? On 8/2/07, Kevin Marks [EMAIL PROTECTED] wrote: there are python and java versions here, with some tests http://microformats.org/wiki/xoxo-sample-code refactoring tests into the HTML + JSON style discussed for hCard et al would be a fine idea. On Aug 2, 2007 3:47 PM, Dimitri Glazkov [EMAIL PROTECTED] wrote: That's a good idea. I'll definitely look into existing parsers. I have located xoxo.rb (http://tinyurl.com/3ygt7e), which should be helpful. Christian's site seems to be down at the moment. I see that Hixie raised a similar issue a while back: http://microformats.org/wiki/xoxo-issues :DG On 8/2/07, Ernest Prabhakar [EMAIL PROTECTED] wrote: Hi Dmitri, On Aug 2, 2007, at 1:08 PM, Dimitri Glazkov wrote: My intent is to use XOXO for configuration (remember plists discussion from a while back?) and I would like to make sure I don't write code that does something unacceptable or illogical. Since there is not much heard anymore about the glorious XOXO adventures, I am wondering if the world has moved on to something bigger and better? I think XOXO is considered a solved problem (for some value of solved) which may be why there isn't much chatter. Your solution sounds reasonable to me -- have you compared it to the existing parsers? -enp ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: Getting legal help (was: inappropriate behaviour)
Scott Reynen wrote: The microformats admins have decided to ban Andy Mabbet from this community (both email lists and wiki) for one week, due to continued failure to adhere to the be nice guideline [1] after a private warning. I don't condone Andy's tone when replying to the thread that started all of this. I think it is important to note that he is one of the more frequent contributors to this community and constantly challenges the ideas and concepts that are just accepted around here without explanation. While I don't always agree with Andy, he does have a knack for making logically sound arguments. It is vital to have people that can challenge the status quo, people such as Andy, involved in a community such as this. His replies reflect reservations that several members of this community choose not to express out of fear of retaliation. In this case the topic is: the insistence that we should not raise legal matters on the mailing list. The reasoning for not discussing legal matters on the list is not clear. It is ironic that in an open community, such as this, that we have any taboo topics... but here we are. The only attempt at explaining this why we cannot speak about legal matters is that nobody on here is a legal expert, including the admins. If that is the case, I think there is something that we can do to solve that issue. I propose that we get the Electronic Frontier Foundation involved. If not the EFF, then Creative Commons. Each of those organizations believe in the open exchange of information and have lawyers on the payroll. I volunteer to get the ball rolling if necessary. Thoughts and suggestions? -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Getting legal help (was: inappropriate behaviour)
Hi Manu, On Aug 2, 2007, at 7:10 PM, Manu Sporny wrote: The reasoning for not discussing legal matters on the list is not clear. It is ironic that in an open community, such as this, that we have any taboo topics... but here we are. I an not a lawyer, but my understanding is that any public statements made by the adminstrators regarding legal matters could be used against them in case of legal action. Given the explicit goal of Microformats.org to avoid any sort of formal bureacracy, I suspect that there was a collective decision to simply avoid the issue altogether. If you want something more formal, you may want to look at GRDDL. :-) -- Ernie P. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] inappropriate behaviour (was: Discussion of public domain declaration template usage)
Once again, there is the impression that microformats fora are being run by an unelected cabal, using arbitrary, personal interpretations of vague and unwritten rules, applied with no sense of even-handedness. Still, I suppose that's easier than actually addressing the governance and rights issues which I and others have raised. Apparently they travel in black helicopters too I don't think we should make light of this point. I've heard several people cite this impression as the reason they don't contribute to microformats. If we can't address the problem then I don't see how we can attract and retain active members. More than once I've observed unresolved discussions cut off with a post saying wiki updated, issue closed. So, why would someone take time out of their day to contribute to a discussion if they expect to be ignored? To put it another way, if the core group is going to do as it pleases regardless of community discussion, why are the rest of us here? The core group is not a defined/invited/elected group so it's not like a W3C discussion list, where people understand they are giving feedback but will not be involved in the final decision. The expectation was that everyone could contribute, but that's not how it actually feels. I am not trying to be troublesome, I am expressing a genuine concern about this community. I don't think it serves anyone's purpose to ignore what many people feel is true. The informal approach worked well when the community was new and smaller, but now that it's ramping up it doesn't seem to be coping. I'm not claiming there's an easy answer, but we should start by accepting there's a problem. cheers, Ben -- --- http://weblog.200ok.com.au/ --- The future has arrived; it's just not --- evenly distributed. - William Gibson ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
