Re: [uf-discuss] Microformat for dictionary/thesaurus ... + research
Certainly worth gathering examples. For my boys' wordlists, I wrote a
scraper that went to merriam-webster, looked up a list of words, and
created a XOXO approximation from their markup:
table cellpadding=0 cellspacing=0 width=400 border=0
tr
td align=left
One entry found for bimpostor/b.form name=entry method=post
action=/cgi-bin/dictionarytable border=0 cellpadding=0
cellspacing=0 valign=toptrtd
input type=hidden name=hdwd value=impostorinput type=hidden
name=listword value=imposterinput type=hidden name=book
value=Dictionary/td/tr/table
/form
Main Entry: bim·pos·tor/b a
href=javascript:popWin('/cgi-bin/audio.pl?
impost02.wav=impostor')img src=/images/audio.gif border=0
height=11 width=16/abr
Variant(s): ior/i bim·pos·ter/b a
href=javascript:popWin('/cgi-bin/audio.pl?
impost02.wav=imposter')img src=/images/audio.gif border=0
height=11 width=16/a /ttim-'pauml;s-tamp;r/tt/br
Function: inoun/ibr
Etymology: Late Latin iimpostor, /ifrom Latin iimponere/ibr
b:/b one that assumes false identity or title for the purpose of
deception
/td
tdimg src=/images/pixt.gif alt= width=10 height=1
border=0/td
/tr
/table
to something cleaner, eg
http://homepage.mac.com/kevinmarks/flock.html
Needs more work (the 3rd layer senses should be a sub-list too, and the
markup could be way more semantic, and converting their home-made
phonetics to IPA would be nice).
On Nov 30, 2005, at 12:27 PM, Ryan King wrote:
On Nov 30, 2005, at 12:20 PM, Chris Messina wrote:Anyway, checking out
that page resulted in a format that seemed ripe
for some dl|dt|dd microformat love:
entry type=subject sortkey=sortkeyhere status=Active
title=noad:1.01 entry=0 stage=1
meta ... /meta
hwGrp ... hwGrp
senseBlock
meta ... /meta
prelim ... /prelim
sense
meta ... /meta
...
/sense
/senseBlock
/entry
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] URI schemes vs. visible data (was Re: communications log, tel microformat?)
On Nov 29, 2005, at 6:15 PM, Tantek Çelik wrote: Authors aren't publishing links to geo and address information. They're publishing *visible text* of geo and address information. So the easiest thing to do, for the author, is to leave it as visible text. I can imagine, that for geo or addr information, maybe they'll want to wrap it in a hyperlink that goes to a maps page or something, so that clicking it actually does something. If you forced them to use a hypothetical geo: protocol instead, then that would interfere, since you can only hyperlink something to one destination. People are publishing links to map data; perhaps a consistent way of labelling these ? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Never underestimate the usefulness of human-readable data. (was Re: [uf-discuss] Non-HTTP/HTML microformats)
On Nov 30, 2005, at 11:14 PM, Tantek Çelik wrote: On 11/30/05 4:55 PM, Ryan King [EMAIL PROTECTED] wrote: Never underestimate the usefulness of human-readable data. Ryan, this is an excellent point, and I feel like something that needs to be added to that other blog-post-in-progress based on the last discussion of The tools will save us (NOT!) that we had on the list. There is SO MUCH evidence (like the examples you just gave) for the usefulness of making data formats be human-readable that it really makes you wonder why so many otherwise intelligent people keep wanting to do otherwise. Well, there is a second distinction here. XML folks would argue that their data is human readable too, and describing the Box Model Hack as human-readable only works for a sufficiently narrow definition of human. However the key point with using HTML for the microformats, is that everyone has a viewer for the data, so they don't need to parse it by eye, as it were. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel-tag for hierarchical categories
On Dec 2, 2005, at 9:38 PM, Benjamin Carlyle wrote: I'm wanting to use tags as part of my blog entry posts, but I don't like explicit tagging. I just want a single link at the bottom of each blog entry to point to its category, and for that to be interpreted as one or more tags. Now, rel-tag appears to do the right thing for: a href=http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ softwaresoftware/a yes, that is the spec Now I want it to make sense of a hierarchical category system: a href=http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ software/httpsubscriptionsoftware/httpsubscription/a I think the current proposal would tag this as software/httpsubscription, when in fact it really means two tags: software+httpsubscription. No, it would tag it as 'httpsubscription' Tagspaces are defined to be flat. What will current parsing do (especially technorati) with my input? Is my data point something that could be applied more generally? Should the specification cover this case? No, tagspaces are meant to be flat. If you want hierarchy you need something else. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] The need for a Trackback microformat?
OK, this brings us to the heart of Podcasting. For much discussion, see the last two videos with rel=enclosure on my blog... On Dec 3, 2005, at 1:51 PM, Charles Iliya Krempeaux wrote: On 12/3/05, Chris Messina [EMAIL PROTECTED] wrote: On 12/2/05, Ryan King [EMAIL PROTECTED] wrote: I don't think your relEnclosure and http://microformats.org/wiki/rel- enclosure are that different, they're just explained differently. Also, I think they're close enough to be resolved. You want to work on that? Yes, the meaning is the same. If we can revise the wording to make this clearer, good. Perhaps rel-enclosure doesn't actually make sense long term. Given that relEnclosure, AFAIK, was grafted onto RSS to allow for media being attached to feeds, rel-enclosure doesn't make sense in your regular browser-consumed webpages because we've got embed and object. If RSS had been able to support inline rich media, wouldn't those tags have sufficed? No. In RSS, enclosures instruct the client to pre-download the media, (but says nothing about playing it). Both embed and object say play the media (and say nothing about pre-downloading it AFAIK). To me, there are 2 orthogonal concepts here. One is pre-downloading it. And the other is playing it. It was my (perhaps naive) understanding that rel-enclosure was an attempt to add pre-downloading to HTML. It is for pre-downloading, and also to imply synchronisation to a non-browser client. The goal is to enable transparent playback of media you subscribe to, with no waiting. In other words, the 'playing new stuff to me on my bike ride to work' scenario. It also seems that relEnclosure was about behavior on the client side and less about semantics. Let's presume for a minute that we've got infinite bandwidth If that was the case, then, you would NOT need RSS enclosures. and infinite storage. In such a world, all embedded media (and hrefs) would be able to be pulled in and cached automagically. In which case the need for delayed media downloading would be much less, so even if you're syncing your 8,000 feeds, which all contain rich media like podcasts and vcasts, you would theoretically be able to pull all that data down anyway for later consumption. So the question is, what is the most effective way to link to that media? Indeed, will the media itself supplant the textual content of the feed? The textual content becomes annotation fro the media, in a podcast, which has beneficial effects: it is indexable by search engines and other tools that can read HTML (instead of having to spelunk thorugh giant binary media files looking for metadata) Will feeds simply become the distribution method for rich media or eventually get into a TV-for-the-web model where you pick people to subscribe to and can tune in to an aggregate stream of them whenever you like? I dunno, and I suppose I'm getting a little off topic here. They already are - see DTV So here's what I'm thinking when it comes down to it (now that you know what I'm looking at in the future)... Shouldn't relEnclosures just be converted to object or embed tags when they're pulled into xhtml? I'd say no. No, that's missing the point. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom draft - class=title
On Dec 27, 2005, at 3:43 PM, Tantek Çelik wrote: This means working deliberately to avoid the two cardinal sins that namespaces typical both enable and encourage: 1. The same term is used to mean two different things 2. Two terms are used to mean the same things Indeed. In fact this is one of the advantages of Atom over RSS - resolving ambiguous usage. In RSS 'description' is used for both summary and full-content feeds. Atom defines distinct 'summary' and 'content' elements for this In RSS 'link' is used for both 'entry permalink' and 'external linked element from a brief entry'. The current established microformats have avoided this problem by essentially reusing from earlier microformats when possible, *before* reusing from other standards. E.g. hReview has reused a lot from hCard and hCalendar. See http://microformats.org/wiki/existing-classes for an overview. In the case of 'title', Paul is right. hCard (by way of vCard) has defined 'title' to mean something in particular. In the case of hReview, we used 'summary' from hCalendar to serve this purpose. Would it be possible to do so for hAtom as well? I would say that letting hCard use a bare 'title' to mean 'honorific form of address' was possibly a mistake in retrospect, but it is established. That said, 'title' is context-defined in Atom - it can mean 'feed title' or 'entry title'. Replacing this with 'summary' would be a mistake, as that needlessly blurs the summary/content distinction which is important for authors, readers and parsers alike. I think keeping 'summary' and 'content' are good. hReview's and hCalendar's 'summary' is IMO not really a title in the atom/rss sense, but a one-line abbreviated form. So I would suggest 'entry-title'. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] rel-bookmark [was entry permalink in hatom
On Jan 4, 2006, at 2:02 PM, Tantek Çelik wrote: On 1/4/06 1:52 PM, David Janes -- BlogMatrix [EMAIL PROTECTED] wrote: Tantek Çelik wrote: An explanation is different from a specification. I would welcome a tutorial on rel-bookmark on microformats.org -- let's just be very clear that it is NOT a new microformat, nor would it be a specification. Perhaps we could call it: http://microformats.org/wiki/rel-bookmark-tutorial Other suggestions for indicating that something is a explicitly an informative tutorial rather than a specification (I'm not saying we have to always append -tutorial, but naming conventions tend to be useful, especially when one could easily confuse a /wiki/rel-bookmark page as being a specification since the URL looks like other /wiki/rel-* pages). As long as the page is not structured like a spec, this should be clear - we perhaps need a Template:DesignPattern to use liek the spec templates. A precedent is perhaps http://microformats.org/wiki/abbr-design-pattern and http://microformats.org/wiki/datetime-design-pattern for documenting something that is standard HTML, but used in a 'clever' way. (also, as http://www.microformats.org/wiki/rel-bookmark is #3 on Google for a search for 'rel bookmark', putting something there is better than nothing). Conceptually, is there a microformat rel-bookmark or not (irregardless of who is providing the spec)? No there is no rel-bookmark microformat. rel=bookmark is a normative part of the HTML 4.01 specification. Using rel=bookmark is just using semantic (X)HTML. Nothing new about it. where people are going to look. This of course code just say this is defined by HTML 4.01 and here's how we use it [[rel-bookmark-tutorial]] Are you suggesting we put in a stub page on the wiki for everything we re-use from HTML 4.01? Not for clear well-known element, but when we come up with a good reuse like this of a more obscure part of a spec, this is a good way to encourage people to read the core specs themselves, and not just blithely make up new elements. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hReview feedback
On Jan 23, 2006, at 5:38 PM, Ryan King wrote: I don't know how the Structured Blogging wordpress plugin does this (or whether it allow it at all), but in hReview you can do tagged ratings. So, in your example: a href=http://wikipedia.org/wiki/CyberPunk_Visuals; Degree of CyberPunk Visuals: span class=rating15/span/span class=best30/span /a you missed off the rel=tag there that indicates this is a tagged rating: a href=http://wikipedia.org/wiki/CyberPunk_Visuals; rel=tag Degree of CyberPunk Visuals: span class=rating15/span/span class=best30/span /a (fortunately Philip put it in in his example) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microsummaries in Firefox
On Mar 21, 2006, at 3:37 PM, Ryan King wrote: On Mar 21, 2006, at 12:55 PM, Chris Messina wrote: The definition: A microsummary is a short compilation of the most important information on a web page, f.e. the ticker symbol and price for a stock quote page. TWX: 17.07 A microsummary definition is a simple XML snippet telling Firefox how to generate a microsummary for a set of pages. The walk-thru: http://www.melez.com/mozilla/microsummaries/walkthrough.html The proposal: http://wiki.mozilla.org/Microsummaries I feel like this is a perfect place for microformats -- and not XML. Anyone have thoughts on this concept? I think h* are good enough. Or how about hAtom, specifically http://microformats.org/wiki/hatom#Entry_Summary (historical note - this is what RSS was originally for - a list of links to remote sites with a little extra context - see Slashdot's slashboxes for example) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Plants Microformat
On Mar 24, 2006, at 11:45 AM, Scott Reynen wrote: On Mar 24, 2006, at 12:08 PM, Andy Mabbett wrote: What do you mean by plants? Garden plants? Plants as studied by botanists? Plant-material, such as cut flowers, or planks of timber? Is there really any ambiguity here? The former two are the same thing, no? Does a plant become something different depending on whether it is in a garden or being studied by a botanist? Well, to be fair there is distinction between species that are studied by botanists, and varieties sold by garden supplies people (which are often effectively clones), but I think that is something that can be worked out in the process. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Plants Microformat
On Mar 24, 2006, at 2:04 PM, Ryan King wrote: Let's take a step back and think about whether a microformat for plants is worthwhile– Microformats are solutions to common problems, which means they often end up being low hanging fruit. That doesn't mean, however, that all low-hanging-fruit is a common problem and a worthwhile effort the community to undertake. As someone who cares about microformats and has fruit trees, I would like to point out that the low-hanging fruit ripens last, so if you're picking that, you likely need to get some help and pick the whole tree, and make some jam. (Not sure if that helps with either discussion, but it is Friday afternoon) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] MicroID - Identity in a shade of microformat
On Mar 27, 2006, at 3:40 PM, jer wrote: Boy, once Doc gets a hold of something... I was going to send out a little note here asking for some feedback, but it's gone full circle already :) Anyway, MicroID isn't exactly a microformat all by itself but it can be expressed in conjunction with one. It's really just an opaque but verifiable owner token, allowing anyone to point at something and say that's mine which can be verified by using their email address (or any supported communication identifier). I'm not sure how useful an email address is as a shared secret. If you use a publicly-known one, anyone who knows it can spoof your signature; if you use a unique address per service then you need multiple microid's. The itch I'm scratching is two part, I'm tired of having to put some button or javascript code (or upload a funky named empty file) on my blog/site to verify that I have editorial control over it. This practice is becoming more and more common, and the technology to do this once and for all isn't brain surgery. Your long hash reminds me of the original Technorati claiming model, which was a hash of the user ID and blog URL, which I deprecated as the ID's were too long and cumbersome to send around easily - urls with them in tended to get wrapped in email, so people ended up making their blog invalid by adding a url with a newline in the middle, and my parser had to cope with that. Hence we went to a 10-character randomly-assigned ID model, as the ID is not guessable. As Chris said on his blog, the bidirectionally-verified rel=me is a sounder way to do this - see http://gmpg.org/xfn/and/ The second part is to have a MicroID published with a score microformat (well really just class='score' unless someone has a better idea) that is wrapped around any comment or content published on a moderated system. If I get modded up and have a good reputation on that system, why can't there be a solid technical way for me to verify my reputation (or just a bag of all my scores) to anyone that cares? If these moderated systems publish a simple MicroID with the score output, it makes my reputation portable as much as I want it to be. As your model is spoofable if I know your email, I'm not sure what this gains for you over showing the ID or email directly in the moderated system. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Google at it again
On Apr 12, 2006, at 11:27 PM, Sam Sethi wrote: So who's the new Google ;-) depends who you ask: http://www.google.com/searchq=%22is+the+new+google%22 says yahoo http://search.msn.com/results.aspx?q=%22is+the+new+google%22 says 37 signals or maybe wikipedia ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Chat microformat/podcast transcript
On Apr 14, 2006, at 12:42 AM, Chris Messina wrote: I disagree, but then I've always been a fan of DLs. The problem that I see with only using q cite and bq is that they're ways of loosely pairing a speaker and what they've said. I don't know of any way to closely couple the two. At least with DT and DD there's a clear correlation for the speaker with her/his words: speaker 1: something that speaker 1 said speaker 2: something that speaker 2 said Thats why you use a list: ol liciteChris Messina/cite qA chat is a list of definitions./q/li liciteKevin Marks/cite qNo, a chat is a list of quotations./q/li /ol Which has a very nice default rendering. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Language Maps [was RE: [uf-discuss] Microformats vs XML]
On May 1, 2006, at 5:59 PM, Tantek Çelik wrote: The problem with AppleScript is that it is actually not that readable/writable (even in English *by* native English readers). AppleScript has a superficial resemblance/reuse of English terms which makes it look a lot easier than it actually is (AppleScript is *very* picky about specific language constructs). I find Applescript to be a read-only language, much as regex is a write-only one. This is in stark contrast with the language which inspired it, HyperTalk, which is quite easy to both read and write, and as with natural langauges, provides multiple ways of saying the same thing and having it just work. I don't know if HyperTalk was ever localized. I don't think so, though one of my early projects wiht it circa '89 involved extensive use of others routines in french and italian with corresponding variable names. microformats-discuss (as Ryan so well demonstrated this being a problem far outside the realm of microformats) and thus I suggest that we drop this thread Language Maps and add it to the list of bad topics on the mailing-lists page. One minor thought before we go - I can envisage a javascript that used the abbr date-pattern to replace dates with user-local ones in the content, while retaining the machine-friendly ones in the abbr. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] microformats search and pinging
On May 31, 2006, at 10:14 PM, Scott Reynen wrote: On May 31, 2006, at 9:29 PM, Tantek Çelik wrote: There are some indexers of specific microformats right now (e.g. Reevoo and Kritx both index hReviews), but no general microformats search engine. Hmm... I'm pretty sure I was indexing contacts, events, and reviews several months ago here: Great stuff Scott, do you want to get pings relayed? Do you have a REST interface for us to send you URLs that ping Pingerati? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] microformats search and pinging
On Jun 1, 2006, at 8:22 AM, Scott Reynen wrote: On Jun 1, 2006, at 1:00 AM, Kevin Marks wrote: On May 31, 2006, at 10:14 PM, Scott Reynen wrote: On May 31, 2006, at 9:29 PM, Tantek Çelik wrote: There are some indexers of specific microformats right now (e.g. Reevoo and Kritx both index hReviews), but no general microformats search engine. Hmm... I'm pretty sure I was indexing contacts, events, and reviews several months ago here: Great stuff Scott, do you want to get pings relayed? Do you have a REST interface for us to send you URLs that ping Pingerati? Six months ago, when I made my little tool, I wrote [1]: I'm not looking to start a new public search engine — just demonstrate that someone with more time and experience than I and maybe an existing web crawler (*cough cough*) could do something like this. Scott, I'm trying to relay pings to you byt they don't seem to eb working: 2006-06-01 16:47:10.68: pinging 'http://www.randomchaos.com/microformats/base/spider/?url=http%3A// flickr.com/people/docsearls/' Failed to load URL: http://flickr.com/people/docsearls/ 2006-06-01 16:47:24.90: pinging 'http://www.randomchaos.com/microformats/base/spider/?url=http%3A// www.pacificit.ca/article/133' Failed to load URL: http://www.pacificit.ca/article/133 should I turn this off again? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] pingerati notes
On Jun 4, 2006, at 2:21 AM, Mark Mansour wrote: I have to say great job on the pingerati digester and multiplexer! Just a couple of administrative items - I cant get reach events.pingerati.com/ping/ or review.* as noted on the about page (I stopped trying after these two failed) Oops, that should be events.pingerati.net/ping/ etc. I corrected the page. We intend to get pingerati.com routed too but it isn't set up yet. Sorry for the confusion. Also not it should be reviews.pingerati.net/ping/ (ie plural 'reviews' not singular 'review'). - the ping format on the about page indicates that the scheme should not be used in the ping URI, but the homepage and the bookmarklet seem to indicate that the scheme should be included and that it should be http:// (my preference is for the scheme should be included). We will cope with either, so sending it with http is fine (do make sure you escape the URL, especially if it has any ? or # in). ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] LinkedIn and Microformats
On Jun 13, 2006, at 3:36 PM, Chris Messina wrote: It would be interesting if the Pingerati infrastructure offered a validation service -- or revealed mal-formed microformats. A validator is orthogonal to pingerati, but if someone puts one togtether I'll happily feed it pings. Similarly exposing this data coming into Pingerati would potentially give mF advocates something to do on the weekend. Heh. (Or at least tell the authors of the pinged page that there's something the matter). There is a difference between a liberal parser and a validator, is the point. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] media file example of hAtom
rel-enclosure is deliberately limited, so that it can be used as part of a wider format. The issue of alternative representations seems like a common one for media. At the HTML level rel=alternate is used for this. http://www.w3.org/TR/html4/struct/links.html#h-12.3 If you are listing alternatives, use a list So for your examples, a possible model would be ol class=alternatives lia href=story.doc rel=enclosure alternate type=application/mswordthe story in Word format/a/li lia href=story.pdf rel=enclosure alternate type=application/pdfthe story in pdf format/a/li lia href=story.txt rel=enclosure alternate type=text/plainthe story in text format/a/li /ol just an initial thought - lets do a proper problem statement and follow the process: http://microformats.org/wiki/process On Jun 13, 2006, at 7:31 PM, Joshua Kinberg wrote: I think the concern may be that relEnclosure is rather limited... For instance, how do I use relEnclosure to markup a group of files that may different versions of the same content? For example, a document in Word, PDF, and TXT... or a video in Mov, WMV, etc. Is there any way to specify an enclosure group? Should there be? Could it be as simple as defining a class=enclosuregroup block (or something like that) and then any relEnclosures within that block are then known to belong to the same group? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] media file example of hAtom
Great, David - I'll add mine. On Jun 14, 2006, at 2:36 AM, David Janes -- BlogMatrix wrote: Strangely enough!: http://microformats.org/wiki/alternates-brainstorming http://microformats.org/wiki/alternates-examples Regards, etc... David Kevin Marks wrote: rel-enclosure is deliberately limited, so that it can be used as part of a wider format. The issue of alternative representations seems like a common one for media. At the HTML level rel=alternate is used for this. http://www.w3.org/TR/html4/struct/links.html#h-12.3 If you are listing alternatives, use a list So for your examples, a possible model would be ol class=alternatives lia href=story.doc rel=enclosure alternate type=application/mswordthe story in Word format/a/li lia href=story.pdf rel=enclosure alternate type=application/pdfthe story in pdf format/a/li lia href=story.txt rel=enclosure alternate type=text/plainthe story in text format/a/li /ol just an initial thought - lets do a proper problem statement and follow the process: http://microformats.org/wiki/process On Jun 13, 2006, at 7:31 PM, Joshua Kinberg wrote: I think the concern may be that relEnclosure is rather limited... For instance, how do I use relEnclosure to markup a group of files that may different versions of the same content? For example, a document in Word, PDF, and TXT... or a video in Mov, WMV, etc. Is there any way to specify an enclosure group? Should there be? Could it be as simple as defining a class=enclosuregroup block (or something like that) and then any relEnclosures within that block are then known to belong to the same group? ___ 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
Re: [uf-discuss] Very basic question that is not in the FAQ
On Jun 22, 2006, at 8:35 AM, Scott Reynen wrote: On Jun 22, 2006, at 9:46 AM, Tantek Çelik wrote: Hamper compared to what? When I'm telling someone about microformats and they express concern that Technorati might try to control microformats as Microsoft or Google has been feared trying to control the web, or Apple trying to control podcasting, or UserLand trying to control RSS, I believe the answer influences people's interest in microformats. The point of microformats is to give up control. Technorati genuinely believes that distributed open formats are more valuable than centralised closed ones, and that is a big reason why Tantek and I work here. I appreciate that this can be a difficult idea to get across, but the difficulty is with the idea of this kind of what Benkler calls 'Comunity-based peer production' rather than with Technorati's involvement. I try to point to the CC license. I avoid a curt that's just FUD (even if it is) because I find that insulting. I find clarifying ownership works well in one-on-one discussion and I think it would work well on the website too. If you disagree, fine. I don't think it's going to make a big difference in the long run, and I didn't mean to suggest it would. But I continue to believe clarifying ownership in advance would be an improvement. The problem may be that 'clarifying ownership' involves a digression into Open Source theory rather than a simple disclaimer. If you have a good way of explaining this do please share it. As Eric said, the real test is the empirical one of adoption, and the goal of the microformats process and community is to converge practice and specification to amplify this. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Must Ignore vs. Microformats
On Jul 19, 2006, at 10:55 AM, Tantek Çelik wrote: On 7/19/06 10:34 AM, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote: One good thing about XML, IMO, is that for certain simple markups based on XML, it's easier for a beginner-level or intermediate-level developer to write a parser for it (as compared to writing a parser for Micrformats... since HTML is more difficult to parse). (For example, writing a parser in C, C++, PHP, Java, C# or whatever.) [...] This is why the supposed easier to parse aspect of XML is incredibly misleading. It ignores both the need to be easier to publish, and the fact that XML, in fact, is *harder* to publish. Also, the Babel aspect of XML means that you always do need to write a parser, if not of the XML itself but to transform the plucked-from-the-air schema and arbitrary choices of what is an attribute and what an element to the data structure you are using. A key part of Microformats is converging the schemas so this becomes much less necessary. One example of such a simple format based on XML is RSS. You're kidding right? It is certainly *not* pretty easy for someone to write a parser for RSS that actually works with real RSS on the Web. Have a look at the Universal Feed Parsers 3000 test cases... http://feedparser.org ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Exploratory discussion: content rating
On Jul 27, 2006, at 10:05 AM, Scott Reynen wrote: I didn't mean to suggest you weren't following the process. I was just trying to point out the humorous situation I was imagining, in which someone walks by, sees you looking at a porn site, and then you turn around and try in vain to explain Seriously, I'm doing research for a microformat. Sounds like a problem we have at work when checking spam blogs. When I was at Apple, Maynard, who worked on MPEG playback, had to have an office with no windows due to the kind of content he got bug reports of bad MPEG streams in... ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] AJAX Pages and Microformats.
On Aug 8, 2006, at 4:40 AM, Pedro Custódio wrote: Hi everyone! I'm kind of new into the microformats world, so this doubt can have actually been answered before, if so please excuse me! ;) How do you take advantage of microformats on pages built using ajax technology, I mean pages, which content is loaded via ajax/json methods? The base page continues to have the initial data or source code, while the content displayed varies. What's your suggestion for combining the 2 technologies? AHAH is a way to combine microformat fragments with async display: http://microformats.org/wiki/rest/ahah ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Apple open sources their iCal Server
This looks interesting - I was chatting to some of Apple's server team last night at the webkit meetup. Begin forwarded message: From: Peter Herndon [EMAIL PROTECTED] Date: August 9, 2006 12:35:11 PM PDT To: twisted-web@twistedmatrix.com Subject: [Twisted-web] Apple using Twisted in OS 10.5 Leopard Server Reply-To: Twisted Web World twisted-web@twistedmatrix.com Hi all, Apple has open sourced their iCal Server, and it is written in Python using Twisted and web2. http://trac.macosforge.org/projects/collaboration/browser/ has the overall stuff in it, and the server itself is at http://trac.macosforge.org/projects/collaboration/browser/ CalendarServer/trunk/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom implementation questions
I'd say both points are arguable. From my point of view, tags should be inside the post content, as otherwise they may be dropped from the feed. Likewise, Stephanie's other-language summaries are currently not in her Atom feed, which makes it less useful, as I find the English summaries handy when deciding whether to work at reading the French; I imagine French readers would feel the same about the summaries on the English posts. On Sep 9, 2006, at 4:02 PM, Stephen Paul Weber wrote: The bilingual summary should be outside of entry-content for sure... but rel=tag data can be either in the entry-content or outside... both are legal in the spec -- Singpolyma On 9/9/06, Stephanie Booth (bunny) [EMAIL PROTECTED] wrote: interface to deal with them. Therefore, rel-tag is the recommended microformat for categories. so i'm correct in thinking they need to go outside the entry-content container, right? Both tags and categories? and if I treat my other language excerpt as some type of summary, that needs to go outside the entry-content container too? Steph ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Proposal: Lunar/ Mars co-ordinates (like geo)
On Sep 18, 2006, at 1:23 PM, Andy Mabbett wrote: - do we really need a /different/ microformat for every body being described? is there a way to add a third value for type (or body, or something more appropriate) to geo without breaking exiting spec / rules or muddying things up too much? I did consider that, but I'm not sure how one could attach the extra attribute, I also considered geo-luna and geo-mars; but the meaning of geo is (planet) Earth, so it's not really appropriate. How about adding a container around the geo that specifies the planet (or geoid, if you want to get extra fussy. You can say it defaults to WSGS-84, which is backwards compatible). That way you can specify the planet once for a series of co-ordinates. What you do for highly non-spherical bodies can be deferred, as after all the IAU now insists that planets are spherical... ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Proposal: Lunar/ Mars co-ordinates (like geo)
On Sep 18, 2006, at 3:57 PM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Kevin Marks [EMAIL PROTECTED] writes How about adding a container around the geo that specifies the planet (or geoid, if you want to get extra fussy. You can say it defaults to WSGS-84, which is backwards compatible). Do you mean http://www.wgs84.com/ which, helpfully, has as its total content: http://en.wikipedia.org/wiki/WGS84 is a decent article on the terrestrial geoid. These exist for other planets too (and the moon) but they are much more tentative. Note multiple statements of Apollo landing co-ords here: http://www.hq.nasa.gov/alsj/alsjcoords.html Currently, the lunar geoid is being redefined with Clementine data, so the location (latitude, longitude, and elevation) of everything will change again very soon I believe the reference geoids for other planets are also under revision ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] i-names and hcard
No, you can take that as meaning 'http redirects are easy to set up and XRI is an over-complex mess' Please read section 5 of it in full before replying here: http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.html#iddiv1142306584 Having the xri http server be a host for your hCard 302 redirect is vaguely OK, but XRIs are a bad way to do it. There are plenty of existing redirection services. I use xrl.us myslef, but have a look at the list here: http://notlong.com/links/ On Sep 19, 2006, at 1:29 PM, Sebastian Küpers wrote: I take this link as an I agree with you - XRI's are a good way to do it :)) On 9/19/06, Kevin Marks [EMAIL PROTECTED] wrote: On Sep 19, 2006, at 1:07 PM, Sebastian Küpers wrote: http://xri.net/=sebastian/+hcard (just try this url in your browser) at the moment it redirects you to my claimID account. but I can now change it to my blog for example and this url still remains the same. http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.html ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] A bug in the Technorati's events exporting tool
On Sep 26, 2006, at 5:44 AM, Brian Suda wrote: I won't go too much technical detail on the discuss list, you can email me off list for a complete explaination and how the W3C defines the order of where to look for language encodings, etc. Our own Mark Pilgrim wrote a good explanation of this: http://www.feedparser.org/docs/character-encoding.html ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] geo - accuracy of coordinates
Andy, you're missing the point. A bare lat-long pair is not always helpful. If that's all you have, you can't really display a useful map. The existing mapping tools tend to use product-specific ways of specifying the degree of zoom needed, to distinguish between the right side of my desk, the Technorati offices, South of Market, San Francisco, The Bay Area, California, and America. A radius of interest is a way to express this in a platform-neutral way that doesn't require address-parsing. It is readily derivable from any specific mapping platform. If you want to express a geographic feature such as those I mentioned above, clearly a human-readable label such as 'San Francisco' is a better than a polygon. You probably realise that the polygons necessary are in fact fractals, with the resolution necessary determined by the zoom level too. We don't want to replicate Arc-Info here, we want to replicate useful user-info. On Oct 2, 2006, at 2:58 PM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Colin Barrett [EMAIL PROTECTED] writes Or the capacity to describe a polygon... I call the 80/20 rule into effect here. Fine, I'm confident that more than 80% of countries, counties, towns, cities, gardens, parks, nature reserves, and industrial estates are polygons, and fewer than 20% are circles. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] geo - accuracy of coordinates
On Oct 2, 2006, at 4:11 PM, Michael MD wrote: Not really, if it's a large city... Consider Birmingham, England, whose centre is far from being equidistant to all points on its boundary - it's in Ladywood on this map: http://www.birmingham.gov.uk/wards GeoRSS uses a radius element, which could be a uf class and would specify in meters, kilometers, or miles (itself a discussion for units). Or perhaps better would be a featuretypetag (again using GeoRSS as a working case example) that can specify city Or the capacity to describe a polygon... In many cases the available data is just not accurate enough to be able to accurately describe a radius or polygon. (if it were, it might be accurate enough for a street address too!) Again, consider this URL: http://flickr.com/map/?tag=yankeestadiumfLat=40.828081fLon= -73.920821zl=7 if it were expressed as a radius of 10km, I think it would do for Brum as a whole. Even with only city-level accuracy, lat/long data can still be very useful, but clearly I'd want to avoid having it end up being used to generate a local street map that gives someone incorrect directions to get to a street address! The radius idea could possibly be used but the radius itself would be inaccurate. That's fine - it's really an order-of-magnitude expression of detail. I think the featuretype idea is probably better for this if there can be a standard for the actual feature type names. (but in GeoRSS it appears to be folksonomy-based so if data comes from multiple sources, an application might need to look up some kind of dictionary of commonly used terms just to work out that it's a city) Or, as in this example, it could be derived from the tag + geo expressed by several people. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] geo - accuracy of coordinates
On Oct 2, 2006, at 4:24 PM, Kevin Marks wrote: On Oct 2, 2006, at 3:16 PM, Chris Casciano wrote: You could outline any territory as a series of geos if the need ever arose. But I'm still not clear how we've gotten here. If I want to say something is in Ireland, or Mexico City or somewhere in the Alps I'd tag it as such. I thought the original issue of accuracy was one of precision (either via tool measurement or in human recollection). Not one of being able to define a geo that accurately represents the floorplan of Yankee Stadium or the whole of Antarctica but of accurately reflecting if a designation was accurate enough to make a determination if a specific seat in yankee stadium, somewhere in the bleechers, or just near the stadium as i was walking around before the game or i need to mark the bronx somehow so left me zoom out and drop a marker from the 50k foot view http://flickr.com/map/?tag=yankeestadiumfLat=40.828081fLon= -73.920821zl=7 Notice that the yankeestadium tag shows various usages here - the ambiguity between where the photo was taken from and what it was taken of. You could probably derive a useful 'centrepoint + radius' for Yankee stadium from the mean and std-dev of those geolocated, tagged points. Notice that the URL I used above has 6 digits of latitude and longitude (a supposed precision of ~ 10cm), but a zoom-level parameter to express the actual display I wanted to convey. However, what you see is dependent on the size of your browser window, as the zoom-level is defined based on pixel-size, not window width. Hm, also, flickr maps didn't update it right. What I meant was http://flickr.com/map/?tag=yankeestadiumfLat=40.826738fLon= -73.928246zl=1map_type=hyb which rather illustrates the underlying need. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: History Microformat (was Re: [uf-discuss] Dated currency examples?)
On Sep 25, 2006, at 10:03 AM, Jeremy Boggs wrote: i would be very interested in helping to explore a history microformat. In my spare time, I've been collecting examples of history timelines, after discussions a few months ago on this list about the inability of using hCalendar to mark up before common era dates, and other considerations for marking up historical dates and spans of time.[1] I've collected examples of uses of BCE dates and timelines in general, but I could easily expand the scope of my inquiry. Starting to collect these at history-examples on the wiki, and making notes at history-brainstorming would be a useful start. Like Tantek says, a history microformat might help address the issue of past currency values, as well as help markup a host of other historical information: both secondary sources (biographies, timelines, articles, genealogy) and primary sources (census records, newspapers, letters, diaries, probate records, etc...). I may be biased about this (I'm a history PhD student. And, I understand that we would need to collect real-world examples first before moving on. I'd be happy to share what I've collected so far, and help out any way I can, if the community thinks it is worthwhile. Price exchanges are a complex subject, and we should be wary of either over-simplifying the real world, or bringing too much of its own complexity with us. Some prices fluctuate minute by minute (think stock markets), some on a slower basis. For most currencies, people are willing to consider prices in that currency as usably stable, though obviously the date it was offered is a useful secondary piece of information. Comparing prices between countries and even more so between eras is far more problematic, because of technological change affecting relative prices. I don't think we want to get into GDP deflators and Purchasing Power Parity if we can avoid having to. See this recent post for some of the complexities: http://www.janegalt.net/archives/009469.html One thing that has come up several time here is a discussion of date/price series - comparing prices over time. That seems like a useful thing to consider in the light of composable date and price + currency formats. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Geographic polygons [was geo - accuracy of coordinates
On Oct 3, 2006, at 1:12 AM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Chris Casciano [EMAIL PROTECTED] writes Totally ignored the point I was trying to make... and that is that describing a border - of any shape - by the use of a collection of geo coords (at whatever precision) is a totally different task then defining an individual point and its precision. Totally ignored the point I was trying to make... and that is that it would perhaps be better to have the capacity to describe a polygon. They aren't mutually exclusive, which is why I suggested separating polygons into a separate thread. There is an HTML way to express 2D polygons in image maps, so what we would need is a way to georeference the imagemaps to translate these back to earth-based co-ordinates. For imagery in lat-long space, or for close-in zooms, just specifying the lat/long of the corners would be adequate; for other projections such as Peterson, Roberts or Mercator, you may need to specify the transform with more care, if trapezoidal interpolation give significant distortion. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] geo - accuracy of coordinates
You'll need a Flash-compatible browser - their geotagging is Flash-based at the moment. (we'd better get HTML-defining and evangelising to convert our Flickr friends) On Oct 3, 2006, at 3:10 PM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Kevin Marks [EMAIL PROTECTED] writes consider this URL: http://flickr.com/map/?tag=yankeestadiumfLat=40.828081fLon= - 73.920821zl=7 That's showing a blank page, with just a Flickr header, for me. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Size considerations
On Oct 18, 2006, at 6:09 PM, Andy Mabbett wrote: That's 399 characters increased to 860 (excluding indentation); over double. when gzipped (with indentation) I get 308 bytes vs 498 ration 1.62 Stripping out the indentation and CRs and using more compact forms of the mf markup I get tr class=X th scope=rowFriday 3br7:30–9:30pm/th tdabbr class=wmbc title=West Midland Bird ClubWMBC/abbra href=../solihull/indoor.htm title=Solihull Branch indoor meetings Solihull Branch indoor meeting/a./td tdSolihull College, New Lecture Rooms, Blossomfield Road, Solihull B91 1SB (SP142790)./td tdSteve Smith: The Farne Islands and the Bass Rock./td /tr vs tr id=D20061103a class=vevent X th scope=rowFriday 3brabbr class=dtstart title=20061103T193000Z7:30/abbr–abbr class=dtend title=20061103T213000Z9:30/abbrpm/th td class=summaryabbr class=wmbc title=West Midland Bird ClubWMBC/abbra class=url href=../solihull/indoor.htmSolihull Branch indoor meeting/a./td td class=location vCardspan class=fn orgSolihull College/span,span class=adrspan class=extended-addressNew Lecture Rooms/span,span class=street-addressBlossomfield Road/span,span class=localitySolihull/spanspan class=postal-codeB91 1SB/span/span(abbr class=geo title=52.4095; -1.7921SP142790/abbr)./td td class=descriptionSteve Smith: The Farne Islands and the Bass Rock./td /tr gzipped I get 293 vs 451 ratio 1.51 Though as in each case (even uncompressed) the size is under a typical 1500-byte packet size, the difference is immaterial - and embedded in a realistic page the difference becomes much less marked. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Size considerations
On Oct 19, 2006, at 11:58 AM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Kevin Marks [EMAIL PROTECTED] writes using more compact forms of the mf markup I get Other than the 20061103T213000Z format for dates, what did you change? I removed a redundant 'title'. gzipped I get 293 vs 451 ratio 1.51 So - still an increase of over 50%. That's not insignificant. In itself, it's not significant, as it is well under a packet size, as I said, and so will not affect download time. A useful exercise would be to compare the whole page before and after adding microformats, not just the fragment that changed. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Size considerations
On Oct 19, 2006, at 12:43 PM, Andy Mabbett wrote: In itself, it's not significant, as it is well under a packet size, as I said, and so will not affect download time. Why is packet size relevant? The page concerned has many - and some have dozens - of table rows in similar format. Good! Do you have before and after versions? Doing a real-world measurement would be a useful contribution. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats vs. CalDAV?
On Oct 19, 2006, at 8:18 PM, Mike Schinkel wrote: The good news is Apple in on our board, which means CalDAV would be the standard we'd employ. CalDEV: http://ietf.osafoundation.org/caldav/ Now, it's my understanding that one of the benefits of Microformats is that it co-exists nicely with other standards, and often even augments them quite well. But I'm still new enough at this I didn't want to stumble in trying to explain and advocate Microformats to someone who thinks CalDAV is the only thing they need to support. I spoke to the CalDAV chaps at Apple about this, they have hCalendar support as a ticket in their db: http://trac.macosforge.org/projects/calendarserver/ticket/19 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Size considerations (or how to choose)
On Oct 19, 2006, at 9:57 PM, Christopher Rines wrote: In my opinion amount is a really difficult one to abbreviate (or any measure for that matter) as it can be used to describe a lot of other things for which there is not yet a microformat but cur (for currency) is interesting as just off the top of my head I don't think currency is used in a lot of other situations but could we abbreviate current (if we did something electrical) with cur? I guess this reinforces my point that while useful abbreviations in human-readable things are tricky at best. Just like acronyms can be an insiders language, abbreviations can obfuscate meaning. On the broader point, assuming you use gzip when you care about size, abbreviations don't save much, especially in the many-repeated case discussed. Also, using whole english words means that the gzip is likely to be more able to exploit the natural redundancy of the English language (assuming your text outside the markup is English). If someone has whole-page examples I'll be happy to compare before and after gzipped ones. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] RE: Disconnect between hCard and RFC 2426 (vCard specification)?
On Oct 23, 2006, at 5:30 AM, Stephen Paul Weber wrote: 1:1 means that the field names are identical in each, not that the use-case will always be the same. (Incidentally, I have seen vCards made for businesses before...) Quite - microformats are based on observing usage, not on theory. There are lots of vCards fro businesses rather than individuals in the wild, as it is a common need, so codifying how to do it within hCard is worth it. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Visible data and key+value pairs
I had a discussion about this in Shelley Powers' blog comments a while back: http://just.shelleypowers.com/technology/ajax-myth-busting/#comment638 what I said then was: What is data and what is metadata depends on the content and the context. If you have a series of key/value pairs where both the keys and values make sense in text to humans (say, a credits list for a film) dl is fine - this is part of the XOXO spec. If you have a case where the values are human readable, but the keys are for machines, use the class on container technique - see hCard for examples of this. If you have a case where neither key or value makes sense to the humans, only the script, use JSON (ie express them in script) That leaves the case where the keys make sense and the values don't - the abbr design pattern could work there. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Happy halloween
http://www.flickr.com/photos/kevinmarks/285384771/ http://www.flickr.com/photos/kevinmarks/285384695/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Fwd: Timeline and microformats
seen http://simile.mit.edu/timeline/ ? I contacted the author - what's the best existing 'hCalendar to JSON' tool? Begin forwarded message: From: David Huynh [EMAIL PROTECTED] Date: November 3, 2006 6:54:57 AM PST To: Kevin Marks [EMAIL PROTECTED] Subject: Re: Timeline and microformats Thanks, Kevin. As far as I understand, hCalendar is for embedding calendar attributes within HTML. Is there an efficient way to gather these attributes distributed all over the DOM? If you can do that, then it's not hard to construct event objects and feed them to Timeline. David Kevin Marks wrote: Your Timeline is a string piece of work, and it seems a perfect fit for the hCalendar microformat: http://microformats.org/wiki/hcalendar This is very close to your existing xml structure, but is already widely adopted across the web, for example by Yahoo Local, upcoming.org and evdb.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Bug in rel-lint bookmarklet
Andy, what do you mean by 'submitted the page to Technorati' ? By the look of it, you pinged us as if it were a blog url. We indexed it on 2006-11-25 01:43:05 PST, and didn't find any blog posts in it. As it is a non-blog page, you should submit it via Pingerati http://pingerati.net and it will be indexed for microformats, and go into the microformat search index. Ben, sorry to hear that. Sometimes pings get lost or dropped on their way to us, and we only pick up the post when your blog next updates. What is your blog URL? On Nov 29, 2006, at 3:20 PM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Ben Buchanan [EMAIL PROTECTED] writes I submitted that page top Technorati, 6 or 7 hours ago, ad it's still not found there, either - does Technorati have the same bug, or does it tale longer to index pages? Anecdotally I've found Technorati to be just shy of completely random in terms of how long it takes to index new posts (if at all). I have had some posts appear within minutes, others take days, others simply never make it. Well, the page concerned is still not listed. what a pity none of the people from Technorati who post here has the time to give a simple yes/ no answer to my question about what seems to be a bug in their system. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] simple rss question
If the page is for a person, then the RSS is an alternative. Use the Feed autodiscovery syntax makes sense: http://feedautodiscovery.org/doku.php but you could apply it to an a href link instead of a link one, eg a href rel=alternate me type=application/rss+xml title=RSS feed of Ted Drake href=http://example.com/feed.rss; Ted Drake's feed/a On Dec 1, 2006, at 3:14 AM, Brian Suda wrote: hm... not exactly sure what you mean? there is hAtom to mark-up HTML as a feed. But i think you are asking for a way to say: That RSS over there is about this person! (right?) if so, then i would look at the XFN rel=me property. That is used for identity consolidation, which (i think) is what you are asking about... if not just reply and we can see what we can do. -brian On 11/30/06, Ted Drake [EMAIL PROTECTED] wrote: 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 didn't see anything. Do you have a suggestion? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: [video_vertigo] Re: [videoblogging] Media RSS what?
On Dec 4, 2006, at 9:16 PM, Mike Meiser wrote: On 12/4/06, Mike Hudack [EMAIL PROTECTED] wrote: Mrss-thumbnail would work for me. Do we want to tie this so explicitly to MediaRSS though? Maybe just media-thumbnail? Makes sense to me. I was thinking about the whole schema tying to media RSS doesn't seem strong span class=mrss img src=http://acmevlog.com/thumbnail.gif; id=thumbnail class, not id (id's need to be unique per page) a href=urltovideo class=type-flashflash version/a /span There is an existing HTML way to express the type of a linked file, using MIME types a href=urltovideo.swf type=application/x-shockwave-flashflash version/a see http://microformats.org/wiki/alternates- brainstorming#Strawman_6_.28lists_.2B_explicit_alternator_.2B_using_exis ting_HTML_idiom.29 The point is we need to make it as flat and simple as possible. img src=http://acmevlog.com/thumbnail.gif; id=media-thumbnail a href=urltovideo.swf class=media-filetype-flashflash version/a a href=urltovideo.mov class=media-filetype-quicktimeflash version/a Simple enough? It's not clear that the files are alternatives - see the discussion at http://microformats.org/wiki/alternates-brainstorming ol class=alternates img src=http://acmevlog.com/thumbnail.gif; class=thumbnail lia href=urltovideo.swf rel=enclosure alternate type=application/x-shockwave-flashFlash version/a/li lia href=urltovideo.mov rel=enclosure alternate type=video/quicktimeQuickTime version/a/li /ol Media is the namespace. Shouldn't be any conflicts there. Namespaces are an antipattern. Lets find a term that is expressive and converge it. http://microformats.org/wiki/namespaces-considered-harmful Should be fairly extenisble. And as Andreas pointed out you can specify alternative class info. I.E. a href=url class=media-filetype-quicktime cool-links media-enclosurecool styles link/a Where cool-links might be a CSS style, and media-enclosure and media-filetype might be attributes of our media spec. All we're talking about right now is media-thumbnail but just keeping an eye out looking forward. I think 'thumbnail' alone is OK (can you think of it being confused with markup for false nails or something?) Looking at http://microformats.org/wiki/existing-classes there isn't an existing classname that fits (you could argue for class=photo summary perhaps, but I think that is less accurate). Simple enough? Or still to convoluted? I know services like blip can and will pick up on this stuff real quick once we publish a spec, but it's got to be simple enough for everday vloggers too. The end goal is better marked up code in video and audio blog posts everywhere dealing with media. Would also be great for images, pdf and other media too in the future. See http://microformats.org/wiki/media-info for previous discussions. It seems like a revival of interest here could help us move on to converging schemas and proposing names. I think the problem this points to is that the magic happens in the blog post, not in the RSS. By embedding the metadata in the RSS with mediaRSS we've cut most vloggers and services like blip who interact by cross posting to blogs off from properly identifying the elements of their blog post. Feedburner's been picking videos out and enclosing them using the rel=enclosure standard. And technoratti and others have been picking out tags using the rel=tag standard, but it's time to develop a more robust schema to put the more power back into the blog posting input box. And finally, I like that this schema can be flat, like tags themselves. Allowing multiple atributes to be attributed in the class space. I think people may well get it. Let's just define ourselves a simple schema or language then, shall we? This is maybe something could be something that could really catch on among bloggers and podcasters in the coming years to give them more control. It also leaves plenty of room for additional complimentary schema as well wheras standards like rel=tag and rel=nofollow cannot be used in conjunction with one another. Yes they can, multiple rel's are legal HTML; rel=tag nofollow is a little nonsensical (the link is a tag for the page, but don't index it?) but see above for more coherent examples. Peace, -Mike mefeedia.com mmeiser.com/blog - Original Message - From: videoblogging@yahoogroups.com videoblogging@yahoogroups.com To: [EMAIL PROTECTED] [EMAIL PROTECTED] Cc: Kevin Marks [EMAIL PROTECTED]; Eric Lunt [EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED]; videoblogging@yahoogroups.com videoblogging@yahoogroups.com Sent: Mon Dec 04 20:06:33 2006 Subject: Re: [video_vertigo] Re: [videoblogging] Media RSS what? Yeah, I like as andreas points out using the class attibute to declare a thumbnail. Because class is an atribute unlike name that is standard across all manner of elements (images, links ans such) and it is very extensible
Re: [uf-discuss] rel=muse implies romantic relationship?
On Dec 10, 2006, at 6:08 PM, Chris Messina wrote: And despite my attempts to explain, as you all have, the origins of the romantic sense of the term, Tara never gave me the benefit of the doubt, hence the semantic change. ;) So yes, Tantek, a FAQ entry would certainly be appreciated. Have a look at the Albert Brooks movie 'The Muse' http://www.imdb.com/title/tt0164108/ it explains the concept (and the misunderstandings) rather amusingly, if you'll excuse the pun. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel=tag
On Jan 3, 2007, at 3:10 PM, Nick Peters wrote: Seeing the tag implementation on Operator has made me question the existing tagging standard. With wordpress you may get something like ?cat=13 for a tag or something that may not even be the intended tag at all. Yes, Wordpress abuses the rel=tag spec by doing that, so I have had to code round it at Technorati. They can't do proper url path tags on all installs, but the code doesn't omit rel=tag on the non-tag links. http://microformats.org/wiki/rel-tag#Tag_Spaces says Tags may only be placed in the URL path, and only in the last segment of the path. Tags may not be placed in query parameters or fragment identifiers. e.g. http://technorati.com/tag/tech?tag=fish#emu is still a URL for the tag tech, not fish or emu. Actually, stripping parameters is recommended (that's why it says 'last path segment'). a previous implementation bug of mine at Technorati wasn't doing that properly. After doing some research on the wiki I see that the rel=tag microformat is based off of existing defacto standards (implemented by sites such as del.icio.us and flickr). I still don't see why the standard extracts the tag from the last part of the URL instead of the information inside the anchor tag. When I see a tag and click on it, I expect the visible content, not what's appended to the end of a URL. Anyone care to shed some light on this for me? The 'last path component of URL' part was based on existing practice by both del.icio.us and Flickr when we did the analysis. This was done to encourage use of these kinds of tagspaces, rather than just allowing linking to an arbitrary URL and using the link text. Setting up a tagspace does take a modest amount of webserver configuration, granted. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Scope of tags (Was: [uf-discuss] rel=nsfw)
On Jan 3, 2007, at 2:08 PM, Andy Mabbett wrote: On: http://microformats.org/wiki/rel-tag#Abstract By adding rel=tag to a hyperlink, a page indicates that the destination of that hyperlink is an author-designated tag (or keyword/subject) for the current page. Note that a tag may just refer to a major portion of the current page certainly aggregators would mark that the page is about the term deceased but it wouldn´t make an assumption about individual hCards? and depending on the mark-up if Sue is NOT nested inside Fred´s hCard, then there is a distinction between where/what/who the rel-tag is relating. There is? Where, on the rel-tag spec, is that made clear? It's deliberately not defined there. Other microformats that incorporate rel-tag for more specific purposes define the scope (eg xfolk, hReview, rel-directory) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel=tag
On Jan 5, 2007, at 12:44 PM, Andy Mabbett wrote: Except rel-tag explicitly uses the last part of the URL path, and should ignore query parameters and fragment identifiers[1] i.e. http://example.com/tags?tag=/fish = tags So the workaround at: http://microformats.org/wiki/advocacy#Google_as_rel-tag_namespace will not work? Not with a conforming implementation, though it will with a crued one that does the equivalent of tag=split(url,'/')[-1] if you'll excuse my Python ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats, WebApps 1.0 and UI widgets in browsers
On Jan 31, 2007, at 11:25 PM, Karl Dubost wrote: At first, I say “cool, very cool!”. Then, taking a step back, I think what about the documents which have been created for the last 15 years before microformats effort existed. These documents contain class names which are probably and most certainly very similar to some values defined by microformats community. Karl, can you document instances of use of 'vcard', 'vevent', 'hfeed,' 'hresume', 'hreview' etc before microformats defined them? Very similar isn't an issue; exactly identical is. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [advocacy] Contacting Blogger (was Re: [uf-discuss] Rel-tag issues...)
On Feb 8, 2007, at 3:54 AM, Ben Buchanan wrote: The better approach is to lobby the software/server folks to fix their implementation, Right. On this point, does anyone have a contact at Blogger? Support emails do not get individual replies so we need someone to contact a real live human. I have contacts there, yes. I mean, sure, I can keep banging away at their support form but their email auto-responder just isn't convinced by my polite inquiries. This is a big community, surely someone knows someone at Blogger/Google...? The issue is this: a rel='tag' href=http://example.com/labels/testing.html;testing/a ...being the new Blogger's version of tagging. The existence of rel='tag' suggests a desire to implement rel-tag. The .html suggests that all Blogger posts will be indexed as tagterm.html Can you show me an example of them getting it wrong? I just republished my son's blog to check: http://funnystories.blogspot.com/2007/02/stop-motion-with-people.html and it correctly used: a rel='tag' href=http://funnystories.blogspot.com/search/label/ helmethelmet/a ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Rel-tag issues, i can't create my own tagspace!
On Feb 8, 2007, at 7:10 AM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Brian Suda [EMAIL PROTECTED] writes --- i agree with all of this, and that is why microformats do not force you to use your own tagspace. There are plenty of sites that can easily be used as tagspaces[1] There's also an implicit assumption that publishers (who don't have their own tag spaces) are (or should be) willing to litter their pages with links to third party websites. I've yet to see any justification for that assumption. The several million existing users of rel-tag are sufficient justification for me. If your second party website (the blog hosting service) is not sufficient eg wordpress, blogger or livejournal), and you can't find a third party tagspace who represents your tag's definition, I am a little stumped. What is the actual objection here? You could put rel=tag nofollow on them if it is SEO linkjuice related. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [advocacy] Contacting Blogger (was Re: [uf-discuss] Rel-tag issues...)
On Feb 11, 2007, at 7:25 PM, Ben Buchanan wrote: Right. On this point, does anyone have a contact at Blogger? Support emails do not get individual replies so we need someone to contact a real live human. I have contacts there, yes. [snip] Can you show me an example of them getting it wrong? Some contact was made on the 9th, so perhaps things really have moved that quickly! There's been no mention on http://knownissues.blogspot.com/ as yet. For reference, a test post published earlier shows the error: http://itn278.200ok.com.au/2007/01/test-post.html It contains a rel='tag' href=http://itn278.200ok.com.au/labels/testing.html;testing/a which is what the new Blogger was producing on Jan 31st (page template is one of the standard Blogger templates, I think one or two modifications but nothing which would effect the output of tags). Try making a fresh post, or republishing that one. This may be a blogger issue with publishing via ftp? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] OpenID
On Feb 20, 2007, at 1:24 PM, Thom Shannon wrote: I was thinking there should be a way to have your OpenID on other profiles that can easily be consumed, allowing someone to see you on social network A and add you on their social network B based on you using the same OpenID. that's where UID works I'm guessing it would be as simple as a class=url fn openid href=http://ts0.com;? Just wanted to know what others are doing. There's nothing stopping you from adding an openid class too if you like. Also, adding rel=me to the links that are other facets of your online identity is worth doing too. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] OpenID
I disagree, it being a URL is a good thing. I have http:/ kevinmarks.com as an openid URL with microformats attached to it (based on Chris Messina's here): http://factoryjoe.com/hcard.html Should I be asserting his urls as a uid? On Feb 21, 2007, at 2:19 AM, Thom Shannon wrote: I was picturing something more along the lines of a list of your friends on your social network, each one with an openID, you'd then want to copy and paste that to search for the same friend on the other social network. No one needs to know it's actually a url, not least the user. Both social networks have already verified their members via openID and are just using that string in their member db. anders conbere wrote: On 2/20/07, Thom Shannon [EMAIL PROTECTED] wrote: I think it should also be possible to use openIDs in other elements than just anchors. You don't necessarily want to link to them, it's the url itself which is important not the location. It should also support none canonical urls so they can be written in the way users expect, we don't want openID users thinking they have to remember to type http://; I think this is actually backwards. You DO want to link to them, (whether or not you're attempting to drive traffic there or not). That's what makes them unique! When I was speaking with Scott Kveton last week at ignite seattle, something we spent a bit of time with was the concept of an openID as a url, and the significance that plays. Without being an actual anchor to a specific location, and openID is meaningless. It derives it's meaning and value from the use of the global DNS system, regardless if you're actually looking to direct traffic to your openID or not, it's the nature of it being an anchor that gives it power. What value would an openID have outside of an anchor? ~ Anders Mike Kaply wrote: The problem here is that there is concept of types in URLS All parsers see is multiple URLS. We don't know which is the openid URL... Mike Kaply On 2/20/07, John Panzer [EMAIL PROTECTED] wrote: Thom Shannon wrote: Hi, Forgive me if this is going over old ground, I just joined this list and couldn't find what I was looking for on the wiki. Are there any particular conventions emerging for embedding an OpenID into a hCard? The openid-brainstorming page mentions using hCard on providers profile pages etc, but I was thinking there should be a way to have your OpenID on other profiles that can easily be consumed, allowing someone to see you on social network A and add you on their social network B based on you using the same OpenID. I'm guessing it would be as simple as a class=url fn openid href=http://ts0.com;? Just wanted to know what others are doing. I actually have the same question. At the moment we're doing this: span class=vcarda class=fn urlhref=http://journals.aol.com/panzerjohn; target=_blankpanzerjohn/a/span where http://journals.aol.com/panzerjohn is an OpenID URL (or will be shortly). A live example is at http://beta.journals.aol.com/panzerjohn/abstractioneer. I had been thinking it might be useful to be explicit about the fact that the target is not just a url, but also an openid. If people think that's a good idea I can add it in to our code. -John ___ 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 ___ 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] XOXO to JSON and back
A preliminary go at a bidirectional XOXO to JSON service: http://kevinmarks.com/cgi-bin/xoxotojson.py?url=http://kevinmarks.com and back again: http://kevinmarks.com/cgi-bin/jsontoxoxo.py?url=http%3A// kevinmarks.com/cgi-bin/xoxotojson.py%3Furl%3Dhttp%3A//kevinmarks.com change the url parameters as it suits you, let me know what you think ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel-tag title as tag value (Was: Should microformat features (like rel-tag) have explicit scope?)
On Feb 24, 2007, at 9:41 AM, Mike Kaply wrote: Was there a reason in the original creation of rel-tag that no one thought to allow title to specify the tagname? Yes, the idea was to make it more resilient against gaming by requiring the URL to embody the tag. This followed existing practice on successful tagging sites, and generalised it to a decentralised model. What should a front-end developer do in situations where the back-end developer can't/won't make changes to support the syntax that the rel-tag spec requires? Use an external tagspace. Having your own tagspace is not necessarily a good idea; you want the tag link to be helpful to readers. In many cases, linking to flickr, wikipedia, technorati or delicious is mroe useful than linking to an internal page that just links back to the post in question if it is a singly-used tag. Also, the backend dev may be more amenable when you pepper your posts with external links... ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformat tools bogosity test
On Mar 5, 2007, at 3:31 AM, Danny Ayers wrote: Thought this might be useful: http://dannyayers.com/misc/microformats/soupdragon http://epeus.blogspot.com/2007/03/hot-news-people-lie.html Or, as we say round here, 'not 80%' ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformat tools bogosity test
On Mar 7, 2007, at 1:51 AM, Danny Ayers wrote: There I disagree - as far as the theory goes, for microformats the problem is effectively solved. The notion of profile URIs has gone through the community process, and there's even a microformat to support them: XMDP. It's been accepted that each microformat should have a profile URI [1]. Agreed. The remaining problem is that it's not possible to both follow good practice in regard to web architecture *and* respect the convention side of microformats. If I want to use a profile URI for hReview my only option right now is to make up one of my own. This is legitimate in terms of web architecture, but may lead to mutliple equivalent profiles making the tool developer's job that much harder. If you make up an XMDP profile, I'm sure we can put it on microformats.org so there is a blessed one. Just to reiterate the rationale for profile URIs : if publishers include one, they have made a clear assertion according to the conventions of web architecture and the relevant specs that they're using that microformat. Consumer tools which maximally respect the intent of the publisher will check for profile URIs and proceed accordingly. Ideally a clear distinction will be made between data that has been extracted following the chain of authority and that which is the result of scraping/assumptions by the scraping tool. This certainly doesn't rule out the case of simple scraping display, for many purposes that's perfectly adequate. But it's ludicrous that the webarch-friendly option isn't currently available. So, help make it so. We could declare an official URL and put your soupdragon there, which would satisfy the opaque URL you want, but if you made up an XMDP, that would be far better. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Numbers of Microformats in the Wild?
On Apr 12, 2007, at 8:06 AM, Kevin Lawver wrote: I'm presenting on microformats at Web 2.0 Expo (well, hopefully, if they can move me back to my original time) next week, and would love to have more examples of folks using microformats as APIs. I ungraciously stole an idea I saw on the list of grabbing the URL used as an OpenID and looking for an hcard on it to build a demo for my talk, but, I'd love more examples to point to. I made an openid+hCard example at http://kevinmarks.com Also, anyone have the digits that Tantek likes to use about the number of pieces of microformatted content out there in the wild? I don't have the latest... ___ microformats-discuss mailing list [EMAIL PROTECTED] http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Fwd: Twitter Is Now Even More Geeky
On May 13, 2007, at 7:49 PM, Chris Messina wrote: XFN. All of the side bars use [rel=contact]. -ryan So yeah, it's hAtom + hCard + XFN. Pretty good, especially since we haven't seen too much hAtom pickup outside of a few WordPress blogs. Also rel=me on the URL links in personal pages, which is excellent going in to Internet Identity workshop this week. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel-tag links with #
On Aug 3, 2007 12:23 PM, Taylor Cowan [EMAIL PROTECTED] wrote: In using hAtom I was interested in populating the @scheme attribute of the Atom category. For example: It's interesting to me to know from where the tag comes, which community or folksonomy is it part of. It's valuable information that gets lost in the rel-tag parse as indicated by the spec today. That is the tagspace part for the URL, eg for htttp://technorati.com/tag/goat 'goat' is the tag and 'htttp://technorati.com/tag/' is the tagspace. This maps to the Atom scheme directly. Then I found that '#' anchors are ignored based on the defacto standards. (http://microformats.org/wiki/rel-tag-issues) This is by design. What impressed by is that the defacto standards pretty much entail that the last token of the link (/a/b/lastoken) and the label ( ..label/a ) are nearly always the same. This holds for nearly every example I've looked at. The concept of having a label, a visual display for a tag, is completely foreign to my understanding of tagsand yet the rel-tag allows for this. That's so odd, because tags are normally just that...the tag and nothing but the tag. I'd also bring to the discussion the theme of visual human readable data...wherein it seems preferable to have the link, and the tag be the same: a rel=tag href=/mytags/weirdThis is weird and rarely happens/a (although perfectly acceptable by rel-tag) should be: a rel=tag href=/mytags/normalnormal/a (this is the defacto standard, it's not weird like the previous example) and could also be a rel=tag href=/mytags#oktoooktoo/a (still abides by URL standards) no, this is tagging it 'mytags' The Display text allows a human-readable tag where the underlying url is less so eg a href=http://flickr.com/photos/tantek/tags/sanfrancisco; rel=tagSan Francisco/a What I find most ironic is that the defacto standards mentioned on the wiki, flickr and del.icio.us, don't even use rel-tag (or at least not yet). the HREF is valuable as a link to more information about the tag, from whence it came, related items, and the value of the a tag should contain the tag itself, as is the defacto standard and ESTABLISHED PRACTICE on both flickr and del.icio.us. I propose at the very least that '#' be allowed in the rel-tag spec...if we're writing weird parsers to snip of that last term based on '/', we might as well add '#' as a delimiter, and it would even be better if the spec can be reconciled with how tags are really used on the web, ie, the display text defines the tag. The reason we chose path component was a) this was existing practice and b) it provides some protection against using totally arbitrary URLs as tagspaces, which creates spam jeopardy. You need to link to a real tagspace that behaves sensibly if someone clicks on it. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Blogger's hAtom Support
http://epeus.blogspot.com/2007/08/microformats-in-blogger-hatom-support.html Those of you who read my blog directly, rather than via a feed-reader, will notice that it is looking styled again, for the first time since CSS Naked Day in April. I made an initial conversion to hAtom by hand in the meantime, but a few weeks back Michal Cierniak and I checked in a change to the underlying Blogger templates to make hAtom the default, which the Blogger team graciously accepted. This should enable much simpler client-side parsing of the blog pages. One thing we had to do to enable this was to add a new datatype to output a date in the W3C's ISO-8601 profile, as expected by hAtom. If you look in the templates now, you'll see markup like this: abbr class='published' expr:title='data:post.timestampISO8601' data:post.timestamp//abbr If you want to make your own hAtom friendly templates, you can use the data:post.timestampISO8601 appropriately in the date-time design pattern; the data:post.timestamp will reflect your personal formatting preferences as before. go to blogpost for links ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Wired call fro open social networking standard
http://www.wired.com/software/webservices/news/2007/08/open_social_net ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard: title or role
from vcard: 3.5.1 TITLE Type Definition Type name: TITLE Type purpose: To specify the job title, functional position or function of the object the vCard represents. Type example: TITLE:Director\, Research and Development 3.5.2 ROLE Type Definition Type name: ROLE Type purpose: To specify information concerning the role, occupation, or business category of the object the vCard represents. Type special notes: This type is based on the X.520 Business Category explanatory attribute. This property is included as an organizational type to avoid confusion with the semantics of the TITLE type and incorrect usage of that type when the semantics of this type is intended. Type example: ROLE:Programmer So Head of Marketing is a Title, Marketing is a Role, I'd say. On Sep 20, 2007 12:22 PM, Dimitri Glazkov [EMAIL PROTECTED] wrote: On 9/20/07, Andy Mabbett [EMAIL PROTECTED] wrote: In hCard, should a job title like Head of Marketing be classed as title or role, or both? What's the difference? Off the top of my head: role = executive title = Head of Marketing No? :DG ___ 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] semantic web and microformats
On Oct 9, 2007 10:27 AM, Tom Morris [EMAIL PROTECTED] wrote: The microformats community works on the basis of having the data embedded into the HTML. The RDF/SemWeb approach looks to have a consistent data model, and then having as many representations as you like of that data model. The data model for microformats differs based on which tool you use (perhaps it's in a key-value-pair array, or an object, or in an XML format) - even though it's getting the same syntax (HTML or XHTML). With RDF, you have the same model (subject, predicate, object) but with different syntaxes (XML, JSON, (X)HTML-with-GRDDL, N3/N-Triples, TriX, the new JavaScript proposal that's been circulating on the W3C semantic web mailing list, internal memory models, SQL table etc. Thats not quite right - the data model for any given microformat is clear. I think the 'common JSON representation' idea is a good one to help clarify this. There is also value in the 'write the parser once' approach. Each new microformat requires a new set of tools - Operator, Tails, X2V, Optimus and so on, will have to be rewritten or extended to cover new microformats. But RDF tools keep on reading RDF regardless of how many new schemas people create. Imagine if we had to recreate the DOM, XML parsers, XSLT, XPath, validators, XQuery and the rest of the XML stack whenever anyone came up with a new XML-based specification. That's a little spurious, Tom - the issue is not parsing it, it's translating the parsed results into something that has meaning to a human. That you can express things in triple or in nested dicts and lists is one thing; knowing that one means a name and one means a phone number is another. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] semantic web and microformats
Note that is more then 2 years after the original 'can your site be your API?' presentation by me and Tantek... great to see these ideas spread out. Drew's slides are much prettier though... and he cites 'fork handles' http://epeus.blogspot.com/2007/07/end-homographophobia-now.html On Oct 9, 2007 5:29 PM, Tom Morris [EMAIL PROTECTED] wrote: On 10/10/07, Patrick Aljord [EMAIL PROTECTED] wrote: On 10/9/07, Andy Pemberton [EMAIL PROTECTED] wrote: http://www.tantek.com/presentations/2004etech/realworldsemanticspres.html thanx for the link, I remember of another presentation of tantek çelik that was about using your website as an API, it looked a bit like that one but more recent maybe. Any idea where I could find it? Not Tantek, but Drew McLellan. See: http://allinthehead.com/retro/301/can-your-website-be-your-api Given at: http://microformats.org/wiki/events/2006-10-19-wsg-microformats-meetup -- Tom Morris http://tommorris.org/ ___ 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] web programmers vs web designers and microformats
In semantic HTML, the right way to do this would be to use cite around the name: citeJulie/cite so doing cite class=hcard a href=http://juliettemelton.com/; class=url uid fn rel=friendJulie/a/cite which has an implied nickname, and adds the XFN for my friend On Jan 4, 2008 2:23 PM, David Janes [EMAIL PROTECTED] wrote: On Jan 4, 2008 2:45 PM, Tantek Çelik [EMAIL PROTECTED] wrote: The fact that hCard is *the* #1 format for publishing information about a person on the Web would seem to refute that. http://microformats.org/wiki/hcard-supporting-user-profiles Profiles is not the problem that Andy Ryan C. are talking about: they're talking about using hCard in casual references to people and places on the web. For example, on your blog, you've coded: | My friend a href=http://juliettemelton.com/;Julie/a and I thought this up when discussing | end of year rituals, and threw it together quickly and roughly in a matter of days (like the first BarCamp). | We invited a bunch of people (also coarsely brainstormed, certainly not comprehensive), a few of | whom were actually available to attend, and shared an incredible two days of reflection | (what emdid/em you do) and projection (what are you emgoing to/em do). They're suggesting that you're much more likely to provide semantic information about Julie if you were willing to do the simple operating of adding (for example) 'class='vcard' to the A tag. Regards, etc... -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://blogmatrix.blogmatrix.com ___ 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] stats on well formed XHTML
What I found with the technorati crawler was that the atom timestamps were mroe reliabel than RSS, as RSS timezones were underspecified. Talking of hAtom, here's a tool that uses it: http://googlenotebookblog.blogspot.com/2008/01/permalinks-up-and-hatom.html Niall told em last night that he's submitted a patch to MT 4.1 that will make it output hAtom too. On Jan 17, 2008 4:05 PM, Kevin Burton [EMAIL PROTECTED] wrote: Not so. The Internet Archive knows the first time they've seen an URL, over the past ten years; they can also tell you when the content has significantly changed. Obviously, there is a bias towards pages (and sites) with higher traffic, but that seems reasonable if you're evaluating standard practices. ~ Derrick Pallas Yes... but it would suffer from crawler priority bias. If it was a low ranked page it might take a few month to get around to crawling it. Spinn3r would have better data here because we're real time Observing the URL and hAtom timestamp as I mentioned before would be nice but would suffer from bias again. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Largest Deployment of Microformats on one site?
maps.google.com has a lot as well, but they're only in response to searches. I bet eventful.com have a lot too. On Jan 18, 2008 1:11 PM, ryan [EMAIL PROTECTED] wrote: On Jan 18, 2008, at 12:31 PM, Ben Ward wrote: For reasons which will be revealed next week (yes, I'm a tease, sorry), I'm interested to know what the largest deployment of any microformat is on a single site, in terms of numbers of instances of microformats. I'm guessing its local.yahoo.com. I think its in the 10s of millions. -ryan ___ 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] rel-license: what does the license apply to? (open issue revisited)
Is the problem that the page contains multiple video elements? If so using hAtom to define them as separate entries may help clarify this, especially in conjunction with rel-enclosure. On Wed, Mar 19, 2008 at 4:40 PM, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote: Hey Angus, On Wed, Mar 19, 2008 at 8:32 PM, Angus McIntyre [EMAIL PROTECTED] wrote: I'm in the process of adding 'rel=license' in the relevant places on blip.tv, a video-sharing site, and I've run squarely into the 'open issue' raised by Evan on 2006-04-07 (in the wiki). Namely, there's no obvious way to specify that the license applies to a content element on a page - a picture, a video - rather than the page as a whole. (I should probably check this before posting... but I'm in a rush...) From what I remember of the HTML spec, an a element with the rel attribute set applies to all or part of the HTML page. An example of this is rel-bookmark used for hAtom. So... the rel-license could apply just to the video. From a machine point-of-view, there's no way (that I'm aware of) to differentiate when the rel-license applies to the whole page or part of the page. Suggestions welcome. See ya -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/ Vlog Razor... Vlogging News... http://vlograzor.com/ ___ 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 Mania in Vancouver, B.C - Events Aplenty Join Us - Open Web, VanDev, SocialCamp
As part of my talk on the Social web I'll be discussing Google's social Graph API, which is a cache of the distributed social graph created by XFN On Wed, Apr 9, 2008 at 8:40 AM, Gerald Bauer [EMAIL PROTECTED] wrote: Hello, Join us for the Open Web Vancouver 2008 two-day conference on Apr 14+15 in Vancouver, B.C on Canada's West Coast that will include talks on Microformats such as: o Microformats and Distributed Social Networks w/ Chris Messina o Microformats Past, Present, Future w / Ryan King More @ http://www.openwebvancouver.ca On Apr 16 I volunteer for a free talk at the University of British Columbia (UBC) downtown campus in Vancouver to talk on Microformats - Adding Semantics to Your Web Site - Web 3.0 in Action. Join us. More @ http://is.gd/4YM Finally, *you* are invited to speak and sign-up for a lightning talk (10-15min) at the upcoming SocialCamp part of the Open Web Vancouver 2008 event. More @ http://barcamp.org/SocialCampVancouver Cheers. -- Gerald Bauer - Internet Professional - http://geraldbauer.wordpress.com ___ 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] Parsing XFN in PHP
On Tue, Apr 8, 2008 at 11:41 PM, Julian Bond [EMAIL PROTECTED] wrote: Let me expand on that. Julian Bond [EMAIL PROTECTED] Tue, 8 Apr 2008 15:21:37 I'm really looking forward to the SG-API becoming useful, but right now it's pretty flaky. There's a lot of pages you'd expect to be in there that aren't and the result you get back aren't what you'd expect. SG-API actually worked very well for my purposes. I'm looking for outward edges and they came back in a pretty convenient form. However, it's dependent on the underlying index, not reading the pages in real time. And several friendfeed pages I tried had no data or incomplete data because they'd been created since the last time the spider called. So it looks to me like SG-API is a useful research tool, but not a useful data import tool. We expect to crawl more often soon; one thing that you can do is use the test parser as described here: http://groups.google.com/group/social-graph-api/browse_thread/thread/c2deffae0bba09dc and here: http://code.google.com/apis/socialgraph/docs/testparse.html to parse pages that are missing from the index (though I wouldn't recommend doing this for huge numbers of pages, it coudl help as a stopgap, and also as a way to validate your own local parsing. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Generically converting JSON to POSH
XOXO is the generic way to turn JSON into HTML (and back) - see
http://www.mail-archive.com/microformats-discuss@microformats.org/msg06827.html
The problem is knowing what are user-visible keys and what aren't
On Mon, Jul 14, 2008 at 6:01 AM, Nirmal Patel [EMAIL PROTECTED] wrote:
On Mon, Jul 14, 2008 at 4:52 AM, Toby A Inkster [EMAIL PROTECTED] wrote:
snip
Looks quite good. Personally I'd have converted JSON objects into definition
lists using DT for the key and DD for the value though. Then perhaps add the
key to the class of each *as well*. So, for instance:
{
key1 : value1 ,
key2 : value2
}
becomes:
dl class=json-object
dt class=key1key1/dt
dd class=key1value1/dt
dt class=key2key2/dt
dd class=key2value2/dt
/dl
I had initially done this but came to the conclusion that this put key1 into
the html as content and that seemed wrong.
Which should be more flexible with regards to styling, and probably more
useful when looked at without CSS. If you happen to like the unordered list
look, then:
I never intended to use the results of this library for exploring the JS. I
suppose that this should be made more explicit.
dl.json-object dt { display: none; }
dl.json-object dd { list-style-type: circle; }
And this was exactly how I styled the result. :)
However, have you considered what happens when the object keys contain
whitespace characters? e.g.
{
some key : some value
}
--
Toby A Inkster
mailto:[EMAIL PROTECTED]
http://tobyinkster.co.uk
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
--
Nirmal Patel
www.nirmalpatel.com
___
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] hcard authority?
Have a look at the representative hCard brainstorming: http://microformats.org/wiki/representative-hcard-brainstorming if the cards are linked, this can help you decide which to use. On Thu, Aug 28, 2008 at 10:04 AM, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote: Hello James, On Thu, Aug 28, 2008 at 9:39 AM, James Tindall [EMAIL PROTECTED] wrote: Hi, I was just wondering if there's any existing mechanism for determining the authority of hcards? In other words, if a social graph query finds two hcards in different locations refering to the same person are there any guidlines for determining which should be considered authoritative if neither one has a rev value? That's likely beyond the scope of the hCard spec. Although I think people can become creative with figuring out that kind of information. Using information like... - the domain's WHOIS information. - the number of hCards on a domain. - whether the hCard is on the homepage or not. - a comparison of the various hCards out there for the person (to look for matching data, conflicting data, etc) etc, etc. It will probably take some trial and error and an observation of how people are using hCards (today)... to figure out an algorithm that is good enough. (Over time, as people's usage of hCards changes, you may need to change your algorithm.) See ya -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/ ___ 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] title - heading/label/caption/?
Have a look at http://microformats.org/wiki/existing-classes 'label' is used in hCard for unstructured addresses. could you re-use 'entry-title' from hAtom? On Thu, Jan 15, 2009 at 3:01 AM, Thomas Loertsch loertsch.tho...@guj.de wrote: hi, in hRecipe we use recipe-title to avoid the problems with the title tag. but this is ugly and it doesn't scale - it's not reusable in other microformats. therefor i consulted a thesaurus and filtered out the following alternatives: heading caption label since i'm not a native speaker i would like to get some advice on the subtle differences in meaning. from what i understand heading has a connotation of layout, mixing style with structure, caption is more of a byline to something than the top or beginning of it, label is more attached to a thing, not so much an integral part of it. if all this is correct, then i would argue that heading would still be a good alternative to recipe-title and suitable for most occurrences of titles, while label or caption could be viable alternatives to title in other cases. heading also has a semantic connection to h1, h2 etc, which may not be such a bad thing. any thoughts? thomas . Thomas Lörtsch Business Development G+J ExclusiveLiving digital GmbH .. Stubbenhuk 5 20459 Hamburg ... eMail: loertsch.tho...@guj.de ___ 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] FYI: serialization of hCard into JSON
Do have a look at http://portablecontacts.net - the JSON spec there is a good model to go to and from hCard (thats where we staretd from wehn desiging it, before we looked at a lot of other contact schemas too). On Mon, Mar 2, 2009 at 9:55 AM, David Janes davidja...@blogmatrix.com wrote: I've been playing about with representing microformats ... hCard in particular ... efficiently and usefully into JSON-type data structures. Here's a blog post on the topic [1]. Regards, etc... [1] http://code.davidjanes.com/blog/2009/03/02/auapi-encoding-hcards-in-json/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] FYI: serialization of hCard into JSON
Whats the data loss? One of the nice things about these tools is that you can chain them, eg piping hCard into PoCo through vCard: : http://www.plaxo.com/pdata/vcard?vcardUrl=feeds.technorati.com%2Fcontacts%2Fkevinmarks.com and piping the result into XOXO for easier human readability: http://kevinmarks.com/cgi-bin/jsontoxoxo.py?url=http://pulse.plaxo.com/pulse/pdata/vcard?vcardUrl=feeds.technorati.com%2Fcontacts%2Fkevinmarks.com On Tue, Mar 3, 2009 at 8:41 AM, Glenn Jones glenn.jo...@madgex.com wrote: Hi David I have done quite bit of work around serialising microformats into both JSON and XML. The current version of my UfXtract parser is designed to consider the description of microformats as a loadable profiles. When I want to add a new microformat I build a new profile object. As such I have also been able to build generic JSON/XML serializers and de-serializers for the parser. They allow me to export and import microformats in JSON/XML without any data loss or added ambiguity. A while back I was really interested in moving this work forward within the community to get an agreed standard. There did not seem much interest at the time, so I documented some of my earlier work on wiki [1]. I think that Toby has since done some work with JSON support in Swignition. I have also looked at the Portable Contacts groups work and done some experimental conversions demos [2]. Although I think this project is a good idea, they have taken an approach with the scheme that allows for conversion between the 2 standards but there is some data loss, so it's not truly compatible. jCard[3] is also a good effort, my only problem was I wanted a serialization structure which can be applied to any microformat. It's also interesting to look at the work Yahoo has done with YQL [4], which can parse some microformats and return JSON/XML. Maybe not the best format, but very interesting toolset. Although the microformat design process did not originally have the concept of an output format, there are times when this would be useful. As parsers mature, we need an easy way to support the interchange and integration of data. Not just for parsers, but also for the applications that use them. A standard output format should encourage a greater culture of reuse and sharing between developers and help collaborative projects such as the building of shared test suites and other tools. If you check out the Microformats OAuth demo on my labs site you can see the serializer and de-serializer in action on the test bed page [5]. You have to create an account on the test site first. [6] [1] http://microformats.org/wiki/json [2] http://lab.madgex.com/portablecontacts/ [3] http://microformats.org/wiki/jCard [4] http://developer.yahoo.com/yql/ [5] http://lab.madgex.com/microformats/apidemo/testbed.aspx [6] http://ufapi.lab.madgex.com/ Glenn Jones On Mon, Mar 2, 2009 at 9:55 AM, David Janes davidja...@blogmatrix.com wrote: I've been playing about with representing microformats ... hCard in particular ... efficiently and usefully into JSON-type data structures. Here's a blog post on the topic [1]. Regards, etc... [1] http://code.davidjanes.com/blog/2009/03/02/auapi-encoding-hcards-in-js on/ ___ 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] Multiple vote-links
On Tue, Jun 9, 2009 at 8:10 AM, Bruno Barberi Gnecco br...@likeorhate.com wrote: On Mon, 2009-06-08 at 18:17 -0300, Bruno Barberi Gnecco wrote: We are using vote-links extensively in our new site (likeorhate.com) And doing so wrongly. VoteLinks are a badly named microformat. They are *not* for polling. They are for linking to articles about stuff you like or dislike. They are links that express votes - if you can suggest clarifications to the text of the microformat page that make this clearer that would be appreciated. e.g. I like a rev=vote-for href=/cheesecheese/a, but not a rev=vote-against href=/broccolibroccoli/a. That means that this page counts as a vote for cheese and a vote against broccoli. Although votelinks is unclear on the semantics - do I like cheese, or do I like that particular page about cheese? That page is the default assumption. Links are between pages. I suppose you could combine with rel-tag to express an abstract category instead: a rev=vote-for rel=tag href=/cheesecheese/a, but in that case you may be better off using the ratings in hreview, which are designed for that purpose VoteLinks are quite muddy and their meaning is pretty unclear. I'd disagree there. The intent is clear -to be able to express agreement and disagreement with a linked-to page from the current context. In practice, however, rel-nofollow has won out as disagreement, with plain links as agreement. The formulation above: a rev=vote-for rel=nofollow href=...Like/a has 2 votes for the same thing, as rel=nofollow is equivalent to rev=vote-abstain - very hard to work out what your intent is there,. With RDFa, you can state each of those meanings unambiguously. With hReview you can express what you want here If you like cheese (the page), then: p about=#me xmlns:like=http://ontologi.es/like#; I like a rel=like:likes href=/cheesecheese/a. /p div class=hreview span class=reviewer vcardspan class=fnKevin Marks/span/span abbr class=rating title=5likes/abbr div class=itema href=/cheese class=fn urlthis cheese page/a/div /div If you like cheese (the food), then (a little more complicated): p about=#me xmlns:like=http://ontologi.es/like#; xmlns:foaf=http://xmlns.com/foaf/0.1/; I like span rel=like:likes a rev=foaf:primaryTopic href=/cheese property=foaf:namecheese/a /span /p div class=hreviewspan class=reviewer vcardspan class=fnKevin Marks/span/span abbr class=rating title=5likes/abbr div class=itemspan class=fncheese/span/div /div Strangely, no I don't like in that ontology? I see Opinion could be used for it, but... However, for a polling site, neither votelinks nor the example above are appropriate. You're not trying to capture the meaning that this page is about something I like - you're trying to capture the meaning of this link is for voting. I don't know of a microformat, or indeed an RDF vocabulary, that covers that meaning, but I can certainly see value in creating one. Thanks for the clarification. Since their meaning is unclear (as you and the FAQ state), why not let them be used for this purpose as well? I suppose with a class or another attribute together one could separate what is a poll link (vote for this) and what is an opinion (I have voted for this). The meaning of the link isn't unclear, the intent on whether the page or the idea or person represented by the page is a little unclear. How would adding extra ambiguity be at all usefule? Otherwise, if vote-links are not used for polling and there is not (it seems) a microformat for it, how to propose a new one? well, the process for defining a new microformat is explained here: http://microformats.org/wiki/process It would be nice to have a more general microformat for associating a target with a label, more or less like xfn. you mean tagging a linked-to page? that's what xfolk is for: http://microformats.org/wiki/xfolk though in practice hReview seems to be used more widely for this. Again, the problem of acting on vs having acted on that confused me shows up. How about something like this rough draft to follow. For acting on (polling): div about=#something class=item a href=... rel=action:likeI like cheese/a a href=... rel=action:blueI think cheese is always blue/a /div For having acted on (similar to vote-links) div about=#me class=item a href=... rev=opinion:likeI like cheese/a p href=... rev=opinion:blueI think cheese is always blue/a /div Although I think this later one should also have information about who likes it (perhaps an hCard), since we could, for example, have a list of expert opinions about cheese. But I don't like the exchanges of roles of about (I hope I got it right). I think that HTML forms would likely be the
Re: [uf-discuss] Google Rich Snippets - testing tool
Great tool guys. I tried it on my original hReviews, - looks like your rating extraction is not honouring the abbr title pattern - it shows you seeing my unicode stars, not the title='4' http://www.google.com/webmasters/tools/richsnippets?url=http%3A%2F%2Fepeus.blogspot.com%2F2005%2F04%2Frevisiting-waugh-and-armstrong.html On Thu, Aug 27, 2009 at 10:11 AM, Edward O'Connorhob...@gmail.com wrote: Hi, We have created an early version of a testing tool to allow webmasters to check that their markup is being correctly parsed by Google for use in Rich Snippets. Wow, very nice. Thanks for making this available! We would love to have you try the tool out and send us suggestions, points of confusion, bugs, or any other general feedback. Does the tool support hCard's additional-name? I don't see any of the middle names from http://federali.st/declaration in the results. I'm also surprised by some results for http://federali.st/constitution. Thanks again, Edward O'Connor ___ 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] Ident Engine
Great stuff glenn! 2009/10/8 André Luís andr3...@gmail.com Hi Glenn, comments inline. On Thu, Oct 8, 2009 at 10:24 AM, Glenn Jones glenn.jo...@madgex.com wrote: Hi André Thanks for the nice comments about the identity work. Can you email me a quick summary of the errors off the list and I will have look. You deserve it. And I will ask them for details and fwd them to you. Like microformats one of the aims of identity consolidation should be to surface the data so that it is not hidden from the user. This is especially important when rel=me linking goes wrong, users want to explore the issue themselves. I had this conversation Brad Fitzpatrick the creator of the Google Social Graph API earlier this year. We both agreed we need to build some sort of visualisation tool to explore social graphs. I think I have achieved this for profiles with Ident Engines. You can see what profile information is store about you and where, but I have yet to look at visualisation of the rel=me linkages. More importantly found a way to allow users to explore issues with their own graph. The tool I use the most at the moment is: http://identengine.com/debug/debug-identites.htm It's only a linear list, but sometimes help me find rogue relationships Right! At least it allows people to take care of the weeds in their social graph. Funny. One of the comments I heard when someone was trying it out was: hey! I've told them [whoever they might be] to remove that site/link!! hahaha Apparently he didn't know someone was still linking an extinct website as his somewhere. :) The example one I built when we launched the SG API can be quite handy too, as it shows degree of connectedness too, and inbound-only : http://socialgraph-resources.googlecode.com/svn/trunk/samples/findyours.html eg http://socialgraph-resources.googlecode.com/svn/trunk/samples/findyours.html?q=kevinmarks.com BTW, your code isn't finding the hCard on kevinmarks.com As for visualization of the social graph, I've been using http://workshop.andr3.net/xfnexplorer/ but it's very very slow, limited to 200 nodes and not distributable. The parsing is done via serverside, using Dmitry's Optimus. I see myself rewriting this to link the Ident engine and JIT toolkit (see footer) to achieve the same results but much faster. :) Cheers, André Luís Glenn -Original Message- From: microformats-discuss-boun...@microformats.org [mailto:microformats-discuss-boun...@microformats.org] On Behalf Of André Luís Sent: 07 October 2009 16:19 To: Microformats Discuss Subject: Re: [uf-discuss] Ident Engine Glenn, thank you (once again) for your effort. This is *huge*. I believe it *does* lower the barrier of using identity discovery. Specially given the level of interest around js. And thank you for including a note on progressive enhancement on your ALA article. ;) Meanwhile, I've pimped the lib around the office and some of them are sending me feeback on some of the tests they ran. Would you be interested in checking some of the faulty results? One of them got a sgn:// template URLs from myspace in one of your demos. Cheers, -- André Luís On Tue, Oct 6, 2009 at 1:06 PM, Glenn Jones glenn.jo...@madgex.com wrote: Hi All I have built a little JavaScript library that combines Social Graph data and parsing of open data sources such as microformats. http://identengine.com/ http://www.alistapart.com/articles/discovering-magic/ Earlier this year Chris Messina made the passing comment that the techniques I demoed involved too much hoop jumping to be of practical use. I built this library to see if I could lower the barrier of entry. A List Apart published an article I have written on the libraries architecture. The library makes extensive use of both the Google's Social Graph API and Yahoo's YQL. It all under a MIT license Try out the demo's Glenn Jones ___ 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
