[uf-discuss] hReview 0.3 drafted
Greetings, I've taken the changes proposed and accepted for hReview 0.3 from the review-brainstorming page and incorporated them into hReview: http://microformats.org/wiki/hreview Please take a look and review (so to speak). Follow-up to the list with any errors / omissions / feedback / suggested improvements. Thanks! Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hlisting discussion Wednesday night
On 2/20/06 8:43 AM, Craig Donato [EMAIL PROTECTED] wrote: If anyone is interested in discussing hListing, I wanted to propose a get together this Wednesday night at 6pm in San Mateo at Oodle's office. Apologies for the late notice. No need to RSVP but would love a heads up if you think you're coming so I can buy enough pizza. Oodle's address is 2929 Campus Drive #400, San Mateo, CA 94403 (we sublet from Greylock). Directions can be found at http://www.greylock.com/contact/directions_ba.cfm Thanks to Craig and Oodle for hosting an excellent multi-hour discussion session on hListing. We have folks from Oodle, Edgeio, Technorati, CommerceNet, and independent developer Assaf Arkin all participated in a heated but productive discussion. Here are some collaboratively taken (props to SubethaEdit) rough notes: hListing meeting notes Attendees Tantek Çelik - Technorati Ryan King - Technorati Craig - Oodle, cofounder Matt - Edgeio Donald - Oodle, feeds person Vidar - Edgeio Scott - Oodle, cofounder Zuzana - Oodle Assaf Arkin - uPress plugin author Faith - Oodle Rohit - CommerceNet Initially the hListing authors tried repurposing hReview, but found that differences were enough to require a different format. The other extreme would have been to make everything a tag. Instead, a compromise was made. 'Item type' may be sub-optimal in hReview and hlisting. In hReview, the item type is very coarse, but there are some restrictions depending on what the type is. What do currently listings providers do for item type? Taxonomies? * craigslist - very loose * ebay - tighter * newspapers - simple (can't do it over the phone) Any consideration to a unique ID for a listing? permalink. item type: business - hCard item info person - hCard item info event - hCalendar event item info other (default) - catchall product - catchall service - catchall opening ? - hCard for organization x housing ? - adr/geo x place ? - adr/geo x website ? - url x url ? - url (x) means perhaps we should eliminate it. if you sell etc. something, you republish with dtexpired = current datetime. parsers should respect del datetime= .../del markup location should be part of item info? yes delete separate location field and instead, extend item info item info (fn || url || photo || adr || geo) can we get away with not having the item type at all? possible approaches: 1. use tags or other microformats to define the item. no item type. allow hCard and hCalendar event on the item type. encourage folks to use tags for item type/category. +1 Tantek 2. only list things that have microformats. (person, business, event, other) 3. start with a set of classifieds as explicit item type values +1 Zuzana, as long as it was open ended +1 Rohit, marketing value of ? 4. totally free form item type - same as just a tag? review vs. listing items that are reviewed often have urls whereas items that are listed often do not? listings tend to be inventories of one Vidar: edgio is more interested in how do we interpret this?, rather than specifying user/publisher behavior/requirements why are listing type/action required? why can't those be tags? ([offer] | wanted ) transaction: sell | rent | trade | meet | announce | service if hListing becomes well used, it will become impossible to do maintenance? should we add an optional definition list for key/value pairs? proposed: collapse listing type, listing action, item type into tags. converge them to listing type (or listing tags) and make a recommended set of keywords +1 Craig +1 Rohit Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformat for forms to post comments?
On 2/23/06, Julien Couvreur [EMAIL PROTECTED] wrote: Hi, Hi Julien! Most bloggers have the problem of following up on the comments they leave on other people's website. One of the challenges to solving this comment tracking problem is that comment forms come in many shapes. Would this be a good problem to solve with a microformat? Has any microformat of this kind been discussed before? Aha, comment tracking: the bain of my life. Whilst I'm not totally sure if hAtom has this in mind, I suspect that it could be used very effectively for converting the comments pages of any blog into an Atom feed and thus allow them to be tracked using a feed reader. At the time of writing, Wordpress is the only mainstream blogging tool I'm aware of that provides native feeds for every post (in RSS 2.0 format), but since hAtom allows you to describe a feed within the HTML mark-up itself, it's a nicely CMS-agnostic solution for creating individual post feeds. As a side question, do we know if some microformats really gained a lot of adoption? If so, which ones? I believe XFN was taken under the Microformats umbrella, that's popular. hCard is picking up too. Regards, Ben (Apologies to list moderators as this message was previously accidentally sent from an unvalidated address) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Microformats to interlink desparate services
Hi all, I'd like to float an idea that I believe Microformats could play a large part in. A few weeks ago, I wrote a rather rough article on my blog [1] about a way for people to host personal 'profile' information as part of their own blog/webspace/etc. Any service or web application could request an individual's profile information based on a URI. Firstly, such a profile would contain contact information, homepage(s), locations and other such fields that services like Flickr, and older applications such as messageboards all request when you register. The first use-case is that rather than enter my details on a dozen different sites (and have to maintain them all separately when I move house), each service could just be given my URL and autofill as much of the information as I provide. It would reduce hassle and time taken to register for new services. What's more, this information can then be automatically updated in the service when I update the profile on my own site. At the moment, this is hCard, perhaps with an additional pointer to locate the hCard from a homepage (directing from http://ben-ward.co.uk; to http://ben-ward.co.uk/about/;, for example). The second set of information I want to contain in a profile concerns other services which I'm a member of. Generally speaking, modern web services have a screenname, a personal URL and a feed. But, there is no way of knowing that BenWard on Flickr and BenWard on Upcoming.org are the same person. Furthermore, there's no way of knowing that BenWard on Delicious is the same person as Shovel on Last.FM. This profile file should therefore list the common attributes of the standalone services, such that data from all the separate services I use could be aggregated. Not only could I aggregate disparate data, but the services I'm a member at could use the profile to link to other content created by the me. To remove the need for disparate services to know each other by name, each service listed in the profile would be tagged with interoperable terms: Flickr tagged Photographs, Delicious, Magnolia, Yahoo MyWeb2.0 tagged Bookmarks, Last.FM and Pandora both tagged Music, and so forth. As such, any service could include related content from any other service based on a common tag, and the feed URI provided in the profile. This second part isn't hCard and if other people agree that this is a good idea, it's the second part that I'd be interested to develop. (I can't think of a clever name for it, maybe hWebServices or something else that's, y'know, actually good). The final part of my pre-draft was to specify a mandatory location for this information. When I bodged together my blog post on the matter I called it profile.xml, believing that some invented XML format could contain all the information. It was afterwards that I realised the obvious use for hCard and that actually, presenting such a profile as HTML has a lot of merit. Perhaps, rather than require it to be a fixed file location (which may not play well for lots of users), the profile could be pointed to by a link rel= href= / on the first page served up by the person's URI. That way it could be embedded into existing about me pages that exist all over the web and could already contain an hCard. The final thing, is that I don't know if this idea is new. If it's come up before and everybody laughed, I apologise. I'm also acutely aware that using the word profile in the context of HTML is a potential cause for confusion, but I'm stuck for better terminology. Feel free to swap it for something else. Thank you, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hReview 0.3 drafted
Tantek elik wrote: Greetings, I've taken the changes proposed and accepted for hReview 0.3 from the review-brainstorming page and incorporated them into hReview: http://microformats.org/wiki/hreview Question: If reviewer is absent from the hReview, then look outside the hReview, in the context of the page, for the reviewer. If there is no "reviewer" outside either, then use the address for the page as the reviewer. What if the review is embedded in something other than a web page, say a feed? (Or an email, but I think a feed falls in the 80% case.) A reasonable thing to do would be to use the authorship rules for the Atom or RSS feed, looking up the XML tree. -John ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats to interlink desparate services
On Feb 23, 2006, at 8:32 AM, Ben Ward wrote: The final thing, is that I don't know if this idea is new. It's not new. I know that Chris Messina and some other folks have been talking about building a similar service, called rhyzomatic.com for awhile. I'm not sure if there's been much progress there, though. I'm not going to respond to your individual points (not because they aren't good, I just have a simpler answer), but instead just say, start building it with the microformats we have available. So, use hcard + xfn + xfolk to build what you can. THEN, we can see what's missing. I suspect, however, that you can get the majority of your functionality with those formats. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hResume 0.1
On Feb 23, 2006, at 8:52 AM, Steve Ganz wrote: I've decided to go ahead and push an hResume draft as v.0.1. http:// microformats.org/wiki/hresume. Please try to use it, try to parse them and give some feedback. Ryan, under Job Titles it says: To express multiple job titles/positions in the same experience event you should use hCards. Do you mean to say if there is only one job title/position that we shouldn't or don't have to use an hCard to mark up the title? I didn't word that well. I should be more like, 'to express one or more...'. thanks, ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hlisting discussion Wednesday night
transaction: sell | rent | trade | meet | announce | service I don't understand the use of 'service' as a transaction - it seems more like the thing sought after or being given away (the thing 'exchanged' for some other thing of value). ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
