Re: [uf-discuss] Anyone knows of an hcalendar-to-ical service that supports simple RRULEs?
On Mon, 12 Dec 2011 14:59:47 +
André Luís andr3...@gmail.com wrote:
The only one that picked it up was Glenn's http://ufxtract.com/ but it
doesn't provide .ics output. ;)
My HTML::Microformats Perl module should support arbitrarily complex
rrules (and rdate, exrule, exdate).
It natively converts from microformats to RDF, but if it detects that
the RDF::iCalendar Perl module is installed, it can also offer
iCalendar output.
Usage would be something like this:
use HTML::Microformats;
use RDF::iCalendar;
use LWP::Simple;
my $uri= 'http://example.com/page.html';
my $markup = get($uri);
my $document = HTML::Microformats
-new_document($markup, $uri)
-assume_profile('hCalendar');
print $_-to_icalendar
foreach $document-objects('hCalendar');
I'm not currently running it as a web service though.
--
Toby A Inkster
mailto:m...@tobyinkster.co.uk
http://tobyinkster.co.uk
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Meetup to workshop/brainstorm input microformat ideas
On Tue, 22 Feb 2011 08:46:08 - Glenn Jones glenn.jo...@madgex.com wrote: What about everyone else? It's been a while since we had a UK microformats meetup. You can put me down as tentative. London or Brighton would be fine - prefer Brighton. -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] input microformats for auto-filling forms
On Tue, 22 Feb 2011 08:26:13 - Glenn Jones glenn.jo...@madgex.com wrote: Could you point me to the documentation for grouping syntax in RFC 2425, Google it with not much luck. http://tools.ietf.org/html/rfc2425#section-5.8.2 See the ABNF production for 'contentline'. The grouping construct allows you to say that certain lines within a vCard (or indeed any text/directory-based format) belong together. e.g. BEGIN:VCARD VERSION:3.0 FN:Prince Charles N:Windsor;Charles;Philip,Arthur,George;Prince;KG,KT,GCB,OM,AK,QSO,CD,SOM, GCL,PC,AdC(P),FRS CON.TITLE=Duke of Cornwall CON.NOTE=The prince has been Duke of Cornwall since 6 February 1952. WAL.TITLE=Prince of Wales WAL.NOTE=The prince has been Prince of Wales since 26 July 1958. END:VCARD vCard 3.0 (RFC 2426) uses text/directory syntax, thus this is allowed. However, as none of the examples in RFC 2426 use it, it's not especially well-supported in vCard 3.0 implementations. vCard 4.0 mentions the construct explicitly; some drafts have included examples of it in use, but the latest does not; consumers that don't care about grouping are just advised to strip /^([^\.\:]*\.)/ off the front of each property. -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] input microformats for auto-filling forms
On Tue, 15 Feb 2011 15:49:11 -0500 Stephen Paul Weber singpol...@singpolyma.net wrote: input type=vcard Interesting, but invalid and does not have a good fallback mechanism. Most things are invalid when they're first proposed. Unknown input types are generally treated as type=text by browsers, which is not a great fallback, but perhaps usable. Sites adopting type=vcard early would just need to be prepared to accept free-form contact data occasionally - but only from clients with scripting disabled, as type=vcard can be implemented in Javascript... http://buzzword.org.uk/2011/input-type-vcard/test.html -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard, i18n and screen readers
On Tue, 11 Jan 2011 17:06:33 -0800
Jeff codedr...@gmail.com wrote:
Doesn't HTML5 microdata use the meta element for this purpose?
That doesn't really work outside XHTML.
The problem is that the HTML5 parsing algorithm hoists meta elements
into the document head. In other words:
!doctype html
headtitleExample/title/head
body
meta name=foo content=bar
script
var heads = document.getElementsByTagName('head');
var metas = heads[0].getElementsByTagName('meta');
window.alert(metas[0].name + metas[0].content);
/script
/body
Will alert foobar. The browser assumes that you really meant to put
the meta element in the head. This behaviour is inherited from legacy
browsers who made this assumption because meta has never been allowed
in the body.
RDFa's content attribute is a nice solution for hiding a machine
readable value, and somewhat less of a hack:
e.g.
p about=#i rel=foaf:based_near
I live in span property=geo:lat_long
content=50.875627;0.017855Lewes (50°52′N, 0°1′E)/span
/p
--
Toby A Inkster
mailto:m...@tobyinkster.co.uk
http://tobyinkster.co.uk
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard and Internet Retailers (Shopping Contact Information)
On Sun, 2010-10-17 at 18:19 +0100, Junaid Nazir wrote: We are actively working with the product catalogues of some 500 internet retailers through our shopping search engine database at http://www.superstoresearch.com and we have access to thousands of more contacts in the shopping and retail industry - if we have some agreed and suitable standards for the various types of contact information, we could reach out to the internet retailers and put forward the suggestion that they adopt such standards and implement them on their e-commerce sites. Have you looked at GoodRelations? It's an RDF-based method of marking up businesses (including stores/branches/offices), opening hours, products, services and offers. Via RDFa it can be embedded in HTML. GoodRelations is apparently being consumed by Yahoo and Google; and is being published by O'Reilly (the book publishers) and BestBuy (an electronics retailer) amongst others. http://www.heppnetz.de/projects/goodrelations/ -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Marking up radio stations
On Sat, 24 Jul 2010 05:04:50 +0100 Corey Mwamba send.miss...@coreymwamba.co.uk wrote: I was wondering if anyone had any suggestions as to how to mark up a radio station using microformats, especially in relation to the frequencies - which I see as a type of address! Any thoughts? Interesting question. hCard is probably a good start: div class=vcard b class=fn orgHeart FM (Sussex)/b i102.4 MHz/i /div Now, how to encode the frequency? It is an address of sorts, or at least a locator. Not the kind of address that is suitable for marking up with class=adr though. If there were a URI scheme for radio wave frequencies this would be a little easier: div class=vcard b class=fn orgHeart FM (Sussex)/b a href=radio:fm:10240 class=url 102.4 MHz/a /div Radio stations are very geography-specific. 50 miles away a completely different organisation could be broadcasting on the same frequency. So our hypothetical radio: URI scheme would probably need a geographic signifier to be attached: div class=vcard b class=fn orgHeart FM (Sussex)/b a href=radio:fm:10240;context=geo:50.9761,0.2293 class=url102.4 MHz/a /div However, such a URI scheme does not exist. It could be registered with IANA, or you could bypass that requirement by using a specialised HTTP prefix instead, a la http://dbooth.org/2006/urn2http/. Short of specialised URIs to identify radio signals, the most appropriate construct in hCard would probably be class=note. e.g.: div class=vcard b class=fn orgHeart FM (Sussex)/b i class=note 102.4 MHz abbr title=50.9761;0.2293 class=geo(Eastbourne)/abbr /i /div -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] re: HTML5 support
On Tue, 20 Jul 2010 08:29:48 -0400 Stephen Paul Weber singpol...@singpolyma.net wrote: Having written significant code both in-browser and out to parse microformats, I find the claim that parsing them using the DOM is not practical shocking. What would you prefer? Parsing microformats via the DOM is not practical. Parsing them any other way is even worse though. While writing DOM code to parse a particular site's implementation of say, hCard, is pretty trivial, generalising that to support all the variations of how hCard is marked up in the wild is a lot of work. As a comparison, I have written Perl parsers[*] for microformats, RDFa and Microdata. Here are the lines-of-code counts for each, excluding documentation, comments and blank lines: Microdata : 945 RDFa 1.0 : 1265 RDFa 1.1 [**] : 2611 microformats : 9455 * = See http://search.cpan.org/~tobyink/. ** = this code actually handles both RDFa 1.0 and 1.1. Whatsmore it can handle them embedded in Atom, SVG and OpenDocument Format; not just (X)HTML. A pure RDFa-1.1-in-(X)HTML parser could probably be written in under 1000 lines of Perl. The amount of code needed to parse microformats is clearly different from the other formats. Another difference is that the Microdata and RDFa 1.0 implementations can be considered more-or-less complete. (The RDFa 1.1 working drafts are still somewhat is flux, so the implementation no doubt still needs changes.) If somebody comes up tomorrow with a new RDFa or Microdata vocabulary for describing cows, or bread makers, or train timetables, it will work out of the box. For microformats, that's not the case - code needs to be written. So you end up with a chicken-and-egg situation with nobody implementing tools for a new draft microformat because it's not used in the wild; nobody using it in the wild because of a lack of tool support; and the microformat never progressing beyond draft status because of lack of implementation experience, and uncertainty about how it might work in the wild. That's why we haven't had any of the draft microformats on the wiki move out of draft status in the last four years or so; or at least it's a major contributory factor. -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] 2 billion hCards! gathering material for a microformats.org turns 5 blog post
On Thu, 8 Jul 2010 01:25:03 -0700 Tantek Çelik tan...@cs.stanford.edu wrote: If there are problems with Twitter's hCards, please document the specific problems on the respective issues page that way we can better verify the problem report(s), investigate possible causes, and suggest fixes to Twitter as well. It's been documented on the Wiki since 2007. http://microformats.org/wiki/implementations?diff=23858 My understanding of RDF(a) advocates is that one of the design principles of RDF(a) is its infinite extensibility and philosophy of encouraging everyone to make up their own vocabulary (which is often contrasted with microformats opposite design principle of deliberate re-use of shared vocabularies for better interoperability and communication). I wouldn't say that RDF encourages everyone to make up their own vocabulary, but that it makes it feasible. Google using their own RDFa vocabulary is a direct consequence of this principle/philosophy of RDF(a)/namespaces etc., and thus if there's a problem with that approach, it merely calls into question that principle/philosophy of RDF(a)/namespaces. There's no problem with Google making up their own RDF vocabulary. The problem is counting the number of uses of their own vocabulary on the Web, taking that number and claiming it as representative of RDFa deployment as a whole. The counter-argument is that perhaps it is/was a case of simultaneous invention, which I would prefer to give more weight to, except that the microformats introduction of rel-license was explicitly discussed/mentioned afterwards on the Creative Commons mailing list[3] where many related subsequent RDF discussions were had: http://lists.ibiblio.org/pipermail/cc-metadata/2004-February/000290.html If you go back a further three months you'll see this thread: http://lists.ibiblio.org/pipermail/cc-metadata/2003-December/000237.html Cory Nelson wrote: | I propose sites under a CC license include a meta tag in their header | saying so. Though this won't help people recognize the content as | being under a CC license, it could help search engines greatly. | | Here is an example: | | meta name=license | content=http://creativecommons.org/licenses/by-nd-nc/1.0/; / And Lucas Gonze followed up with: | It would also work to have a link rel= element So the seed of the idea had been around since before the microformat proposal. Certainly the microformat proposal solidified the idea, but it's not inconceivable that when rel=license was proposed to be added to XHTML2 (the metadata parts of which evolved into RDFa), Ben Adida was drawing from earlier ideas, and possibly unaware of the microformat. http://lists.w3.org/Archives/Public/www-html-editor/2005AprJun/0178.html It's worth noting that before license was added to the XHTML2 link relations vocabulary, the term license was already defined in both Creative Commons' and Dublin Core's vocabularies, in the former case since 2008. Ben's proposal seems not so much inspired by the microformats use, but rather to move the term license out of Creative Commons' namespace to help clarify that it may be used to point to non-CC licenses too. -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] 2 billion hCards! gathering material for a microformats.org turns 5 blog post
On Wed, 7 Jul 2010 02:25:38 -0700 Tantek Çelik tan...@cs.stanford.edu wrote: E.g. Wordpress.org results don't have any RDFa. View source and the only thing even remotely resembling you see is: meta property=fb:page_id content=... - which is simply use of an invalid property attribute (in XHTML 1.0). The qname fb: is not defined anywhere. In the current RDFa 1.1 drafts, this is allowed, though its meaning is not likely what the authors of this page intended. In 1.1, prefixes which are not bound to anything are assumed to be absolute URIs. The page at http://wordpress.org/ does actually contain 3 triples if evaluated as RDFa 1.0, though they're each the result of RDFa grandfathering in certain HTML 4/XHTML 1 semantics. The question how many pages contain RDFa? is only meaningful if certain qualifications are added... Does broken RDFa count? Do grandfathered rel/rev values count? c. In fact, how many pages questions about the Web are not especially meaningful. Say Google added an hCard to its search result pages, replacing its current logo with something like this: span class=vcard a href=/ class=url img class=logo fn org alt=Google src=... / /a /span Are the search results for foo and bar different pages? What about the search results for 1001 and 1002? Because if they are, that's over a hundred billion hCards online. -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] VoteLinks
If on a page I'm writing about Albert Einstein, I include: a rev=vote-against href=http://en.wikipedia.org/wiki/Quantum_Physics; Does that mean that I'm negatively endorsing quantum physics, or that Albert Einstein did? Or both? Or is this undefined? *How* can we determine who the voter is? *Can* we determine who the voter is? -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] best practices to represent person working at
say I want to represent a doctor working at a hospital. What's the preferred way to represent that? div class=vcard span class=fnPerry Cox, MD/span div class=orgSacred Heart hospital/div div class=adr div class=street-address1 Hospital Avenue/div span class=localitySan Diego/span, span class=regionCA/span span class=postal-code92101/span /div div class=tel619) 555-5020 x 1234/div /div The other way to do it would be to invert it and create an hCard for the organisation, listing the doctor (or doctors) as an agent: div class=vcard h1 class=fn orgSacred Heart hospital/h1 div class=adr div class=street-address1 Hospital Avenue/div span class=localitySan Diego/span, span class=regionCA/span span class=postal-code92101/span /div h2Staff/h2 ul li class=agent vcard b class=fnPerry Cox, MD/b div class=tel(619) 555-5020 x 1234/div /li li class=agent vcard b class=fnJohn span class=nickJ.D./span Dorian/b div class=tel(619) 555-5020 x 4321/div /li !-- etc -- /ul /div -Toby ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] HTML 4 strict only
On Tue, 2010-03-23 at 10:51 +0100, Harald Effenberg wrote: Is /H1 valid HTML 2.0? ;-) Yes, if it's followed by another tag. e.g. h1Foo/h1pBar/p That's valid in HTML 3 and 4 too. It's an SGML shortcut that browsers never actually implemented, but in the particular place I've used it their error-correction seems to compensate for it. How about this... !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0//ENtitle//p It is, I think the shortest possible valid HTML 4.0 document. But this is getting seriously off-topic... -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] HTML 4 strict only
On Mon, 2010-03-22 at 09:38 -0600, Andrew Jaswa wrote: Like what? class? id? If I remember correctly microformats where meant to be portable across all versions* and using non-standard attributes wouldn't make sense. * 4.0+ atleast The rel- and rev-based microformats (e.g. rel-tag, votelinks, etc) can be used validly as far back as HTML 2.0. But HTML 2.0 didn't include a class attribute, so the bigger microformats can't be used. I think the HTML 3.0 drafts included the class attribute, but HTML 3.0 faltered and never really happened. HTML 3.2 was published as a W3C Recommendation, but didn't include class. (The DTD explicitly mentions it as something that was omitted.) -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] HTML 4 strict only
On Mon, 2010-03-22 at 16:12 -0600, Andrew Jaswa wrote: Ha. I would hop no-one uses HTML 2.0 any more! I use HTML 2.0 for the error pages on my personal website, more as an easter egg than for any other reason. e.g. http://tobyinkster.co.uk/this/should/give/you/a/404 -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Org HCard with special phone number
On Thu, 2010-03-18 at 09:31 -0500, Sean Edison-Albright wrote: This makes sense -- if I'm following correctly, the Help Desk is essentially an individual entity within the organization, rather than part of the contact info for the org. Thanks for your help, all! Yes - and the 'agent' property relates the two hCards. Of interest may be the definition of the AGENT property in vCard: http://www.ietf.org/rfc/rfc2426.txt -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Org HCard with special phone number
On Thu, 2010-03-11 at 11:20 +1300, Paul Wilkins wrote: I believe that there is a label that can be applied for each phone number. http://microformats.org/wiki/hcard-issues-resolved has an entry starting with RFC2426 allows TYPE for LABEL which covers the need to update the hCard specification so that they are formally used in the same manner in which they are used in the vCard specification. I think you're misinterpreting that issue. It refers to the fact that the label property (for address labels) can have types. e.g. div class=vcard b class=fnJoe Bloggs/b span class=label i class=typeHome/i span class=value123 Test Street, Testville/span /span span class=label i class=typeWork/i span class=value45 Example Lane, Testville/span /span /div The label property differs from adr in that it's not broken down into subproperties (street-address, etc). Here's how I'd do it: div class=vcard h1 class=fn orgMy Org/h1 p bGeneral Enquiries:/b span class=tel01234 567 890/span /p p class=agent vcard span class=org abbr class=organization-name title=My Org/abbr b class=organization-unit fnHelp Desk/b /span span class=tel01234 567 899/span /p /div -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Problems with comma separated ratings in the Google Rich Snippets Testing Tool
On Wed, 2009-12-30 at 13:56 +0100, Petersen, Dennis wrote: A normal German date would be 19.11.2009 which is not recognized by the Testing Tool. Instead the American format is expected which leads to the same problem mentioned above. US-style dates (mm/dd/) should not be expected. Microformats use ISO 8601 (-mm-dd) dates. http://microformats.org/wiki/date-pattern -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Extended types (as in VCard, chapter 3.8)
On Wed, 2009-12-16 at 11:34 +0100, Tobias Prinz wrote:
3. Not work with extended types at all. Which makes it unattractive to
all systems that want to use hCard as a basic system to exchange data
but want to extend it. It also is not in the spirit of VCard, I'd say.
In Swignition I implemented a handful of X-* properties, though this was
a list of additional properties recognised by the parser rather than
just allowing the page to specify arbitrary classes beginning with x-.
So I might be willing to use a work-around and (ab)use another element
to store those values. I was just wondering which element would make
the most sense?
It would need to be an element that has a type (to hold the real
attribute name), that can appear more than once and that, ideally, has
a very broad meaning. What would you use?
span class=categorySalary - €5/span
span class=categoryShoe Size - 10.5/span
span class=categoryFavourite Pizza - Pepperoni/span
Then skim through categories doing something like this (Javascriptish
pseudo-code):
$data = new Array();
foreach ($vcard.category as $category)
{
if ($category.matches(/ - /))
{
($key, $val) = $category.split(/ - /);
if (!$data[$key]) $data[$key] = new Array;
$data[$key].push($val);
}
}
--
Toby A Inkster
mailto:m...@tobyinkster.co.uk
http://tobyinkster.co.uk
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Marking up properties which reused pre-existing microformat
On Mon, 2009-12-14 at 20:27 +, Glenn Jones wrote: Breaking apart the education and vevent into separate element class attributes. Correct if I am wrong but only the first pattern should be supported by parsers. I originally only supported the class=education vevent style in Swignition, but eventually relented and supported the separate elements style too. It's so widespread, that I just gave up fighting against the tide. Not specifically talking about hResume here, though that is as good an example as any. Others include hCard's agent property, hCalendar's contact etc properties, hAudio's contributor property, etc. -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard, photo element: Inlined or embedded images according to rfc 2397?
On Fri, 2009-12-11 at 12:34 +0100, Tobias Prinz wrote: Of course I also have to check whether the parser I am currently using supports this, too (which is independent of the standard), but right I am more interested in the standard itself. Swignition http://buzzword.org.uk/swignition/ does support RFC2397 data URLs. When it outputs vCard it converts them on the fly to PHOTO;TYPE=BASE64: properties which seem to be better supported in address book apps than data URLs are. The Swignition web service is down right now, but the Perl library and command line app is still available for download. -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] 18 months
Given that it's been 19 months now, has Andy Mabbett's 18 month ban been lifted? http://microformats.org/discuss/mail/microformats-discuss/2008-March/011674.html -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] microformats.org hacked!
Seems to have fallen victim to the current WordPress security problem. -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] What does the 'h' in microformats mean?
On Thu, 2009-07-09 at 09:15 +0100, Martin McEvoy wrote: I wander if anyone can tell me what the 'h' in microformats means? hAtom, hCard, hCalendar, hReview etc are all named after the character Horatio H Caine from the popular police procedural television series CSI: Miami. -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Multiple vote-links
On Tue, 2009-06-09 at 12:46 -0700, Kevin Marks wrote: 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. I think clarifying VoteLinks is a task that goes beyond my abilities. But this issue has been raised before, it's not an isolated case of confusion, so I do think some sort of clarification is needed. http://microformats.org/wiki/vote-links-issues#Issues -- Toby Inkster m...@tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Multiple vote-links
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. 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? VoteLinks are quite muddy and their meaning is pretty unclear. With RDFa, you can state each of those meanings unambiguously. 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 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 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. -- Toby Inkster m...@tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and keyword spamming
On Tue, 2009-06-02 at 00:01 -0700, Elli Albek wrote: 3. Alternative formats: RDF? RDFa is pretty good at avoiding repetition. e.g. body xmlns:r=http://purl.org/stuff/rev#; xmlns:foaf=http://xmlns.com/foaf/0.1/; div typeof=foaf:Organization h1 property=foaf:nameMaharishi Ayurveda Health Spa/h1 ul rel=r:hasReview li typeof=r:Review h2 property=r:titleAwesomeness!/h2 p rel=r:reviewer a rel=foaf:homepage href=http://bob.example.com/; property=foaf:nameBob/a /p p property=r:textThis spa is very good!/p p property=r:rating content=4☆/p /li li typeof=r:Review h2 property=r:titleAwfulness!/h2 p rel=r:reviewer a rel=foaf:homepage href=http://joe.example.com/; property=foaf:nameJoe/a /p p property=r:textThis spa is horrible!/p p property=r:rating content=1★☆☆☆☆/p /li /ul /div /body -- Toby Inkster m...@tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] XFN 1.1 and CC BY-ND
Given the public domain policy, does XFN 1.1's licence make it ineligible as a microformat? Ditto XMDP. -- Toby Inkster m...@tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Announcing poshformats.org
Occasionally proposals are floated here, or on uf-new, or the Wiki, or IRC channel, which are too obscure to ever end up as a microformat. Most are destined to never get the buy-in from tool (parsers, authoring tools) writers that will make them useful. When these ideas come up, people are often told this isn't appropriate for microformats.org but aren't given an alternative suggestion. That's where poshformats.org comes in! poshformats.org is intended to be a counterpart to microformats.org. It borrows many of the Microformats community's principles: * use of plain old semantic HTML; * community development via mail, IRC and Wiki; * public domain requirement but it is intended to be appropriate for small groups, solo projects and rapid development. This is NOT intended to split the Microformats community. I anticipate a large overlap between users of microformats.org and poshformats.org. Rather it is intended as a development area for people to be able to work on ideas not appropriate for microformats.org without them being branded as it must be an official microformat because it's on microformats.org. I invite people from the Microformats Community to visit poshformats.org, and if they like the idea, sign up to the Wiki and mailing list. There's also a logged #poshformats channel on irc.freenode.net, and a project on Google Code for sharing posh-related code. I'm also invite people to volunteer to become an administrator. Administrators should have experience implementing solutions with microformats and semantic HTML. To volunteer, sign up to the Wiki and add the following to your user page: [[Category:Administrator_Volunteer]] (without the quotes). Thanks for reading. -- Toby Inkster m...@tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Next/Prev [was Rationale for providing hAtom instead of Atom/RSS feeds]
Two example pages: html titlePage 1/title link rel=next rev=prev href=page-2 body div class=hentry h1 class=entry-titleEntry 1/h1 p class=entry-contentContent./p /div /body /html html titlePage 2/title link rel=prev rev=next href=page-1 body div class=hentry h1 class=entry-titleEntry 2/h1 p class=entry-contentContent./p /div /body /html As I understand the semantics of next/prev, they indicate links to separate resources - not a continuation of the current resource. i.e. These pages represent two separate feeds, each of which contains a single entry. The reason some XFN parsers will recurse to rel=me next and rel=me prev links is not the next/prev relations, but rel=me -- they can spider rel=me links (presumably constrained to a particular depth limit) and consolidate the information into a single unified profile. -Toby ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: One more shot at accessible hCalendar
Charles Belov wrote: Remember that any page these occur on would presumably have a language specification such as en-us so computers would be able to deal with standard month and day of week names and abbreviations. I'm sorry, but this sounds like a really bad idea. Parsers would need to maintain translation tables for day and month names, plus abbreviations for them, plus some sort of heuristic for figuring out the language of the page. (In practice, many authors leave out lang/xml:lang attributes, and Content-Language headers.) Andy Mabbett's proposed data: prefix already solves the abbr design pattern accessibility issue and can be implemented in just a few lines of code. All we need to do is build support for it into parsers. (Cognition has supported it since alpha2.1.) Closest thing to a specification for the prefix: http://microformats.org/discuss/mail/microformats-discuss/2008-February/011583.html -- Toby Inkster mailto:[EMAIL PROTECTED] http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] hCard label type
The vCard spec allows types (e.g. home, postal, etc) to be specified for the LABEL property, but the hCard spec doesn't seem to allow this. The hCard examples page on the wiki (RFC 2426 examples) does include a label marked up with type+value, but that page is not considered normative. Is this an oversight in the spec, or was a conscious decision made not to allow types to be specified within labels? If the latter, what was the reasoning? Do any current parsers extend hCard and allow a type to be specified for labels? (I'm considering adding this feature to Cognition.) -- Toby Inkster mailto:[EMAIL PROTECTED] http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] a[name] as machine data?
Better than a[name] would be a[href], assuming a relevent URI scheme exists: a href=geo:51.36,-0.05London, abbr title=United KingomUK/abbr/a (See: http://geouri.org/) Disadvantages would be: 1. Involves using a poorly supported URI scheme. People using browsers that don't support the scheme would get a link that doesn't do anything, or brings up a cryptic message. (This could be worked around with a combination of CSS and Javascript, but that seems a bit hackish to me.) 2. This requires there to always *be* such a URI scheme. There isn't a URI scheme for timestamps for instance. URI schemes cannot be quickly and easily registered. -Toby ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
