RE: [uf-discuss] RDFa vs microformats
Thanks for the article. -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Mabbett Sent: Saturday, November 25, 2006 10:39 AM To: Microformats Discuss Subject: [uf-discuss] RDFa vs microformats In case you missied my adding it to the 'wiki;', here's an article about RDFa vs microformats : http://evan.prodromou.name/RDFa_vs_microformats -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ 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] Best Practice for wrapping hCard information with geo, for display on Google Earth?
Hi Folks, I am when using Brian Suda's xhtml2kml.xsl tool to create a KML file from an hCard. Then I display the KML on Google Earth. What is the best practice for wrapping hCard data with geo, which will result in the most informative rendering on Google Earth? Let me explain what I mean. Consider this hCard: span class=vcard span class=fn orgWaldorf-Astoria/span span class=adr span class=street-address301 Park Ave./spanbr / span class=localityNew York/span, abbr class=region title=New YorkNY/abbr span class=postal-code10022/span /span /span The lat/lon coordinates of the Waldorf-Astoria are: Latitude: 40.756561 / Longitude: -73.974056 Here are some possible ways to wrap the hCard data with geo: 1. Wrap the name (Waldorf-Astoria) span class=vcard abbr class=geo title=40.756561; -73.974056 span class=fn orgWaldorf-Astoria/span /abbr span class=adr span class=street-address301 Park Ave./spanbr / span class=localityNew York/span, abbr class=region title=New YorkNY/abbr span class=postal-code10022/span /span /span Running Brian's tool will yield KML that when displayed on Google Earth shows the label Waldorf-Astoria at that lat/lon. But that's all the information that will be displayed. 2. Wrap the street address (301 Park Ave.) span class=vcard span class=fn orgWaldorf-Astoria/span span class=adr abbr class=geo title=40.756561; -73.974056 span class=street-address301 Park Ave./spanbr / /abbr span class=localityNew York/span, abbr class=region title=New YorkNY/abbr span class=postal-code10022/span /span /span Running Brian's tool will yield KML that when displayed on Google Earth shows the label 301 Park Ave. at that lat/lon. Again, that's all the information that will be displayed. Is it better the Google Earth label show the name of a place or its address? 3. Wrap the entire collection of information span class=vcard abbr class=geo title=40.756561; -73.974056 span class=fn orgWaldorf-Astoria/span span class=adr span class=street-address301 Park Ave./spanbr / span class=localityNew York/span, abbr class=region title=New YorkNY/abbr span class=postal-code10022/span /span /abbr /span Running Brian's tool will yield KML that when displayed on Google Earth shows the label containing all the information (name, street address, city, etc). Not pretty. So, what is the best way to wrap (with geo) hCard data that will produce KML, which when displayed on Google Earth, creates an informative display? /Roger ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] simple rss question
Hi all I am adding hcard to a page and wondered if there was a pattern for defining the rss feed for an individual. It seems like there would already be something simple, i.e. class=rss or rel=rss. I didnt see anything. Do you have a suggestion? Thanks Ted Drake Yahoo! Tech - Tech Made Easy Member of the Yahoo! Accessibility Stakeholders Group Is your site voice recognition friendly? If you use an image for a button, the alt text needs to match the text in the image. If the user says hit send nothing will happen if the alt text says subscribe to our wonderful newsletter by hitting this send button. The same goes with using CSS image replacement techniques. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Best Practice for wrapping hCard information with geo, for display on Google Earth?
In message [EMAIL PROTECTED], Costello, Roger L. [EMAIL PROTECTED] writes I am when using Brian Suda's xhtml2kml.xsl tool to create a KML file from an hCard. Then I display the KML on Google Earth. What is the best practice for wrapping hCard data with geo, which will result in the most informative rendering on Google Earth? Let me explain what I mean. As a general point of principle,; I suggest you use the best, most meaningful, markup, and not try to tailor it to the idiosyncrasies of a particular tool. If a tool is not giving the optimum output, write to its author and ask them to consider changing the way it works. Consider this hCard: span class=vcard span class=fn orgWaldorf-Astoria/span span class=adr span class=street-address301 Park Ave./spanbr / span class=localityNew York/span, abbr class=region title=New YorkNY/abbr span class=postal-code10022/span /span /span The lat/lon coordinates of the Waldorf-Astoria are: Latitude: 40.756561 / Longitude: -73.974056 I feel the only thing there which might equate to an abbreviation, for which the coordinates are the full form, is the postal (Zip) code. -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard search engine at Alexa
On Nov 20, 2006, at 10:08 AM, Ben Ward wrote: One thing I would request though is that the results listing also be marked up with hCard, since that would enable use of existing Microformats browser tools to transfer hCards from the results into desktop address books and so forth. If you do this, please consider using class=uid to link to the original, so that it's clear that the original is elsewhere. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Is class=vcard fn illegal?
On Nov 25, 2006, at 11:19 AM, Ryan Cannon wrote: Is it perhaps useful to talk about implied vcards? The rule could be similar to: If a an element with class=vcard does not have any hCard class names, imply the entire content as an fn field, and attempt to apply the implied n optimization. Optionally, if the root element has @href, imply a class=url. ... I don't have any initial opposition to this, but I think some research could help. Could you collect examples from the wild where this optimization would help? -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Implied hCard (was: Is class=vcard fn illegal?)
On Nov 27, 2006, at 6:55 AM, Ryan Cannon wrote: It would seem that the rule still applies: [EMAIL PROTECTED] would be both the FN and Nickname fields. Perhaps parsing could key on the protocol: mailto would imply an EMAIL;TYPE=Internet and http(s) would imply a URL. Any other protocols would not imply anything. Should I add this to the wiki? Why do you say that the @href would be the FN? AFAIK, the the spec doesn't state this and no implementation does this. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Implied hCard (was: Is class=vcard fn illegal?)
On Nov 30, 2006, at 1:24 PM, Ryan King wrote: On Nov 27, 2006, at 6:55 AM, Ryan Cannon wrote: It would seem that the rule still applies: [EMAIL PROTECTED] would be both the FN and Nickname fields. Perhaps parsing could key on the protocol: mailto would imply an EMAIL;TYPE=Internet and http(s) would imply a URL. Any other protocols would not imply anything. Should I add this to the wiki? Why do you say that the @href would be the FN? AFAIK, the the spec doesn't state this and no implementation does this. It's hard to tell what people are responding to when they top-post replies, but I believe what Ryan Cannon wrote above was in response to this: what about: a href=mailto:[EMAIL PROTECTED] class=vcard [EMAIL PROTECTED] \a Here [EMAIL PROTECTED] is both the @href and the node value (assuming \a was intended to be /a). Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] [citation] Page range conclusion?
Hi, I can't tell from the ending of the most recent trail of emails about the citation uf whether a consensus was reached about encoding page values and ranges, or if everyone just got tired after 51 emails. There was some evidence of research that I think ought to be put on the citation-brainstorming page in the form of examples from the web using each kind of page / page range encoding. It's easier to find it for reference that way... I'd like to keep this moving if possible, and remind people of the danger of trying to get it perfect the first time around - note that existing citation formats like bibtex and RIS are emphatically not perfect and are still very useful. More than anything, we need a working imperfect format so that tools can begin to grow, and we can iteratively improve the format as neccessary. Thanks, -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] [citation] url field
Based on the existence of a URL in the examples listed at the end of this email, I propose modifying the working straw format at http://microformats.org/wiki/citation-brainstorming#Brian.27s_Straw_format to include a URL field, denoting the URL to a copy of the work available online (often a PDF, but could be anything linkable). I suggest that it could, but would not necessarily, be combined with a field representing a unique identifier for the cited item, as for instance in the case of a DOI URL. I also suggest that in the case of identifiers like a DOI or ISBN which can be represented as a parameter in a link to doi.org or some other resolver, that the format encourage using a URL field for those identifiers and not include separate fields for each such identifier. In other words, I think that class=url uid is sufficient to encode DOI/ISBN/etc., and we shouldn't add a separate DOI class, a separate ISBN class, and so on. For an example of how I think it might look, see http://microformats.org/wiki/citation-brainstorming#Citing_a_conference_publication Any comments or suggestions? Thanks, -mike Examples from the web with URL data: http://microformats.org/wiki/citation-examples#CiteSeer_database_search_results http://microformats.org/wiki/citation-examples#W3C_XHTML_Spec_Example http://microformats.org/wiki/citation-examples#Google_Cache http://microformats.org/wiki/citation-examples#Book http://microformats.org/wiki/citation-examples#Journal_Articles http://microformats.org/wiki/citation-examples#Historical_Sources http://microformats.org/wiki/citation-examples#EPrints.org http://microformats.org/wiki/citation-examples#Citation_of_an_Online_Resource This omits the cases where other identifiers like DOI and ISBN are used, but that only adds to the relevant examples, if you buy my argument about using URL for those. -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [citation] url field
On 11/30/06, Michael McCracken [EMAIL PROTECTED] wrote: I also suggest that in the case of identifiers like a DOI or ISBN which can be represented as a parameter in a link to doi.org or some other resolver, that the format encourage using a URL field for those identifiers and not include separate fields for each such identifier. In other words, I think that class=url uid is sufficient to encode DOI/ISBN/etc., and we shouldn't add a separate DOI class, a separate ISBN class, and so on. What about non-http URIs? Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Re: [uf-discuss] [citation] url field
On 11/30/06, Bruce D'Arcus [EMAIL PROTECTED] wrote: On 11/30/06, Michael McCracken [EMAIL PROTECTED] wrote: I also suggest that in the case of identifiers like a DOI or ISBN which can be represented as a parameter in a link to doi.org or some other resolver, that the format encourage using a URL field for those identifiers and not include separate fields for each such identifier. In other words, I think that class=url uid is sufficient to encode DOI/ISBN/etc., and we shouldn't add a separate DOI class, a separate ISBN class, and so on. What about non-http URIs? I'm not sure what you're asking exactly. I intended the URL field to represent the extremely common use of a link on a web page that points to a copy of the linked work. So it should (maybe even must?) provide the location of a resource, which a non-http URI doesn't do, without extra context. If you mean why not call it URI?, then mainly because I wasn't aware of any examples of URIs on the web that weren't also http URLs. I didn't see any references to URIs such as URN:* in the examples-markup page, except as parameters to an OpenURL http: URI. So, I thought I'd call it URL with the understanding that people would use it 80+% of the time as an http URL that links to a copy of the cited work. Calling it URL takes no explanation for publishers, unlike URI. On the other hand, if you mean then how should we mark up non-http URIs?, I would say you can do it however you want, perhaps by using an ID class (I've used class=uid in the example I linked to), just *don't* use class=url because that means a link to a copy of the cited resource. Also, since this just occurred to me, I see no reason why there can't be multiple URL fields for one citation - this could cover multiple versions, such as in the example of a cached copy of a cited web page along with the original link: a href=cached... class=url Cached version as of abbr class=dtaccessed ...Sept. 06/abbr/a a href=original... class=urloriginal link/a Thanks, -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
