Re: [uf-discuss] Microformat inside Atom?
On 8 Jul 2009, at 08:18, Álvaro Ortiz wrote: Our API is going to be Atom, but we have questions regarding how to include hReview in it; we didn't find anything in the Microformats wiki The normal way would be to simply embed it into a content type=xhtml element. I don't think there are very many microformat parsers that will read feeds and check content for microformats though. The latest version of Swignition does, but it's not a thoroughly tested feature. As an alternative, you could consider using RSS 1.0 (instead of Atom) which uses RDF for extensibility. This is because there's already a review vocabulary for RDF which is fairly widely used, and strongly influenced by the design of hReview. An example - http://xml.pastebin.com/d6807e48a -- 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] mixing vocabularies
On 25 Jun 2009, at 02:55, Peter Mika wrote: class=infobox infobox vcard vevent Related wiki page: http://microformats.org/wiki/compositing -- 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] hRecipe in RDF
On 17 Jun 2009, at 15:42, Thomas Loertsch wrote: I'm not quite sure if I will continue to work on a mapping of *all* microformats to a RDF vocabulary since that's a lot of work. Seen http://poshrdf.org/ns/mf# ? -- 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] hcalendar - irregular repeat of identical meeting.
Michael MD wrote: Does much software actually implement this kind of thing in the iCal world? Outlook certainly does - I've seen RDATEs and EXDATEs in the iCalendar files it produces. Lotus Notes does too. Apple iCal doesn't seem to. Google Calendar apparently does, but only if all the recurrences have the same duration. In terms of hCalendar software, X2V seems to support them, as does Swignition. Not tested any others. -- 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] hcalendar - irregular repeat of identical meeting.
Try iCalendar's RDATE property. div class=vevent h1 class=summaryMy Irregular Meeting/h1 div bDates:/b span class=dtstart2001-01-01/span span class=rdate2003-01-01/span span class=rdate2003-01-02/span span class=rdate2004-05-12/span span class=rdate2004-07-30/span span class=rdate2009-02-01/span span class=rdate2011-02-01/span span class=rdate2011-02-04/span /div /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
[uf-discuss] Is this illegal? 1) dtends for yyyy or yyyy-mm. 2) Wikipedia vevents for birth and death.
JMesserly wrote: 1) On wikipedia, we have lots of dates where only years or months are specified Eg. the ancient Korean kingdom in this article http://en.wikipedia.org/wiki/Gojoseon the last year of existence was 108BC. The precision is year units so judging from the examples for whole days from the microformats book Brian edited, as well as in the hcalendar, iCalendar (RFC2445) documents, the dtend for this date should be -0107. Similarly, if the battle end date is given as August, 1843 then the dtend should be 1843-09, and if the article says battle end date is August 19, 1843, then the dtend should be 1843-08-20. Correct? Looks OK to me. You should be aware that many parsers will not have been tested with dates prior to 1 AD. If they're using decent ISO 8601 parsing libraries, they should probably be OK, but if they've written their own parser for dates, they may not be safe. My own parser http://buzzword.org.uk/swignition/ mostly deals with such dates OK. The following fragment is parsed correctly for instance: div class=vevent span class=summaryThe death of Julius Caesar/span occurred on abbr class=dtstart title=-0043-03-15the Ides of March, 44BC/ abbr. /div 2) hCalendar usage for death dates. Consider article Ceasar Augustus: http://en.wikipedia.org/wiki/User:J_JMesserly/demo1. We are aware of proposals for dday (death day) addition to hCard. Some feel vEvent is perfectly suited to Life events. My question: Is the usage of vevent, dtstart and dtend in this example in any way officially deprecated or ruled improper? hCard officially has no way of marking up dates of death. hCard's properties are entirely taken from vCard 3.0. The IETF is currently drawing up drafts for vCard 4.0 - it looks like this next version of vCard will contain a property 'DDAY' for date of death. Whether hCard is ever updated to use the new vCard standard is another question though. However in my parser I support the proposed new vCard 4.0 properties (which also include 'BIRTH' and 'DEATH' for marking up the places of birth and death) as an hCard extension. Until that time, hCalendar is the only official way of marking up dates of death using Microformats. Looking at your example, it does seem a little odd to mark up Augustus' entire life as a single hCalendar event with a start and end date. Not strictly wrong, but unusual. A better way would be to mark up his birth and death as separate events - this has the advantage that you can mark up the locations of birth and death, and even categorise the events as murder, suicide, accidental, 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
[uf-discuss] Rel-Canonical
Brian Suda wrote: Google has started to use rel-canonical to specific the best URL for page information. It is a shame they don't seem to have openly discussed this idea before implementing it. If they had, people may have pointed out that it more or less duplicates the semantics of the existing Content- Location header from HTTP 1.1. Content-Location is already a fairly commonly used header, and although HTTP headers can sometimes require a bit of voodoo to configure, meta http-equiv is available as a substitute. -- 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] Microformat for programming language reference?
Have you considered just using a simple table?
table
thead
tr
th scope=colConcept/th
th scope=colPHP/th
th scope=colPerl/th
!-- etc, etc --
/tr
/thead
tbody
tr
th scope=rowRegular expression match/th
tdcodepreg_match('/expression/', $string, $matches)/code/td
tdcode$string =~ /expression//code (matches in $1, $2, etc)
/td
/tr
tr
th scope=rowRegular expression replace/th
tdcode$string = preg_match('/expression/', $replacement,
$string)/code/td
tdcode$string =~ s/expression/replacement/;/code/td
/tr
!-- etc, etc --
/tbody
/table
Maybe with some class attributes on the code elements.
--
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] title - heading/label/caption/?
Kevin Marks wrote: 'label' is used in hCard for unstructured addresses. could you re-use 'entry-title' from hAtom? entry-title was my suggestion a while back (see http:// microformats.org/discuss/mail/microformats-new/2008-April/ 001600.html) but some people pointed out that it might be problematic for people who want to produce an hAtom feed of recipes without using the same titles for the recipes and entries. -- 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] MediaWiki hResume templates
It is my interpretation of the hResume draft spec (though it's not very clear) that the contact hCard needs to be an address element (you have a table element). While class=contact is good POSH for it, but the hResume format itself doesn't define any meaning for class=contact, so using address is the only sure fire way of indicating the contact address for the hResume. If you take a look at the hResume field details http://microformats.org/wiki/ hresume#Field_details, then you'll see that unlike summary, education, experience, skill and affiliation, contact is not defined as a class name. See also: http://microformats.org/wiki/hresume#Contact Frankly, this is an area where I think hResume could do with improvement: although address is a perfect fit for this information semantically, structurally it leaves a lot to be desired. The way address is defined in the HTML spec doesn't allow it to contain block elements (e.g. div, p) or tables. Thus allowing an alternative element for the contact info (e.g. div class=contact, table class=contact) would be handy. -- 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
hResume address issue (was Re: [uf-discuss] MediaWiki hResume templates)
Tantek wrote: Could you add your specific documentation of this hResume issue to the hResume issues page? http://microformats.org/wiki/hresume-issues It's already on there (last item) - added by Steve Ganz in 2006. Which reminds me... linkedin.com has recently started to do really annoying things with their hCard titles. :-( -- 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] MediaWiki plugin
Ben Ward wrote: Critically, it doesn't add anything to logging in or editing pages, so your regular workflows should be unaffected. It does seem to come up when editing pages - at least when adding/ changing external links. -- 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] A suggestion to address date accessibility issues
Jeremie, something along those lines has been proposed before. See: http://microformats.org/wiki/datetime-design- pattern#strtime_instructions_as_class_names There are some problems noted there, which I think would have to be overcome before people would consider something like this. -- 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] using rel to point to remote meta-data resource for a url identified resource
Adrian Skardhamar wrote: img src=http://someurl/photo_of_cow.jpg; rel=http://someurl/meta_data_about_photo_of_cow; Firstly, the rel attribute does not normally hold a URI. Although placing a target URI in there is syntactically allowed, it is semantically incorrect - the rel attribute is designed for indicating the nature of a relationship, not the object of a relationship. Secondly, the rel attribute is not valid on img using the usual HTML 4 and XHTML 1.x doctypes, nor is it valid in HTML5. The only published standard (that I'm aware of) that allows rel on img is RDFa. Which brings me to the point that this is re-inventing something that RDFa can already deal with very easily: img src=photo_of_cow.jpeg rel=meta resource=metadata_about_photo_of_cow / This is already supported by many existing tools. -- 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] What do I do when I have images with different licenses on a single page?
Jorel Pi wrote: If I had a page with 2 images, each having a different license. What am I supposed to do? This is a known problem with rel=license, and the reason why rel=license has been (at least for now) removed as a component of the current hAudio, figure and hRecipe drafts. In general, the scoping of properties is an area where microformats have always been murky. I was thinking of just using span with the name of the license as the class. This is perfectly good POSH, but obviously no parsers will pay any attention to it. If you're looking for something which will be machine readable, then you probably want RDFa. RDFa has very clear scoping rules. An example might be: img src=foo.jpeg alt=A Foo p span about=foo.jpeg The image above is licensed under a rel=:license href=foo.htmlFoo licence/a. /span span about=bar.jpeg The image below is licensed under a rel=:license href=bar.htmlBar licence/a. /span /p img src=bar.jpeg alt=A Bar The colons in the rel values are not actually needed, but they have the effect of masking the rel=license from non-RDFa processors. Note that the about attribute is RDFa-specific, so if you want your page to validate, you'll need to use the RDFa doctype, which is: !DOCTYPE html PUBLIC -//W3C//DTD XHTML+RDFa 1.0//EN http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd; -- 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] hatom tumblr theme
James Tindall: Incidentally however, this vcard validator now complains that uid should not appear twice on a page with the same value? http://hcard.geekhood.net/?url=microformats.tumblr.com There is no prohibition on reusing UIDs in the hCard spec, but hcard.geekhood.net goes far beyond the spec with regards to suggesting best practices and things you might have missed. In general, I think it's a good tool, but in this case I (personally) disagree with it. If Joe has an hCard for himself on his index.html and another hCard for himself on his contact-me.html, then nobody would think twice about giving them both the same UID. So if two hCards on different pages can have the same UID, then why not two hCards on the same page? What is important (and again this is just my opinion) is that if two hCards do have the same UID (whether they're on different pages or the same page), then they should be referring to the same contact (person, organisation, place, whatever). To back up my argument, I'll cite the vCard spec (RFC 2426) which defines the purpose of UID as: To specify a value that represents a globally unique identifier corresponding to the individual or resource associated with the vCard. That is, the UID is a unique identifier for the contact, not a unique identifier for the card. I've contacted Kornel about this warning message and suggested that he change it so that the warning is only issued if two hCards have the same UID but different FNs. As an aside, I'll point out that I do *not* recommend using the same UID for the historic hCards in a resume, because in that situation, merging details is not the desired behaviour - you want them to be kept separate. -- 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] hatom tumblr theme
Me too! http://srv.buzzword.org.uk/atom/microformats.tumblr.com/ http://srv.buzzword.org.uk/icalendar/microformats.tumblr.com/ http://srv.buzzword.org.uk/vcard/microformats.tumblr.com/ Note that the vCard output contains many different James Tindalls. If you gave all your hCards the same uid it would (using the most technical language possible...) glue them together and the vCard output would just contain one contact. -- 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] hCalendar-Recurring Events Help
iCalendar does include support for recurring events such as this. hCalendar is, according to its spec, a 1:1 representation of [...] iCalendar. Thus is can be assumed that it does include support for recurring events, even if the spec is silent on exactly how to mark them up. Because of the fact that hCalendar is so vague about how a number of iCalendar properties should be expressed in HTML, I've put together a completely unofficial, but hopefully helpful draft called hCalendar 1.1, which you can find here: http://microformats.org/wiki/User:TobyInk/hcalendar-1.1 Now, in iCalendar, the way to express a recurrence of the first and third Friday of every month would be: RRULE:FREQ=MONTHLY;INTERVAL=1;BYDAY=1FR,3FR The hCalendar draft allows two basic ways of marking this up. The first is a clumsy, all-in-one way, but is probably the best supported: abbr title=FREQ=MONTHLY;INTERVAL=1;BYDAY=1FR,3FR class=rrulethe first and third Friday of every month/abbr. A slightly nicer way, though one which you'll find less parser support for would be: p class=rrule On the abbr class=byday title=1FRfirst/a and abbr class=byday title=3FRthird friday/a abbr class=interval title=1of every/abbr abbr class=freq title=monthlymonth/abbr. /p Both of these markup styles are supported by Cognition http:// buzzword.org.uk/cognition/. Perhaps other parser maintainers could reply to this thread to say whether they support either/both. Note that with RRULE you do still need to include a DTSTART (use this to indicate the start date and time of the first event in the sequence) and I'd recommend also including either a DURATION (i.e. the duration of each event) or a DTEND (i.e. the end time of the first event - not the date when you want the recurrence rule to finish). RRULE is a singular property - that is, you can only have one recurrence rule per event, but these rules can get pretty complicated, so do manage to cover the vast majority of cases. Also of interest are RDATE, which allows you to list explicit dates when an event is repeated, and EXDATE and EXRULE which are their counterparts for excluding particular dates. Hope that helps. -- 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
[uf-discuss] hFoaF - Hypertext Friend of a Friend
Martin McEvoy wrote: a rev=made href=http://someapp.com/;I made this app/a would translate as http://referencingpage.com/ made http://someapp.com/ much better! No, it really is the other way around! Take a look at the HTML 3.2 recommendation — it's the closest thing there is to a spec defining what is meant by 'made'. The section on anchors http://www.w3.org/TR/REC-html32#anchor states that REV=made is sometimes used to identify the document author, either the author's email address with a mailto URL, or a link to the author's home page. That is, rev=made is used to link from a page to its author, thus rel=made is used to link from an author to a page they made. rel=author/rev=made links from page to author. rev=author/rel=made links from author to page. The way you're interpreting it is as made by which is a perfectly natural and sensible interpretation, but wrong according to the specification of the term, and how it's used in the wild. This is a good illustration of why verbs are a bad idea as link types - nouns or adjectives work better. -- 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
[uf-discuss] hFoaF - Hypertext Friend of a Friend
This (on this-page): a href=that-page rev=made vote-forthat page/a means: that-page made this-page that-page is voted for by this-page And this: a href=that-page rel=made vote-forthat page/a means: this-page made that-page this-page is voted for by that-page VoteLinks is not a good analogy to use for clarifying something in your head though. The definitions of the terms were all confusing from the beginning, and a later attempt to fix them just ended up muddying everything even more. Personally, I have never implemented or used VoteLinks and have no plans to do so in the future. If VoteLinks had been left as originally defined, they might have been slightly more reliable. A better way of clarifying it in your head is to consider that 'made' is the inverse of 'author'. If X made Y, then Y has author X. 'rel=author' is defined in HTML5[1] so that it links from a page to its author; so if 'rel=made' is the inverse, then logically it links from author to page. 1. http://www.whatwg.org/specs/web-apps/current-work/multipage/ structured-client-side-storage.html#link-type-author -- 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
[uf-discuss] hFoaF - Hypertext Friend of a Friend
Good work, Martin. As I am rubbish at XSLT, these few notes are mainly from a FOAF perspective: 1. RDF (and thus FOAF, which is an application of RDF) uses URIs to identify virtually everything. (There are exceptions: literals and blank nodes.) What is important for RDF to work is that each distinct resource (i.e. thing) has a distinct URI. No two resources can share a URI - syntactically there is nothing to prevent them sharing, but semantically it doesn't work - things fall apart when you start feeding your data into any sort of reasoning system. hFoaF, when dealing with XFN input creates RDF triples[1] like this: #alice xfn:met http://bob.example.com/ . http://bob.example.com/ foaf:homepage http://bob.example.com/ . Here you are clearly using the same URI to represent both Bob and Bob's web page. What if we added say, a creation date for http:// bob.example.com/? Would that mean that Bob was born on that date? Or perhaps it was the day he first uploaded some HTML to his server? The easy solution is to use the URI to represent Bob's web page only and then choose a different URI for Bob. Choosing a different URI for Bob is pretty easy to do - simply give his web page a prefix or suffix. e.g. you could create these triples: #alice xfn:met x-person:http://bob.example.com/ . x-person:http://bob.example.com/ foaf:homepage http://bob.example.com/ . Where x-person: is a randomly made-up, unregistered URI scheme. Using an unregistered, made-up URI scheme is obviously suboptimal though, so if you wanted to get very fancy, you could use Google's (also unregistered, but at least not pulled out of thin air) sgn: URI scheme. SG Node Mapper[2] can be used to determine the sgn URI for a person from their web page's URI, but it may be tricky to use it in XSLT. 2. You seem to have rel=author and rev=made back to front. They are not for linking to stuff which you've authored/made; they are for linking *from* stuff that you've authored *to* you! If you want to link from *you* to stuff that you've authored, use rev=author or rel=made. 3. In your example output, your foaf:name is MartinMcEvoy (no space). Footnotes: 1. Using Turtle notation: http://www.dajobe.org/2004/01/turtle/ 2. Google Social Graph Node Mapper: http://code.google.com/p/google-sgnodemapper/ -- 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
[uf-discuss] Nifty little hCalendar trick
I needed to send details of a meeting to a few people, so I thought, what's a quick, easy way of doing that? hCalendar is obviously an easy way to type up the details, and iCalendar is good for people to be able to add it to their calendars. So what I needed was an easy way to publish an event in hCalendar and a way for people to add that to their calendar software without downloading a microformat parser. Introducing Cognition + pastebin! Type up the hCalendar: http://pastebin.com/m57fe450e (Yes, you need the surrounding html.../html tags right now. I'm working on a fix.) And instant iCalendar! http://srv.buzzword.org.uk/icalendar/PB:m57fe450e E-mail the latter URL to everyone, and they can add the event to their calendars with one click! (PB: is a little macro I've made which expands to http:// pastebin.com/pastebin.php?dl=. It is case-sensitive.) -- 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
[uf-discuss] Re: Nifty little hCalendar trick
On 1 Dec 2008, at 13:04, Toby A Inkster wrote: Type up the hCalendar: http://pastebin.com/m57fe450e (Yes, you need the surrounding html.../html tags right now. I'm working on a fix.) OK, the reason for this is that Cognition (in the first instance) will attempt to parse a page as XHTML. Of course, in XHTML, no elements can have their start or end tags omitted - i.e. html and body cannot be omitted - thus if your snippet starts with div, then div is the root element. Also, in XHTML, there is no class attribute on the root element. Put these together, and you get: if the snippet it parsed as if it were an XHTML document, the class attribute on the root element is ignored. Solution: make sure that Cognition doesn't parse the snippet as XHTML, but as HTML instead. How? Easiest way is to leave out an optional end tag. http://pastebin.com/m12ebc0e8 Converts to: http://srv.buzzword.org.uk/icalendar/PB:m12ebc0e8 Nifty, nifty! -- 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
[uf-discuss] hCard slowing adoption of microformats?
People might be interested in the FOAF+SSL discussions happening on the foaf-protocols mailing list at http://lists.foaf-project.org. The basic idea is to have a public profile and a private profile; the public profile contains a link to the private profile, which resides on an HTTPS server; access to the private profile is granted only after authentication using an SSL client certificate; the client certificate itself contains a link to the client's public profile; data in the client's public profile can be used by the server to determine access rights to the server private profile. The FOAF part of the name comes from the client's public profile, which needs to be written in RDF using FOAF+extensions. This doesn't necessarily mean RDF/XML - RDFa could be used, or hCard+GRDDL. If this is something that makes you think awesome!, then sign up to the foaf-protocols mailing list. -- 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
[uf-discuss] Google Code microformat?
If you're talking about their use of class=ot-logmessage etc, then no, that isn't a Microformat[1]. It looks to me like the reason those particular classes are present in the project updates Atom feed is that the feed is generated by the same code that generates the project updates HTML file, where these classes seems to be mainly present as hooks for CSS and Javascript. If you're looking for a way to markup feeds, then use hAtom[2]. If you're looking for a way to markup software projects, then perhaps you should look at hDOAP[3]. 1. http://microformats.org/wiki/Category:Specifications http://microformats.org/wiki/Category:Draft_Specifications 2. http://microformats.org/wiki/hAtom 3. http://purl.org/stuff/hdoap/profile -- 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
[uf-discuss] rel=byme
Brian Suda wrote: James Tindall james at atomless.com wrote: I use the xfn rel=me to link from my personal site to sites that I maintain and that represent me in some way but is there a microformat I should use to link to a site I have built for a client? I can't seem to find a reference, but i remember a value called made from somewhere. It is not part of the core link types in HTML http://www.w3.org/TR/REC-html40/types.html#type-links It's in the HTML 3.2 spec. WHAT-WG has a few additional values for HTML5 http://www.whatwg.org/specs/web-apps/current-work/#linkTypes As does the XHTML 2.0 draft: http://www.w3.org/TR/xhtml2/mod- metaAttributes.html#adef_metaAttributes_rel Whatsmore, RDFa http://www.w3.org/TR/rdfa-syntax/ allows you to use terms from various non-W3C vocabularies such as Dublin Core (which has dc:creator and dc:contributor) and FOAF (which has foaf:made and foaf:maker). If you treat a website as being a project, then the Description of a Project (DOAP) vocabulary might be handy too, as it has doap:developer, doap:maintainer, doap:documenter, doap:translator, doap:tester and doap:helper. At http://buzzword.org.uk/cognition/ I use RDFa to indicate that the dc:creator, doap:maintainer, doap:developer, foaf:maker and doap:documenter of the project is me; that the dc:creator, author and foaf:maker of the page itself is me; and that I foaf:made and made both the project and the page. I also use the hCard microformat in conjunction with address to indicate that I am the contact person for the page. -- 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
[uf-discuss] clarification request on usage of id attributes in XMDP
Using @id is useful so that people can link to particular terms, but I think it would be unwise for any tool to rely on them (as the XMDP spec says that @id does not need to match the name of the term being defined - which is important, given that hCard profiles define both the 'class' attribute and a 'class' class). And if no tools are going to rely on them, then it shouldn't actually be harmful to leave them out. -- 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
[uf-discuss] mama
A query of classtag:xfolk should find documents where xfolk is used in a class somewhere in the document. ~D Though that doesn't tell you much, as the xFolk root class name is xfolkentry. ;-) Does it cope with multiple class names in one attribute, like class=contact vcard mine? -- 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
[uf-discuss] How about adding aRecipe, an RDFa serialization of hRecipe?
The way you do it also scarces me a little because I find it hard to judge how stable vocabularies like those of donnafales.com or holygoat.co.uk are. The former I don't know, but the latter is probably the most widely used RDF tagging vocab that there is - Richard Newman is very unlikely to make any incompatible changes to it. And what if there where two slightly different vocabularies for recipes that I both liked and that both had their merits? Which one would I chose and what would happen to the other one? Good luck finding another RDF recipe vocab with merit. Good luck finding another RDF recipe vocab at all! * define mappings from this vocabulary to other, existing vocabularies through OWL, eg hRecipe:title owl:equivalentClass dc:title The problem with this is that only tools that support OWL will realise that hRecipe:title is the item's title. This leaves the majority of simple RDF tools out in the cold. That makes things more memorable, and easier to identify e.g. when scanning source code. If you want to make the properties you're using for recipes more obvious, you could always use: xmlns:recipe=http://donnafales.com/2002/07/28/recipe-schema#; xmlns:recipeDC=http://purl.org/dc/terms/; xmlns:recipeTag=http://www.holygoat.co.uk/owl/redwood/0.1/tags/; h1 property=recipeDC:title.../h1 ... etc ... Anyway, this is probably becoming off-topic for uf-discuss. Perhaps we should shift over to the SWIG mailing list? -- 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
[uf-discuss] How about adding aRecipe, an RDFa serialization of hRecipe?
Hi Thomas, There is already a reasonably good RDF recipe schema: http://donnafales.com/2002/07/28/recipe-schema# If you want to map hRecipe to RDFa, then the best technique would be to use a combination of the schema above, plus Dublin Core (for authorship) and then create your own vocabulary only to fill in the gaps which the combination of the two more established vocabularies couldn't cover. That would be similar to what Manu has done for his RDFa mapping of hAudio. For what it's worth, I've already performed a mapping of hRecipe to RDF. (This is basically the way my parser, Cognition, works. All microformats are converted into RDF, and then RDF is converted to, for example, vCard or JSON or whatever. Thus, when I added support for hRecipe, I had to map it to RDF as part of that process.) The mapping I've used is: hrecipe = http://donnafales.com/2002/07/28/recipe-schema#Recipe recipe-title = http://purl.org/dc/terms/title recipe-summary = http://purl.org/dc/terms/abstract author = http://purl.org/dc/terms/creator published = http://purl.org/dc/terms/issued photo = http://purl.org/media#depiction ingredient = http://donnafales.com/2002/07/28/recipe-schema#ingredient method = http://donnafales.com/2002/07/28/recipe-schema#directions yield = http://donnafales.com/2002/07/28/recipe-schema#x-yield (Namespace squatting a bit here.) preparation-time = http://donnafales.com/2002/07/28/recipe-schema#x-preparation-time (Ditto.) category = http://www.holygoat.co.uk/owl/redwood/0.1/tags/taggedWithTag Within ingredients, I also map: quantity = http://buzzword.org.uk/rdf/measure#quantity item = http://www.w3.org/1999/02/22-rdf-syntax-ns#value note = http://purl.org/dc/terms/abstract optional = http://purl.org/dc/terms/abstract How might all this be used in RDFa? Well, here's an example: div xmlns:r=http://donnafales.com/2002/07/28/recipe-schema#; xmlns:dc=http://purl.org/dc/terms/; xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#; xmlns:m=http://buzzword.org.uk/measure#; typeof=r:Recipe h1 property=dc:titleMince and Dumplings/h1 div property=dc:creatorToby Inkster/div h2Ingredients/h2 h3For the mince/h3 ul rel=r:ingredient li typeof=r:Ingredient span property=m:quantity400 g/span span property=rdf:valueminced beed/span /li li typeof=r:Ingredient span property=m:quantity1/span span property=rdf:valuecarrot/span, span property=dc:abstractchopped/span /li li typeof=r:Ingredient span property=m:quantity1/span span property=rdf:valueonion/span, span property=dc:abstractchopped/span /li li typeof=r:Ingredient span property=m:quantity60 g/span span property=rdf:valuepeas/span, span property=dc:abstractshelled (frozen are OK)/span /li li typeof=r:Ingredient span property=m:quantity500 mL/span span property=rdf:valueale/span /li li typeof=r:Ingredient span property=m:quantity2 tbsp/span span property=rdf:valuetomato puree/span /li li typeof=r:Ingredient span property=rdf:valueworcestershire sauce/span span property=dc:abstractto taste/span /li li typeof=r:Ingredient span property=rdf:valuesage/span /li li typeof=r:Ingredient span property=rdf:valuebutter/span /li /ul h3For the dumplings/h3 ul rel=r:ingredient li typeof=r:Ingredient span property=m:quantity75 g/span span property=rdf:valueshredded suet/span /li li typeof=r:Ingredient span property=m:quantity150 g/span span property=rdf:valueself-raising flour/span /li /ul div property=r:directions ol liPreheat the oven to 190˚C./li liIn a casserole dish, fry the onion gently with a little butter./li liBrown the beef in the dish./li liMix in the other mince ingredients./li liBake for 45 minutes, covered./li liWhile the mince is baking, prepare a dough from the suet, flour and a little water./li liDivide the dough into eight balls./li liAfter the mince has been baking for 45 minutes, add the dumplings to the dish. They should float like icebergs, partly poking out of the mince./li liReturn to the oven for another 35 minutes - covered for 20 minutes and uncovered for the last 15./li /ol /div p span property=r:x-preparation-time Preparation: 10 minutes/span; span property=r:x-preparation-time Cooking: 90 minutes/span. /p /div -- 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
[uf-discuss] ISO Dates and Durations using Style
One problem with this idea is the difficulty of parsing. (I know that
as per microformats principles, the needs of implementors come third,
after the needs of users and the needs of publishers - but the needs
of implementors do still need to be taken into account!) It would
mean that all microformats tools would have to include a full CSS-
parsing ability. Otherwise they might pick up false positives from
things like:
span style=background:url(quot;http://example.com/-uf-
content:'2008'quot;)
(Yes, this is a contrived example!) And you may end up in a situation
where publishers start using the following and expecting it to work:
style type=text/css
#event1 .dtstart { -uf-content: '2008-01-01' }
/style
Then you end up with parsers needing to follow all rel=stylesheet
links, @import rules, etc.
--
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
[uf-discuss] ISO Dates and Durations using Style
Martin McEvoy wrote: No Tantek and Toby you are misguided in your interpretation please cite your sources ... http://www.w3.org/TR/REC-html40/present/styles.html#h-14.2.2 The syntax of the value of the style attribute is determined by the default style sheet language. http://www.w3.org/TR/REC-html40/present/styles.html#h-14.2.1 User agents should determine the default style sheet language for a document according to the following steps (highest to lowest priority): 1. If any META declarations specify the Content-Style-Type, the last one in the character stream determines the default style sheet language. 2. Otherwise, if any HTTP headers specify the Content-Style-Type, the last one in the character stream determines the default style sheet language. 3. Otherwise, the default style sheet language is text/css. HTTP headers and meta http-equiv are document-wide in scope, which means that you can only change the default style sheet language on a document-wide basis. this is a valid solution. It is certainly valid in an SGML sense. And it does conform to the HTML spec *if* you set the Content-Style-Type header. However, if you do so, then any use of CSS in style attributes becomes non-conformant. The ability to use CSS in style attributes being very handy, I don't think this is a very good solution. -- 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
[uf-discuss] ISO Dates and Durations using Style
Benjamin Hawkes-Lewis wrote: It will cause problems if browser developers ever implement W3C's proposals. Opera implemented support for CSS's content property on real elements (as against pseudo-elements) a very long time ago (Opera 5 or 6 IIRC) but dropped it later on. -- 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
[uf-discuss] gender
Jonas wrote: I prefer use it as it is indicated in the vCard 4.0 draft [1]. In addition there are another new properties which I am interested as LANG, IMPP or KIND. http://tools.ietf.org/html/draft-resnick-vcarddav-vcardrev-01 Latest version of the vCard 4.0 draft is here: http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-03 There is nothing to stop you using these in hCards, but you should be aware that most parsers will ignore them - just as they'd ignore class=foobar or class=xyzzy - they'd be assumed to be non-hCard classes added for presenational or other reasons. Cognition does support these vCard 4.0 properties as an experimental extension (and various others - for instance, CALURI is cool), and although hCard is officially based on vCard 3.0 it seems very likely that if ever a new version of hCard were to be decided upon, new classes would be chosen to be compatible with new versions of vCard. In the mean time you can always combine them with other (existing) hCard classes to get the best of both worlds. e.g. span class=category genderMale/span span class=category kindindividual/span a class=impp url href=xmpp:[EMAIL PROTECTED] jab me/a -- 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
[uf-discuss] ISO Dates and Durations using Style
If any style sheet language can be used, why don't microformats create their own style language eg: span class=bday style=bday.1968-01-044th Jan, 1968/span By definition, the contents of the style attribute must be in the default style sheet language. The default style sheet language is by definition CSS unless a Content-Style-Type header (either HTTP header or meta http-equiv) is present. There can only be one default style sheet language per document, thus any document which wants to use a non-CSS style sheet language in the style attribute cannot use CSS in the style attribute. (That is, you can't use CSS in some style attributes and non-CSS on others.) -- 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
[uf-discuss] Indicate order of sub-properties
In some cultures (e.g. China), full names are written in family-name given-name order, whereas in others (e.g. Western Europe), given-name family-name is used. So you might think it would be nice if we had a way to indicate the order of properties within n, but in actual fact, we don't need it - fn provides us with the name with all its parts in the correct order. Similarly, label provides a fully-formatted address, with all its components in the right order. -- 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
[uf-discuss] hRecipe - one suggestion, a lot of comments
Thomas Loertsch wrote:
as I already posted here we're planning to implement hRecipe at
essen
trinken [1]. I think hRecipe is in quite a good shape already.
Cognition
[2] has recently included experimental support for the proposed
hRecipe
microformat (though the document [3] is a bit vague about what
exactly they
make required and optional respectively).
I've put together slightly better documentation of Cognition's
support for it here:
http://buzzword.org.uk/cognition/uf-plus.html#hrecipe
* Suggestion: idle period / off-time / rest period / unattended time
Perhaps preparation-time could be made into a plural type+value
property (like tel in hCard).
span class=preparation-time
span class=typePreparation/span:
abbr class=value title=PT5M10 mins/abbr
/span
span class=preparation-time
span class=typeWaiting/span:
abbr class=value title=PT25M25 mins/abbr
/span
span class=preparation-time
span class=typeCooking/span:
abbr class=value title=PT35M35 mins/abbr
/span
TobyInk proposes an optimization for Ingredient which makes sense,
but...
first I wonder how much harder the optimization makes it to develop
parsers.
It's very little effort to implement, but saves a lot of typing when
publishing recipes, especially when there are a lot of ingredients.
Implementation is easy by just performing a tiny pre-processing step.
(Code below in Javascript, assumes that the hRecipe root element is
hroot. Should be very easy to port to other DOM-compatible languages.)
var nodes = hroot.getElementsByClassName('ingredients');
for (var i=0; nodes[i]; i++)
{
var kids = nodes[i].getChildrenByTagName('*');
for (var j=0; kids[j]; j++)
{ kids[j].className += ingredient; }
}
Pretty easy. And if you think it's a bit messy to change the DOM tree
prior to parsing, you should realise that most parsers make a lot of
DOM changes prior to the proper parsing stage in order to implement
the include pattern.
--
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
[uf-discuss] Suggestion for Birthday
With Microformats, dates are in ISO 8601 format. ISO 8601 already allows for years without months or days. e.g. span class=bday1980/span And indeed with years and months, but no days: span class=bday1980-06/span Most microformat parsers already support these, so no need to go inventing some non-ISO format. ISO 8601 also offers a way of specifying months and days without a year: span class=bday--06-01/span Though this doesn't have such wide support. -- 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
[uf-discuss] ignoring minimal hCards
Karsten Januszewski wrote: Right now, I'm working on both a parser and an application. What if my application were to ignore Microformats that may be to spec but weren't interesting enough for my application's purpose? Yes, a subjective decision, but I'm wondering what the community would think of such a decision. That sounds fine to me. If you've got an application that is designed to, say, add people's portraits to a photo management tool, then ignoring hCards which don't have a photo property would seem to be a good move. If your app takes contact details from a web page to transfer to a phone via bluetooth, it is probably sensible to skip hCards that don't contain a phone number. Microformats are about marking up the information on the page - not compelling parsers to do anything in particular with it. -- 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
[uf-discuss] URL and Relative paths
Karsten Januszewski wrote: Is this considered bad form? Or is this to spec? I didn't see anything on the wiki about this... That which is not forbidden is mandatory. (Attributed to Murray Gell-Mann.) There's a whole bunch of weird code out there that people expect to be parsed. If it's not forbidden by the spec, then you've just got to roll up your sleeves and parse it. -- 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
[uf-discuss] NetNewsWire ditches support for microformats
Next downloadable version of Cognition (downloadable as against the web service) will include four plugins for NNW which do the following: hCard -- Address Book hCalendar -- iCal hAudio-- iTunes (all) -- RDF/XML in default text editor This uses NNW's scripting facility, so it sadly can't include any GUI icons to indicate the presence of any such data in the feed. (A custom NNW stylesheet could be used to indicate the presence of microformats though. Anyone want to design one?) -- 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
Draft to Specification (was: [uf-discuss] More than three years)
Yay! Finally the sort of discussion I was hoping to kick-start. I think 'adr' and 'geo' should certainly be considered candidates for promoting from drafts to specs - these have been stable for ages and don't seem to have any issues raised (at least none which don't effect hCard, or microformats in general). There have been plenty of ideas proposed for extensions to them, but the current drafts certainly address 80% of use cases. These can be deferred to a future iteration which would address 80% of the remaining 20% of use cases. (This would also address the anomaly that hCalendar, a full specification, recommends that event locations may be marked up with adr and geo, each of which are only drafts.) And hAudio and figure are probably stable enough to go on the official drafts list. The Microformats process is extremely helpful in the early stages of drafting a spec, taking the authors/editors through the process of researching relevant examples, looking at existing standards, narrowing down requirements to a simple, usable and deliverable set, and building a draft vocabulary; but after that, the process leaves you dangling: there is no defined process for knowing when to freeze a spec, when to start asking for implementations, creating test suites, publishing as a formal spec once you've got a few implementations that pass the tests, restarting the effort for a v1.1 iteration, etc. [That was a very long sentence. I apologise to readers: my writing style tends to favour run-ons.] The process itself should be considered a product of the microformats community; but the process does not yet cover 80% of use cases, so needs more work. -- 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
[uf-discuss] More than three years
Compare and contrast: http://microformats.org/wiki?title=Main_Pageoldid=251 http://microformats.org/wiki/Main_Page#Specifications The only difference between these lists are XFN and XMDP, both of which were adopted from outside the community. -- 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
[uf-discuss] hcard: born and died and flourished
And I've decided to use class=dday for date of death and class='flourished-start' and class='flourished-end' for flourished dates Where either date is circa I've included ca. in the span with bday, dday, flourished-start or flourished-end: span class=bdayca. 1575/span-span class=ddayca. 1614/span Does this look /feel right or am I missing something obvious? Is there established POSH for death date and flourished dates? I've previously recommended using 'dday' for date of death. DDAY is the name of the property in the draft vCard 4.0 spec, so it seems likely that any future extension of hCard that does include a date of death will name the property 'dday'. 'dday' is already supported in Cognition http://buzzword.org.uk/ cognition/. I imagine that your use of 'ca.' in dates will cause problems for some parsers, which expect to find an ISO 8601 date these - it certainly breaks in Cognition. You may be able to improve parser behaviour by using value excerpting: span class=bday span class=approxca./span span class=value1575/span /span -- 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
[uf-discuss] Cognition 0.1-alpha12 out today!
Cognition 0.1-alpha12 is out now (maybe I'll move into betas one of these days). A full change log is available at the Cognition website http://buzzword.org.uk/cognition/ where you can download the latest version or try it online. A summary of the changes for this version: * Lots and lots of bugfixes, in particular handling parsing edge cases for RDFa and nested microformats. * Turtle output. * M3U output. * Full parsing of durations and time intervals - not just treated as plain old strings. This includes experimental support for parsing non- ISO-8601 durations and intervals, as outlined at http:// buzzword.org.uk/cognition/uf-plus.html -- 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
[uf-discuss] [off-list] Cognition 0.1-alpha12 out today!
This is great I tried it on http://weborganics.co.uk/haudio-rss/ worked perfectly thanks (you saved me a job). Excellent. And if you include machine readable durations, in any of the four formats outlined at http://buzzword.org.uk/cognition/uf- plus.html#durations, those will be included in the M3U file as well. In some future version I'm hoping to include an export module for some sort of podcast format (i.e. RSS or Atom). The problem I'm struggling with is what to do when people overlay hAtom and hAudio. If hAudio is output as Atom and hAtom is output as Atom, then when the page as a whole is output as hAtom, then each song will end up having two entries in the feed. :-( I'll come up with something eventually I'm sure. -- 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
[uf-discuss] NetNewsWire ditches support for microformats
I've been using NNW since January and don't think I've ever used the microformat icons in it, so I can't say I'm bothered that it's gone. In 95% of cases, you could probably just open the article link in your browser and find the microformat there anyway. I do notice that NNW can call external applescripts. I don't know much applescript, but I imagine that it would only take a dozen lines or so to connect to a Cognition daemon running on a local TCP port and do something useful. :-) but removing it? ... how about giving the users a choice of whether to use this feature? As I understand it the motivation to remove it was not a matter of UI clutter, but to cut out chunks of source code, speeding the application up, slimming it down and removing dependance on a rather ugly API. Making it an optional feature thus wouldn't achieve the objectives. -- 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
[uf-discuss] hcard: additional additional names
But some detach: Beethoven, Ludwig van span class=fn n span class=given-nameLudwig/span span class=family-name van span class=sort-stringBeethoven/span /span /span -- 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
[uf-discuss] hcard: additional additional names
But as I said earlier on listing pages it should be Beethoven, Ludwig van Not especially pretty, but: span id=b class=sort-stringBeethoven/span, span class=fn n span class=given-nameLudwig/span span class=family-name van a href=#b class=hidden include/a /span /span -- 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
[uf-discuss] hcard: additional additional names
Eeeuuurrgg! Well, I did warn that it was not pretty. The sort of hCard that might be found at goatse.cx perhaps. Using my own suggested alternative to the include pattern, it would be: span id=b class=sort-stringBeethoven/span, span class=fn n span class=given-nameLudwig/span span class=family-name #bvan /span /span http://microformats.org/wiki/include-pattern-strawman#Non- Verbose_Class-Based_Solution -- 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
[uf-discuss] Audio/Video RDF Vocabulary Screencasts
For those who are interested, here are two copies of a page, one marked up with hAudio and the other with Audio RDF: http://buzzword.org.uk/2008/audio/ -- 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
[uf-discuss] Cognition 0.1 alpha11 released!
Summary: added support for hAudio, hResume, species, hmeasure and XEN; improved parsing, especially datetime; more experimental features for hCard. URL: http://buzzword.org.uk/cognition/ Details: Previous releases have included a lot of repetitive code for microformat parsing. This release includes a new centralised function which takes care of 95% of microformat parsing. It means that I can make improvements to one single function which will then benefit parsing for all microformats. Two improvements I've already made are: * Improved datetime parsing, including support for HTML 5's time element; and * Better handling for nested microformats. For example, whereas previously Cognition would only parse an agent hCard if the class names agent and vcard were found on the same element, it is now able to cope with the vcard element being nested *inside* the agent element. I've implemented support for the current hAudio draft http:// microformats.org/wiki/haudio. This information may be output as RDF, and in future versions I expect to be able to output it as a podcast in RSS or Atom. I've also implemented support for the most recent draft of hResume http://microformats.org/wiki/hresume. Output is in RDF, using the DOAC (Description of a Career) vocab. I've implemented support for the current species draft http:// microformats.org/wiki/species-strawman-01, in a manner broadly compatible with the existing user script for Operator. This information may be output as RDF, and (using extensions) hCard and iCalendar. Details of the support have been documented http:// buzzword.org.uk/cognition/uf-plus.html#species. Implemented support for the latest hmeasure http://microformats.org/ wiki/measure draft, treating units as opaque strings. Although it was intended as a joke, I've implemented XEN, the XHTML Enemies Protocol http://xen.adactio.com/. To use it, you MUST include the profile URI. Lastly, I've continued extending Cognition's support for hCard to include support for new vCard 4.0 (draft) properties. In this revision, this has included changing lang from a singular property to a plural property, and adding support for the member property, which may take a URL or an embedded hCard. e.g. div class=vcard pMembers of the a href=http://microformats.org; class=fn org urlMicroformats Community/a include:/p ul li class=member vcard a class=url fn href=http://tantek.com;Tantek Celik/a /li li class=member vcard a class=url fn href=http://suda.co.uk;Brian Suda/a /li li a class=member href=http://adactio.com/;Jeremy Keith/a /li li a class=member href=mailto:[EMAIL PROTECTED]Toby Inkster/a /li /ul /div This syntax is achieved by extrapolating the existing hCard standard from vCard 3.0 to vCard 4.0 draft. Feedback is welcomed. -- 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
[uf-discuss] Extending hCard with RDFa
I mentioned that I was working on an article about extending hCard with RDFa a few weeks ago on the Microformats discussion list, but then went on holiday and forgot about it for a while. Anyway... http://tobyinkster.co.uk/blog/2008/07/16/hcard-rdfa/ -- 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
[uf-discuss] Human and machine readable data format
Bob Jonkman wrote: On 14 Jul 2008 at 21:54, Toby A Inkster wrote: So there will be cases where people want to publish non-Gregorian dates, but for interoperability with iCalendar, they'll need to include a machine-readable Gregorian equivalent date. Actually, not necessary. The iCalendar spec [1] contains a property CALSCALE that can be used to specify the scale of the calendar. I'm not sure if any CALSCALE property values other than GREGORIAN are defined, but that's the way to use alternate calendars. For practical purposes it is necessary to include a machine-readable Gregorian date. Although the CALSCALE property does exist, the only valid value defined for it is GREGORIAN. Right now CALSCALE is not in the hCalendar property list [2] but it could be... Cognition http://buzzword.org.uk/cognition/ will actually parse class=calscale found within an element with class=vcalendar (but, not within class=vevent), and will include it in RDF and iCalendar output. -- 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
[uf-discuss] Generically converting JSON to POSH
Nirmal Patel wrote:
I am converting arrays into ordered lists and dictionaries into
unordered lists where each list item has a classname that is equal to
the key in the key/value pair.
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
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:
dl.json-object dt { display: none; }
dl.json-object dd { list-style-type: circle; }
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
[uf-discuss] Human and machine readable data format
Scott Reynen wrote: I'm assuming by different calendar, you mean non-Gregorian? If so, what are the use cases for non-Gregorian dates in hCalendar? It's not so much the case of wanting to encode non-Gregorian dates in hCalendar, but wanting to include non-Gregorian dates on the web page. abbr class=dtstart title=2008-07-1411 Rajab 1429/abbr Is '2008-07-14' to be considered an appropriate expansion of the abbreviation '11 Rajab 1429'? In case anyone is wondering whether non-Gregorian calendars are used in practice, the Islamic calendar (used in the example above) is the official calendar for Saudi Arabia, and used in religious contexts in many other countries; the Julian calendar is still used in religious contexts by Orthodox Christian churches, and frequently used by historians to refer to many older dates; the Chinese calendar is used for various religious and cultural reasons not just in China, but in some other Asian countries, but not for any official purposes. I would cite specific pages that use these calendars, but I don't speak Arabic, Russian or Mandarin, so don't know the correct terms to Google for. So there will be cases where people want to publish non-Gregorian dates, but for interoperability with iCalendar, they'll need to include a machine-readable Gregorian equivalent date. This is an example of where you're going to have very significant differences between the human and machine-readable representations of the same dates. (It's also interesting to note that automatic translation from the Islamic calendar to Gregorian is impossible to perform reliably, as it is based on human observation of the movements of the sun and moon, not on the actual -- predictable -- movements of the sun and the moon. Thus the exact numbering of dates is not usually known very far in advance.) -- 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
[uf-discuss] Human and machine readable data format
Breton Slivka wrote: The premise that publishers will pick any old format is merely an assertion with no evidence. Please show us an example somewhere else where this has happened, or perhaps a better argument than merely insisting on the obvious truth of it. I have previously mentioned the example of RFC 822. This standard defined a very specific human-readable date format for use in e- mails, and despite the fact that only a handful of people had to deal with it (i.e. the people writing mail clients, not the people *using* them), it quickly fragmented. Examples of specific deviations are that the RFC defines years to be two digits, whereas implementors quickly started using four digit years. (Fair enough I suppose as two digit years were a poor choice to begin with. The revised specification RFC 2822 switched to four digit years.) It also used strings like Mon, Tue, etc for days and Jan, Feb, etc for months. Despite the fact that these exact three letter strings were required by the specification, implementors often localised them. Lastly, although it used +/- for timezones, it also defined alphabetic codes like GMT and so forth for about a dozen commonly used timezones. However, many implementations started using other alphanumeric timezones not defined in the spec. ISO 8601 is a good, well-defined spec for dates and times, with many existing and interoperable implementations. It is clearly the best choice to standardise on as a date format. However, it's important that we offer publishers the option of hiding the ISO date from their visitors and displaying the date in a different format (perhaps even in a different calendar!) for them. -- 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
[uf-discuss] Human and machine readable data format
Paul Wilkins wrote: We should leverage the computers ability to do the hard work for us. pDate span class=dateFriday, July the 11th 2008/span/p As I've said before, although my parser does support dates in this format, I strongly recommend *not* allowing these per spec, as it will lead to unpredictable and inconsistent results. Yes, many programming languages do have libraries to do natural language parsing of dates, but these all differ subtly in what formats they support, how they interpret certain ambiguous dates, and how well they internationalise. e.g. I know that Perl's DateTime::Format::Natural, while it can perform very sophisticated parsing (Saturday evening 3 months ago = 2008-05-12T19:00:00, thursday morning last week = 2008-07-03T09:00:00) only includes English in the distributed module (though it has hooks allowing support for other languages). PHP's strtotime function is English only too, and there are differences in how it interprets some natural language dates, not just with Perl, but between different versions of PHP. Natural language parsing is really not the way to go, nor is a limited range of date formats that *look* like NLP, because publishers will believe them to *be* NLP and start publishing in any old date format. ISO8601 is what we must stick with - we just must agree a better way of embedding it than abbr. -- 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
[uf-discuss] The BBC case and HTML5 time
Henri Sivonen wrote: I found that HTML5 time isn't listed even as having been considered and rejected. See: http://microformats.org/wiki/datetime-design-pattern#HTML_5_.3Ctime. 3E_Element Frances Berriman wrote: The BBC can't use HTML5. It won't validate, it doesn't adhere to their standards and guidelines or their browser support levels. Adopting time does not require fully switching to HTML 5. Validation can be achieved through using a custom DTD. In terms of browser support, I think I'm yet to encounter a browser that doesn't treat unknown tags as effectively being the same as span. -- 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
[uf-discuss] The BBC case and HTML5 time
I wrote: Adopting time does not require fully switching to HTML 5. Validation can be achieved through using a custom DTD. Here's an example of how this can be done - a customised version of HTML 4.01 strict using hCalendar with time, plus a little RDFa. http://buzzword.org.uk/2008/html4plus-example.html This is parsed quite nicely into iCalendar by Cognition, apart from the time element, which Cognition doesn't support yet: http://srv.buzzword.org.uk/icalendar/buzzword.org.uk/2008/html4plus- example.html -- 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
[uf-discuss] class=tag
Brian Suda wrote: if you take a look at the 'category' property, it works how you are proposing to use 'tag'. Yes 'category' is defined for hCard, hCalendar and (possibly - it's ambiguous) hListing. But it's not for xFolk, hReview, hAtom or simply tagging whole pages. -- 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
[uf-discuss] Re: Using object for datetimes (was: Microformats and RDFa not as far apart as previously thought)
Ben Ward wrote: On 28 Jun 2008, at 17:03, Ed Lucas wrote: object data=20050125January 25/object This particular example is invalid, as the data= attribute must contain a URI, and a URI cannot start with a number. It's perfectly valid. Absolute URIs can't start with a number, but relative ones can - and the data attribute is permitted to contain relative URIs. This proposal is far less elegant than Frances' though. -- 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
[uf-discuss] Microformats and RDFa not as far apart as previously thought
André Luís wrote: this extension would only work on xHTML, right? Or is it possible to use rdfa in html? (I'm not that proficient in rdfa) The RDFa people have only specifically defined RDFa in terms of XHTML. This is for mostly pragmatic rather than ideological reasons - it was far easier to spec out that way. In practice, it was always expected that RDFa parsers would also support HTML, and indeed the majority do. There are two pitfalls with adding RDFa to HTML: 1. It adds a few new attributes, plus allows a handful of existing attributes like 'rel', 'rev' and 'content' to be set on more elements than before. Any non-trivial RDFa will make use of these facilities, so can't be validated against the HTML 4.01 Strict DTD. It would probably be not much more than 20 minutes work to download a copy of the DTD, add these attributes in and get your HTML valid though. (Some people seem to have an irrational dislike for custom DTDs, so this solution may not be satisfactory to them.) 2. It also uses xmlns:X attributes, where X can be pretty much anything. Because DTDs don't allow wildcard attributes to be defined, you won't be able to create a DTD that can handle this. Again, use of xmlns:X is not required by RDFa, but any non-trivial page will probably need to. If you know that you're only going to be using a limited number of RDF vocabs, your DTD can however define those ones specifically (e.g. xmlns:dc for Dublin Core, xmlns:foaf for FOAF, etc). But in the general case, this is less easy to get around. Although, it is beyond the scope of the RDFa spec, so is not likely to become official in the foreseeable future, I've proposed an alternative syntax for the xmlns:X stuff to be used in HTML - basically to use RFC 2731. (Which is what eRDF does.) I don't know how many parsers have implemented it, but Cognition includes support - http://buzzword.org.uk/cognition/ In short, if you're using the standard HTML 4.01 DTDs, RDFa will not validate. But it will work. -- 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
[uf-discuss] Microformats and RDFa not as far apart as previously thought
Benjamin Hawkes-Lewis: If you want to to use RDF in an HTML context, look to eRDF eRDF is an interesting experiment, but not particularly practical. Probably the biggest practical problem with it is the use of the id attribute to indicate that (by the attribute's mere presence) an element is the subject of any data found in descendant elements. This makes it difficult to add eRDF to existing documents which are usually already sprinkled liberally with id attributes. For example, if you have a side bar on a page and want to use it to provide some supplementary information about the main body of text, you might expect something like this to work: div id=sidebar h2About this page/h2 div class=dc-titleFoo bar/div div class=dc-creatorJoe Bloggs/div /div However, this actually says that the title of #sidebar (i.e. not of the whole page) is Foo bar, and that #sidebar was created by Joe Bloggs. Yes, you can rejig things a bit, make your sidebar use a class instead of an id, but adding eRDF to existing pages a pain - especially if they're not simple static pages, and you would need to go through thousands of lines of server side code to find all those id attributes. If you're writing an eRDF page from the ground up, this will probably not bother you as much. The other serious concern is that any information you wish to state about a resource which is not a physical anchor on the current page needs to be made within a link. So if Alice wants to link to Bob's page and mention the title of Bob's page, and when it was last updated, she would need to write something along the lines of: a href=http://bob.example.net; span class=dc-creatorBob/span's blog span class=dc-titleGroovin' with Bob/span was updated span class=dc-date title=20080629today/span /a whereas without eRDF, most normal people would probably only want to link the blog's title, not the whole phrase. This gets pretty awkward if you want to say substantial amounts of information about an off- page resource. (It's possible to work around it by using an id attribute somewhere, saying the information about the id attribute instead of saying it about the link, and then using owl:sameAs to say that the link and the id attribute are the same thing. But that is a hack.) Final annoyance: varying between dots and hyphens to separate the QName prefix and suffix, seemingly at random. Yes, it's quite impressive what they managed to achieve, bringing most of the RDF stack to HTML 4, without adding any new attributes or elements. Yet when it comes to implementing it on real life pages, it's annoying. RDFa is a much nicer solution to work with. -- 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
[uf-discuss] Cognition 0.1 alpha 10
Dear all, I've just released Cognition 0.1 alpha 10. New features of interest to the microformats community: * Experimental support for machine data in class http:// microformats.org/wiki/datetime-design- pattern#Experimental_Parser_Support * Support for class=tag (see my next message) * Support for XFN 1.0. XFN 1.1 has been supported for a couple of versions already, but pages can trigger explicit support for XFN 1.0 (i.e. no me, contact or kin) by including the XFN 1.0 profile URI. * Add support for type+value sub-properties for label in hCard. * XOXO todo lists http://microformats.org/wiki/User:TobyInk/ hcalendar-1.1#VTODO_List_XOXO_Minimization * Merged support for xFolk and hReview http://buzzword.org.uk/ cognition/uf-plus.html#xfolk-hreview * In vCard export, include vCard 4.0 compatible RELATED properties containing contact relationships gleaned from XFN. For more information, to download or try online: http://buzzword.org.uk/cognition/ -- 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
[uf-discuss] class=tag
It has been documented http://microformats.org/wiki/rel-tag-other- evidence that rel-tag places significant limitations on authors' choice of tag space. Many popular blogs (in case you doubt the popularity of these blogs, they were all in the top 40 results from a Google search for blog at the time of writing) include category links that do not have URIs suitable for use with rel-tag: * http://dilbertblog.typepad.com/ * http://dig.csail.mit.edu/breadcrumbs/ * http://stephenfry.com/blog/ * http://blogs.msdn.com/ie/ (currently using rel-tag incorrectly) Additionally, authors may wish to use links to searches for terms on Google or various dictionary/thesaurus sites as tags, but these do not typically use URIs suitable for rel-tag. One of the principles http://microformats.org/wiki/principles of microformats is to build around current behaviours and usage patterns. Microformats involve adding a few class names and rel values to existing semantic HTML; they should not require major overhauls in publishing patterns. Requiring authors to fiddle with .htaccess files (or whatever) to provide themselves with a clean tagspace raises the barrier to entry too high. The alternative: asking them to use a third party's tagspace (e.g. link all their tags to Wikipedia or Technorati or whatever) is unrealistic, and doesn't fit with existing publishing. So I propose an extension to rel-tag. As outlined above, there are many blogs which cannot easily use rel- tag. However, there are also a large number that can, and already do. So any extension to rel-tag has to be completely compatible with the existing specification. Any existing data marked up with several rel- tags should not find that the meaning of their tags has changed under the extended format. My proposed solution is that rel=tag continues as-is, but class=tag is introduced as a parallel mechanism for marking up tags. When class=tag is used, the link text is used as the tag value, subject to value excerption. Like rel=tag, class=tag will only be allowed on a and area tags, and not non-linking elements such as span, nor invisible elements such as link. As per the microformats principles, class=tag is a use of semantic, meaningful HTML; it is an example of visible metadata; and of course it reuses terminology from rel-tag. Examples: a rel=tag href=http://example.com/tags/TheTag;NotThis/a a class=tag href=http://example.com/tags/NotThis;TheTag/a For backwards compatibility reasons, when both rel=tag and class=tag attributes are found on the same element, then the existing rel=tag parsing rules take precedence. Example: a rel=tag class=tag href=http://example.com/tags/ TheTagNotThis/a Under this proposal, class=tag would be allowed anywhere that rel- tag is currently allowed, including hCard categories and xFolk tags. -- 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
[uf-discuss] Microformats and RDFa not as far apart as previously thought
Martin McEvoy wrote: On Tue, 2008-06-24 at 21:25 +0100, Toby A Inkster wrote: I'm about half-way through writing an article on extending hCard with RDFa You might like to read this http://internet-apps.blogspot.com/2008/03/so-how-about-using-rdfa- in-microformats.html Yep - if you take a look at the comments, you'll see I left one back in March. ;-) and this http://weborganics.co.uk/articles/show/extending-hcard-using-rdfa Yes - have read that too. The gist of mine is more about using RDFa to add information to hCards in order to encapsulate information which hCard itself can't represent (height, shoe size, whatever). -- 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
[uf-discuss] RE: Microformats and RDFa not as far apart as previously thought
Guillaume Lebleu wrote: span class=dstart lang=en-usOctober 5, 2004/span Cognition already supports this as a last ditch attempt at parsing dates - but I wouldn't recommend it get adopted widely. It's too unreliable; too much work to deal with internationalisation; too much work full-stop in languages that don't provide a handy library that takes care of most of the work. -- 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
[uf-discuss] http://microformats.org/get-started/
It would be nice if http://microformats.org/get-started/ mentioned adding a profile URI. See: http://microformats.org/wiki/faqs-for-rdf#Isn.27t_this_just_scraping.3F http://microformats.org/wiki/profile-uris -- 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
[uf-discuss] hCard markup question w.r.t. organizations
Basic idea is: div class=vcard div class=org div class=organization-unit fnMolecular Biology Lab/div div class=organization-nameUniversity of Cambridge/div /div /div If this is also part of the lab's postal address, you can combine it nicely with the adr: div class=vcard div class=adr label div class=org div class=organization-unit extended-address fn Molecular Biology Lab /div div class=organization-name extended-address University of Cambridge /div /div div class=street-address123 Some Street/div !-- etc -- /div /div The drafts for vCard 4.0 (hCard is based on vCard 3.0) include a property called KIND to indicate which type of thing the card provides contact information for. e.g. individual, org, group, etc. Cognition http://buzzword.org.uk/cognition/ will automatically infer the kind of hCard by noticing that the fn and organization- unit properties are identical, so the kind must be group. -- 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
[uf-discuss] regexp for last path component
Paul Denning wrote: Can someone provide a regexp for the last path component? The following Perl-compatible regexp seems to do the trick: /^ [^\#\?]* # Stuff at front (ignore) \/([^\/]+)\/?# Last path component (\?.*)? # Query string (ignore) (\#.*)? # Fragment (ignore) $/x Use the first sub-pattern match as the tag. -- 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
[uf-discuss] Cognition 0.1 alpha 9
Dear all, Today is my birthday, and as *my* birthday present to *you*, I present the latest preview release of Cognition. http://buzzword.org.uk/cognition/ Many of the improvements have been in terms of performance. Cognition is about 10 times faster than it was in alpha 8. This has been achieved by splitting the program into daemon and client processes, in much the same way as SpamAssassin works. (SpamAssassin is another Perl-based parser with thousands of lines of code which had performance problems largely due to initialisation.) Also to help performance, the daemon uses an HTTP cache, and an object cache to avoid re-parsing pages that haven't changed. There have been improvements in compliance with hCard/vCard/jCard (e.g. plural name properties are now supported properly), hCalendar/ iCalendar (fixes for datetime, plus support for http:// xml.coverpages.org/draft-royer-ical-vcard-01.txt) and geo (now supports explicit plus signs used in numbers). Apart from these little tweaks here and there, Cognition now adds almost-complete support for hReview 0.3. (It doesn't support ratings being used within a tag, but does support tags used within a rating.) Reviews can be output as RDF/XML or RDF/JSON using Danny Ayers and Tom Heath's RDF review vocabulary http://danja.talis.com/xmlns/ rev_2007-11-09/index.html. Download Cognition to try it, or have a play with the slightly dodgy web service here: http://buzzword.org.uk/cognition/ -- 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
[uf-discuss] Next/Prev [was Rationale for providing hAtom instead of Atom/RSS feeds]
Zhang Zhen wrote: rel=next is a relationship between two documents, as well as *between two hfeed*. Yes, but rel=next is a relationship between two documents, as well as between *two hfeeds*. ;-) -- 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
[uf-discuss] Next/Prev [was Rationale for providing hAtom instead of Atom/RSS feeds]
Toby, wasn't that what Zhang said? or did you just move the emphasis? :P Yes, the emphasis -- that rel=next/prev indicates relationships between *two* hAtom feeds. I was trying to come up with some situations where people would put a link to the next page within a document with an hAtom feed and NOT want to mean the next page (linked in the link) is also the next page of hatom. I couldn't. I don't currently use hAtom on my site, out of concern for accessibility and the datetime pattern. However, imagine that I were to use hAtom to mark up the comments on my blog. Now, my blog articles include links to the next/prev articles in the side bar, marked up with rel=next/prev. I wouldn't want the hAtom comment feed for an article to automatically include comments from the next and previous articles! Each article has a separate comment feed -- rel=next/prev shouldn't join them together. I think it makes sense to allow the inclusion of an A/LINK element with rel=next inside the hAtom feed. If someone doesn't want link rel=next to be considered for the hatom feed, just declare explicit the hFeed and leave the link outside. Indeed, but rel=next/prev should indicate the next and previous feeds, not a continuation of the current feed. This would be more in line with the current meaning of rel=next/prev which indicate the next and previous pages in a sequence -- not a continuation of the current resource intended to be rendered as a single page. -- 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
[uf-discuss] Next/Prev [was Rationale for providing hAtom instead of Atom/RSS feeds]
André Luís wrote: Still, do you see any way of tieing two hFeeds on separate pages together? Any way at all? The best way that I can come up with involves a slight extension to hAtom. The current hAtom spec only covers a subset of the full Atom spec. In particular, to cover feed consolidation, you'd want to implement in hAtom an equivalent to the id element in Atom. Because class=id or rel=id look a bit confusing (confusion with the id attribute) I'd suggest: rel=feed-id rel=entry-id rel=entry-id isn't really needed for this task, but if you're in a situation where the same entry could appear on several pages, then it may be useful. The feed id assigns a unique ID (in the form of a URI) to a feed. If two hAtom feeds have the same ID, it should be safe to assume that they're different HTML representations of the same underlying logical feed. Going back to my original examples, this could become: html titlePage 1/title link rel=next rev=prev href=page-2 link rel=feed-id href=urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6 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 link rel=feed-id href=urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6 body div class=hentry h1 class=entry-titleEntry 2/h1 p class=entry-contentContent./p /div /body /html OK, that solves part of the problem - a way of determining if two hAtom pages represent the same underlying feed. However, given that these pages may be on opposite sides of the Internet, to consolidate the feed we need a way of finding them. For this, I'd suggest using rel=meta, an existing rel value which is used to link to additional metadata. Because rel=meta is often used to link to RDF files, it may be helpful to RDF parsers to explicitly include the type attribute. Adding all this to the mix gives us: html titlePage 1/title link href=page-1 rel=feed-id link href=page-2 rel=next meta type=text/html body div class=hentry h1 class=entry-titleEntry 1/h1 p class=entry-contentContent./p /div /body /html html titlePage 2/title link href=page-1 rel=feed-id prev meta type=text/html body div class=hentry h1 class=entry-titleEntry 2/h1 p class=entry-contentContent./p /div /body /html What do other people think? -- 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
[uf-discuss] Rationale for providing hAtom instead of Atom/RSS feeds
André Luís wrote: What is the rationale for providing an hAtom feed on a page for content that is also syndicated via a real Atom or RSS feed? Can someone provide me with a real use case? One idea that I've been playing with is removing a page's Atom feed, and replacing it with something like this: link rel=service.feed type=application/atom+xml href=hatom2atom.php?uri=http://example.org/page.html; So although David says that hAtom is not intended to replace Atom, it can be used to abrogate the need to explicitly publish Atom as a separate resource. (Though of course most Atom is not published by hand, but by the same CMS that powers the HTML, so in these cases, this technique won't save any work.) -- 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
[uf-discuss] RE: microformats-discuss Digest, Vol 36, Issue 9
Charles Belov wrote: span class=humandtstartMay 12, 2008, 5:30pmabbr class=dtstart title=2008-05-12T17:30:00-0700 style=display:none/abbr/span Similar to my current compromise: span class=dtstart May 12, 2008, 5:30pm abbr class=value title=2008-05-12T17:30:00-0700 style=display:none/abbr /span Which seems to work in many current parsers. -- 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
[uf-discuss] Request for help from screen reader users from the BBC
Ben Ward wrote:
I don't think the ‘what's the default‘ argument is an absolute decider
either way with this.
Indeed. Even if no screen readers even *offered* the option of
reading the title attribute of abbreviations, the abbr design pattern
would still be a bad idea. Or rather,having it as the only supported
method of supplying machine-readable data (short of making the
machine-readable data available as normal page content) is a bad idea.
In the case where the human readable data really is an abbreviation
for the machine readable data, such as
abbr class=country-name title=United KingdomUK/abbr
then the abbr pattern is appropriate, and it's good that it works.
But when the machine readable data is not a legitimate expansion of
the human readable text, then use of the abbr design pattern falls
into an obvious discord with:
http://microformats.org/wiki/semantic-xhtml-design-principles
An author who was not using microformats could not legitimately claim
to be using proper semantic HTML if they included samples like this
in their pages:
abbr title=cellmobile phone/abbr
abbr title=2008-01-01end of December/abbr
Adding classes ('type' and 'dtend') does not make things any better.
The abbr design pattern is good and should work, but we really must
have an alternative for those times when it doesn't make good
semantic sense.
--
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
[uf-discuss] [Ann:] TransFormr.
The best way to get going is to use auto detect, example: http://transformr.co.uk/detect/http://tantek.com/ Auto-detect... now that is a good idea... I'm going to copy you: http://srv.buzzword.org.uk/detect/tantek.com/ -- 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
[uf-discuss] Re: One more shot at accessible hCalendar
If the problem is 'machine readable dates get read out sometimes' I don't see how the data: prefix solves that. Screen readers may be configured to read out the title attribute for abbr and acronym; perhaps also a and img. But they don't automatically read out the contents of the title attribute in the general case. The title attribute on span or div or table or b or whatever will not be read out -- data can safely be kept there. What is needed is a signal to parsers to tell them when to use element content, and when to use the title attribute. The traditional microformats method is: * If element==abbr, then title attribute * Else, element content. Adding support for the data: prefix, this becomes: * If title attribute contains 'data:', then the remainder of the title attribute * Else if element==abbr, then title attribute * Else, element content. -- 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
[uf-discuss] Re: One more shot at accessible hCalendar
I'm wondering, can you also configure screen readers to expand out titles on any elements? Not any of which I'm aware. There is a good article on this issue here: http://www.paciellogroup.com/resources/articles/WE05/forms.html -- 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
[uf-discuss] hAtom and Optimus
I see an error that required property author not specified An author is required for *each* hentry, but the spec allows this required element to be missing and provides instructions for parsers to determine the author in these cases. -- 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
[uf-discuss] Geo microformat doubt
Ana Belén Ramón wrote: Is this microformat right? a href=# class=geo title=42.3;-1.96667Madrid, Spain/a No — the title attribute is only used for abbr. There are alternative proposals to use the title attribute for other elements, but most parsers do not support those yet. Usage of the abbr pattern should work, although it is terrible semantically: a href=# abbr class=geo title=42.3;-1.96667Madrid, Spain/abbr /a Because Madrid, Spain really isn't an abbreviation for 42.3;-1.96667. If you use value excerpting you might be able to come up with something a bit more acceptable semantically: a href=# class=geo Madrid, Spain abbr class=value title=42.3;-1.96667/abbr /a As it happens, Cognition http://buzzword.org.uk/cognition/ will successfully parse your first, non-standard geo, because as a last ditch attempt at parsing a geo, it will simply look for two semi- colon or comma delimited numbers anywhere in the HTML code (including href attributes, comments, whatever!), but that is an extension of the geo spec — it's not a standard part of it. -- 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
[uf-discuss] Cognition 0.1 alpha8
New version released today. Improvements related to microformats: * Support for xFolk * XFN improvements I've implemented Andy Mabbett's fn == address component suggestion http://microformats.org/discuss/mail/microformats-discuss/2007- December/011169.html. Also perhaps of interest: * Support for COinS * Support for meta name=ICBM http://buzzword.org.uk/cognition/ May the fourth be with you! -- 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
[uf-discuss] Coding mbox_sha1sum in XFN
Julian Bond wrote: This looks like a generic problem. How to qualify an XFN entry with additional non-visible information. Ah. Additional. In my earlier message I was assuming that you did not know (or want to show) an HTTP URL for the contact. That is, that you wanted to represent a person by their mbox_sha1sum *instead* of a conventional URL. span class=mbox_sha1sum:fc521285feac8d1de0a488166aeeb9dbf99070e1 a href=url rel=contacttheir name/a span That approach won't be picked up by any parsers that I know of. A better approach would be to look into RDFa or eRDF. Very few parsers though will handle both microformats and one of those. Cognition http://buzzword.org.uk/cognition/ handles most microformats, plus eRDF *and* RDFa. Here's a code sample that uses hCard, XFN and RDFa (FOAF) and is correctly parsed by Cognition: div class=vcard id=alice xmlns:foaf=http://xmlns.com/foaf/0.1/; a class=fn url rel=contact about=#alice property=foaf:mbox_sha1sum content=fc521285feac8d1de0a488166aeeb9dbf99070e1 href=http://alice.example.net; Alice Jones/a /div Note that RDFa introduces a handful of extra attributes to HTML, so will not validate unless you use an RDFa DOCTYPE. (eRDF uses existing HTML attributes, but in my experience is often very likely to result in false positives for parsers when applying eRDF parsing to pages that were not authored from the ground up with eRDF in mind.) -- 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
[uf-discuss] Coding mbox_sha1sum in XFN
Julian Bond wrote: I want to be able to say something like:- This person with this profile page URL and this mbox_sha1sum is one of my contacts. But I'm not sure how to do it in XFN. Where can I put mbox_sha1sum into a href=url rel=contacttheir name/a For the href attribute, you could use a (non-standard, but frequently used[1]) SHA1 URN: a href=urn:sha1:052f384479559f1b4854756bdce69d1c658de3b3 rel=contactTheir Name/a It should be supported by most XFN parsers that treat the URL as basically an opaque identifying string. Any XFN parsers that assume that the href attribute will be an HTTP URI may have problems, but that would be their own fault for making such an assumption. Of course, if you're using it on a web page designed for humans, you should bear in mind that people clicking on the links might get confusing error messages if they don't have any program configured to handle such URIs (and I can't imagine that any such programs exist!), so it might be inadvisable to use such links on such a web page. One way of mitigating this problem might be to style these urn: links (using CSS) as if they were plain, non-link text. (Don't forget to use the CSS cursor property to disable the pointing hand cursor.) 1. Google for urn:sha1 (in quotes) returns almost a quarter of a million results. It's mostly used for P2P, but that shouldn't stop us re-employing it here. -- 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
[uf-discuss] hCard uid
Stephen Paul Weber wrote: and give me a value of Weber, Stephen Paul for uid - the intended value was definitely http://singpolyma.net/ Your code is certainly right. If a parser isn't looking at the href attribute (and it should!) for the UID, then the best you can do is force it using something like the ABBR pattern: a class=url rel=me href=http://singpolyma.net/;span class=family-nameWeber/span, span class=given-nameStephen/span span class=additional-namePaul/span /a abbr title=http://singpolyma.net/; class=uid style=display:none/abbr For the record, the behaviour Cognition http://buzzword.org.uk/ cognition/ uses for parsing UID is this: 1. If the UID has an ID attribute, uses the URI for the fragment; 2. Otherwise if the UID is an a or area element, uses the href; 3. Otherwise if the UID is an img element, uses the src; 4. Otherwise if the UID is an object element, uses the data attribute; 5. Otherwise uses the UID node contents, respecting the ABBR design pattern, value excerpting, include pattern, etc. 6. If there is no UID node at all, then it uses the id attribute of the vcard root element (if any). So it will correctly parse both the example I provided above, and your original example. -- 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
[uf-discuss] Cognition 0.1 alpha 7 released
I've just released Cognition-0.1-alpha7 http://buzzword.org.uk/ cognition/. Amongst other improvements it includes: * Support for representative hCard. * Minor improvements in hCard support. * Support for XFN. * Major improvements in hCalendar support, including support for rel=vcalendar-child@, rel=vcalendar-parent, rel=vcalendar- sibling and implied relationships indicated by nesting; better support for vFreebusy; use the title attribute of div class=vcalendar title=foo as the calendar title. * Major improvements in stringifying (converting HTML to plain text), including support for the start, type and value attributes on ordered and unordered lists; better value excerpting. * Minor inprovements to iCalendar and vCard outputs. * Major improvements to RDF/XML output. * New RDF/JSON output. * New jCard output. You can try Cognition through the web based interface, but I highly recommend downloading it and using it on your own computer, because the web interface is r-e-a-l-l-y s-l-o-w. -- 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
[uf-discuss] Value excerpting - thoughts and random observations
I've been noodling with value excerpting recently, as Cognition's
support for it has been limited until recently -- it was only
supported for .vcard .tel, .vcard .email and .vcard .impp, but I
realised that I really needed it for .vfreebusy .freebusy and so
decided to generalise it to pretty much all properties.
Here are some interesting observations:
span class=fn n
span class=given-nameToby/span
span class=additional-namespan
class=valueA/span./span
span class=family-nameInkster/span
/span
Value excerpting here is used so that the dot displayed after the
middle initial isn't taken to be part of the additional-name, yet it
displayed as part of the formatted name. Unintentional consequence:
FN is parsed as simply A. I've not tested other parsers, but I
assume that the results are similar. Of course, a better way of
marking it up would have been:
span class=fn n
span class=given-nameToby/span
span class=additional-nameA/span.
span class=family-nameInkster/span
/span
Not using value excerpting at all.
Consider abbr versus value:
span class=fnabbr title=Toby A. Inksterspan
class=valueFoo/span/abbr/span
FIGHT!
Under my interpretation, FN is Toby A. Inkster. The span with class
value is ignored, as it is the child of an abbr with a non-empty
title attribute.
Yet abbr versus value can be used for good as well as evil.
Consider this:
span class=dtstart
1 October 2008
abbr class=value hyper title=20081001/abbr
/span
With the CSS abbr.hyper{display:none;}.
This uses existing microformats patterns (value excerpting, abbr
pattern) to create a more accessible alternative to the abbr/datetime
pattern. Because it uses existing patterns, it should work in
existing tools. *Should*, not necessarily *does*! Works in my current
unreleased version of Cognition. (Which I'll be releasing as soon as
the RDFa group get around to updating their syntax document with
their recently decided changes.)
Another thought: what to do about this?
span class=fn
Foo
span class=value
Bar
span class=value
Toby A Inkster
/span
/span
/span
Should the FN be:
Bar Toby A Inkster
Ignoring the inner class=value.
Bar Toby A Inkster Toby A Inkster
Parsing both values and concatenating them, as if they were not
nested. Cognition currently does this.
Toby A Inkster
The outer value itself is subjected to value excerpting.
Or do we simply say that the parsing of such a construct is
undefined, so authors must not use it? And then let parsers handle it
however they like, reasonably confident that they will never run into
such a construct.
--
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
[uf-discuss] Include-Pattern Infinite Loop Open Issue
Jason Kams: I'd like to address Toby Inkster's current Open Issue. [http://microformats.org/wiki/include-pattern-issues] It's very easy for inclusions to end up as an infinite loop. For example:... This issue is addressed by simply ignoring any includes that reference an ancestor of the current node. [http://microformats.org/wiki/include-pattern#in_general] To prevent infinite loops, if a class=include refers to itself or to an ancestor in the parse tree, then it is ignored and has no effect on the parser. Can this issue now be closed citing the page above? There are still issues of one include including another include which references the first include, but yes, preventing the inclusion of an ancestor node does go a long way to a solution. -- 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
Re: [uf-discuss] multiple hCards on a user's profile page - how can I mark one as the actual user?
Martin McEvoy wrote: I have a new test going on my Dev site that does just about what you suggest and converts XFN+hCard via XSLT to produce a FoaF file called for want of a word xFoaF. example output using http://www.tantek.com/#hcard as the transformation Mostly looks good, but I'd suggest that you seem to have some of the relationships backwards. For example, Tantek has the following on his page: a href='http://juliemelton.com' rel='muse'Julie Melton/a which you convert to: Person rdf:ID=hcard nameTantek Çelik/name rel:mentorOf Person rdf:about=http://juliemelton.com; nameJulie Melton/name weblog rdf:resource=http://juliemelton.com/ /Person /rel:mentorOf /Person (I've simplified both down a bit.) I would suggest that the FOAF should be the other way around: Tantek apprenticeTo Julie; not Tantek mentorOf Julie. (Yes, the terms mentor and apprentice seem a bit odd, but they're about the closest terms that the FOAF relationships extension has to muse.) Also, you needlessly output multiple foaf:knows for each person. -- 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
[uf-discuss] hCalendar Acid Test #1
There's no right or wrong answer - just judge the output of your favourite parser yourself. http://examples.tobyinkster.co.uk/hcalendar-acid1.html For comparison, here's the output from latest development version (unreleased) of Cognition: http://examples.tobyinkster.co.uk/hcalendar-acid1- cognition-20080415.ics http://examples.tobyinkster.co.uk/hcalendar-acid1- cognition-20080415.rdf Cognition's output is by no means perfect: handling of attendees, contacts and organisers in particular could be improved. -- 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
[uf-discuss] multiple hCards on a user's profile page - how can I mark one as the actual user?
Brian Suda wrote: there is a wiki page somewhere (which i can't find at the moment), but there are a few options. HTML has the address element to describe the contact info of the page owner. No - address provides contact information for the page. The owner of the page and the correct person to contact regarding the page may well differ. The page that you're thinking of is the representative- hcard page, which addresses (no pun intended) this very issue amongst others. Also perhaps relevant is the page I threw together over the weekend on mapping XFN to FOAF, which covers more than just FOAF really: it's a general purpose guide on how to interpret the interactions between different hCards and XFN on the same page. Not so much from an page authoring perspective, but rather from a parser development point of view, to make sure that people writing parsers don't misinterpret pages like the ones described in this thread. http://microformats.org/wiki/representative-hcard http://microformats.org/wiki/xfn-to-foaf -- 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
[uf-discuss] Re: Parsing XFN in PHP
Ryan Parman wrote: On Apr 10, 2008, at 10:34 AM, Toby A Inkster wrote: http://www.php.net/manual/en/function.dom-domdocument-loadhtml.php This is interesting -- especially if it works. However the version information is noted as CVS-only. Is this in a shipping version of PHP yet? I've never quite understood how they get that versioning information in the documentation. It often seems wrong. DOMDocument has been part of the PHP core since 5.0. Another option is XML_HTMLSax3 from PEAR: http://pear.php.net/package/XML_HTMLSax3 Here's an example use of the above PEAR module: it converts an HTML table into a two-dimensional array, respecting rowspan and colspan (oh yes!): http://tobyinkster.co.uk/blog/2007/07/20/html-table-parsing/ -- Toby A Inkster BSc (Hons) ARCS [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 15 days, 18:33.] Tagliatelle with Fennel and Asparagus http://tobyinkster.co.uk/blog/2008/04/06/tagliatelle-fennel-asparagus/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: Optimus 0.5.1
Michael MD wrote: nested includes? ! my guess is that anyone doing that would be asking for trouble! This is another thing that Cognition has supported since alpha1. (Though until the latest release it supported including a node's own parent, which really *is* asking for trouble!) The only thing you've got to be careful of (from a parser's POV) is making sure that you don't get stuck in an infinite loop. The solution is to write your inclusion code to *not* support nested includes, and then simply call the function a few times. (The first call will handle includes, then the second call will handle includes within includes, etc.) My policy is to allow two levels of includes for adr and geo, 4 levels for hCalendar valarm and hCalendar vfreebusy, and 6 for hCard, hAtom entries, hCalendar vevent and hCalendar todo. I also use an optimisation such that each call of the function actually checks to see if any changes have been made. If no changes have been made, then the loop is ended prematurely -- this prevents the inclusion code (which is computationally expensive) from being called when there are no instances of class=include left, or those instances are invalid (e.g. attempts to include an ancestor node). -- Toby A Inkster BSc (Hons) ARCS [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 14 days, 19:59.] Tagliatelle with Fennel and Asparagus http://tobyinkster.co.uk/blog/2008/04/06/tagliatelle-fennel-asparagus/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: Parsing XFN in PHP
Julian Bond wrote: - Modifications to reduce dependencies and just possibly work with PHP4 PHP4 has been dead since the beginning of January. There will be no further releases apart from the odd security fix. For projects looking to expand beyond PHP5, PHP6 is a more useful option. -- Toby A Inkster BSc (Hons) ARCS [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 14 days, 20:34.] Tagliatelle with Fennel and Asparagus http://tobyinkster.co.uk/blog/2008/04/06/tagliatelle-fennel-asparagus/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: Optimus 0.5.1
Dmitry Baranovskiy wrote:
As always feedback is highly appreciated.
Just a few thoughts...
* Parsing http://examples.tobyinkster.co.uk/hcard issues a few warnings
related to use of XHTML with namespaces. You might want to think about
turning down PHP's error reporting. e.g.
error_reporting(E_ERROR);
* Parsing same page with output as JSON I see (line break added):
tel: [{, type: workvalue: +1 (310) 597 3781 work},
{, type: workvalue: +1 (310) 597 3781 work}]}
this is clearly garbled.
* There are other JSON output errors: e.g. not all strings are quoted.
I might have some more feedback when I've gone through your source code.
--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 14 days, 20:17.]
Tagliatelle with Fennel and Asparagus
http://tobyinkster.co.uk/blog/2008/04/06/tagliatelle-fennel-asparagus/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: Parsing XFN in PHP
Michael MD wrote: There are still lots of people stuck with php4 on shared servers ... I suspect that won't be the case much longer after security updates for PHP4 are discontinued in August. What did they expect? ... changing a language in ways that breaks existing code is hardly the way to encourage people to upgrade to a new version! There are virtually no changes in PHP5 that break existing PHP4 code. Some things like register_globals and auto-escaping of incoming variables are turned off by default in PHP5 (they were on by default in PHP 4.0 IIRC) but can be switched on in php.ini or a .htaccess file in a matter of seconds. PHP6 will be a more painful switch for those with legacy code. (But still fairly painless for those updating from PHP5-style code.) -- Toby A Inkster BSc (Hons) ARCS [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 14 days, 23:58.] Tagliatelle with Fennel and Asparagus http://tobyinkster.co.uk/blog/2008/04/06/tagliatelle-fennel-asparagus/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: Parsing XFN in PHP
Ryan Parman wrote: But we can do it in web browsers! What do web browsers have that PHP developers don't? An HTML parser. As far as I know there are no HTML parsers written for PHP (or any other language that I'm aware of). http://www.php.net/manual/en/function.dom-domdocument-loadhtml.php -- Toby A Inkster BSc (Hons) ARCS [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 15 days, 4:51.] Tagliatelle with Fennel and Asparagus http://tobyinkster.co.uk/blog/2008/04/06/tagliatelle-fennel-asparagus/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: XFN Relationship types
Julian Bond wrote: Is there some standard here we should be encouraging like rel=Contact Acquaintance or do we expect developers to know that an Acquaintance is also a Contact? And if it's the second is there some mapping table on a wiki somewhere? The background http://gmpg.org/xfn/background document makes it pretty clear (as does the profile document) that contact, acquaintance and friend are mutually exclusive. They can be considered a scale. Choosing a value higher up the scale (e.g. friend) both forbids the explicit use of one lower down the scale (e.g. contact), but also implies its meaning. So it's not valid to write, say: a href=http://bob.example.net; rel=friend contact.../a but when faced with: a href=http://bob.example.net; rel=friend.../a it is acceptable for a parser to conclude that Bob is one of your contacts. The co-resident and neighbor values could also be construed in such a manner. -- Toby A Inkster BSc (Hons) ARCS [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 15 days, 4:59.] Tagliatelle with Fennel and Asparagus http://tobyinkster.co.uk/blog/2008/04/06/tagliatelle-fennel-asparagus/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
