Re: the term microformat and encouraging people to play (wasRe:[uf-discuss] Comments from IBM/Lotus rep about Microformats)
From: Tantek Ç elik [EMAIL PROTECTED] The term nor site microformats(.org) did not bring about a new category. The category pre-existed: semantic (X)HTML. microformats is the specific brand (your term) of semantic (X)HTML that follows the microformats principles and process. You could say that RDFa is another brand of semantic (X)HTML that follows its own principles. Unfortunately, the use of a 'generic' term such as microformats turns it into a 'category', because categories are created by (all the others out there) others and inspired by products. Rather than us extending this debate, I might suggest that you file this away as the reason for the confusion. Solutions are entirely upto you and if you need further reading, besides al ries I might suggest you could also see seth godin's comments on podcasting rss http://sethgodin.typepad.com/seths_blog/2006/06/being_brave_wit.html S. Sriram ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
From: Ryan King [EMAIL PROTECTED] On Dec 5, 2006, at 8:48 AM, S. Sriram wrote: From: Mike Schinkel [EMAIL PROTECTED] http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006- December/00 8462.html I wonder if his issues can be addressed? How about a distributed parser-discovery service What's wrong with GRDDL [http://www.w3.org/2004/01/rdxh/spec]? Nothing. Except that in this case it introduces yet another parsing burden on the browser/renderer i.e. from rdf/xml to JSON or other renderable format. S. Sriram ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
From: Mike Schinkel [EMAIL PROTECTED] S. Sriram wrote: This is not a scarce resource, people can (and are) naming classes as they choose. Any constraint happens at the parsing stage, since microformat-aware parsers look for specific class names etc. (see below) If it is not a scarce resource, please tell me what would happen if I decided to start marking up documents, as an example, using the class directory and license, for purposes other than rel-directory and re-license? How could my markup and those Microformats co-exist in the same HTML document? They would simply co-exist. Period. Hypothetically, say the author uses rel-license for some internal markup and has unwittingly cut/pasted in a uf-snippet containing a rel-license tag. The consumer of this microformat will now be presented with spurious/confusing data. How different is this from a web page (today) that contains a rel-license entry which was not intended to be a microformat in the first place. Not much. This too will lead to a spurious/confusing interpretation if consumed as a microformat. But, is that not what ALL current usages of this are and is that not how microformats even chooses these terms by sifting through the way people actually use them. In other words, just finding a markup on a page that resembles a microformat 'does not necessarily mean that is is one'. This is true today. The burden of interpretation is on the consumer not the author. Now, if the argument is that authors are 'constrained' in their class naming freedom, and have to avoid the usage of rel-license altogether (unless used as specifically noted by microformats.org) since microformats have 'squatted' on it. The response is NO, you are not constrained, as the burden of interpretation falls on the consumer of the microformat and not its author. As for multiple namespaces and a bureaucracy to govern that, it is highly unlikely. What is more likely is a white/blacklisting mechanism if spammers etc. begin wide use of it, much the same way blogs are being white/blacklisted. S. Sriram ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
From: Bruce D'Arcus [EMAIL PROTECTED] The issue isn't really microformats vs. RDF (except as RDF provides a model), but microformats vs. RDFa. [snip] So while it might be comforting to dismiss RDFa and it's not our problem, I don't think it's good strategy. I agree.. Parsing Per [1] RDFa is akin to a language for microformats, as opposed to the current microformats which are a 'particular' defined set of class names in a defined order. A 'language parser' could parse all combinations of 'syntactically' correct RDFa, whereas with microformats each particular format requires a particular parser. Rendering Now when it comes to rendering the 'parsed output', knowing what the parsed output is, is necessary. This is where the need is to understand the 'particular output' *OR* have a generic container (an hItem or a micro-microformat for an item) so all-purpose renderers can view 'unknown/particular' parsed output as a blackbox. Distributed parsing Allows for custom microformats to be developed with their associated custom parsers and the output passed to the rendering engine. (possibly discovered by distributed rendering) Note: This does not need any 'approval process' as all publishers are free to do this today i.e. build a custom microformat, markup their pages appropriately, build a browser plug-in that understands this and build a cutom renderer. In other words, in the absence of a language parser (which can parse all combinations of a syntactically correct RDFa) the other way to accomodate custom microformats (elias's need) is through distributed parsing. Another way to look at it is that microformats (with defined formats == known rendering) are aggregator-friendly, where RDFa and distributed parsing/rendering are more user/institution friendly which may explain where google/technorati(aggregator) v. ibm(institution) are coming from. My own feeling is that a model which includes both 1. a uf-language (RDFa) and 2. canned formats (microformats) allows for greater flexibility, with canned formats allowing for aggregators/multiple tool vendors, where custom format developers would have the burden/opportunity of rolling their own renderers. [1] http://www.w3.org/TR/xhtml-rdfa-primer/ S. Sriram ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
From: Scott Reynen [EMAIL PROTECTED] So while it might be comforting to dismiss RDFa and it's not our problem, I don't think it's good strategy. A good strategy toward what end? I think Elias has a problem that microformats are not intended to solve. What he wants to do is have a generic semantic model that anyone can use with any type of data, and put it in HTML. What microformats are intended to do is provide specific semantic models, not just /in/ HTML, but using the familiar tools of HTML as much as possible. That's right, I think that what RDFa does is hint at realising the potential that microformats (in general) offer (to institutions), which 'microformats.org' with its inherent (and probably valid) limitations stops short of. Maybe, thinking of RDFa as microformats (in general) and microformats.org/microformats as microfortmatted-objects (in particular) might help understand this relationship better. S. Sriram ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
From: Mike Schinkel [EMAIL PROTECTED] http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-December/00 8462.html I wonder if his issues can be addressed? How about a distributed parser-discovery service More specifically a YADIS discovered JSON returning uf-specific parser: 1. Place an entry on the uf-authored page detailing the ufs-used meta name=ufs-used content=hreveiew hatom hwidget / 2. Place a yadiservices discovery pointer to where parser(s) maybe found, (on the same uf-authored page) meta name=ufs-used content=hreveiew hatom hwidget / meta http-equiv=X-YADIS-Location content=http://www.blahblah.com/path/to/yadis-file; / 3. add parser service data to the (existing) yadis file pointed to within the uf-authored page. ?xml version=1.0 encoding=UTF-8? xrds:XRDS xmlns:xrds=xri://$xrds xmlns=xri://$xrd*($v*2.0)XRD Service Typehttp://openid.net/signon/1.0/Type URIhttp://www.livejournal.com/openid/server.bml/URI /Service Service Typehttp://microformats.org/hreview/1.0/Type URIhttp://www.blah.com/path/to/uf2json-parser/URI /Service Service Typehttp://mysite.com/hwidget/1.0/Type URIhttp://www.mysite.com/path/to/uf2json-parser/URI /Service /XRD/xrds:XRDS 4. ..domain../path/to/uf2json-parser is a REST-call that is passed a 'uf-snippet' and returns a JSON object. Browsers that are uf-aware would call the parser with the uf-snippet, and than hand of the JSON to the storing module. CONS: The parser needs to be 'hosted', incurring bandwidth costs. PROS: Roll your own microformat and parser - or - *leave your html as is and just build a parser for it and point tothe parser from within the page.* S. Sriram ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
From: Scott Reynen [EMAIL PROTECTED] 2. Place a yadiservices discovery pointer to where parser(s) What you've described above is a process for converting all microformats to JSON, but that doesn't really solve the problem Elias described. It just changes the format. Each individual parser still needs to figure out what the JSON means, where before they had to figure out what the HTML means. In point of fact it exactly solves elias's problem in somewhat the same way that inline RDFa does. Because of the key-value pairs retuned by JSON. Take Elias's hCard example [1] with the need for additional attributes i.e. blog-url, activity-url etc. and the inability to 'add new properties' to an existing microformat. In the distributed parser model, the returned JSON would allow all uf-aware-browser-apps to look only for hCard data and allow 'uf-aware-special-browser-apps' to seek out the additional attributes i.e. blog-url etc. satisfying elias's need. In other words by looking at parsing/rendering as two seperate and distinct steps, with ditributed parsing one can accomodate 'generic' formats and 'custom' formats and one can accomodate 'generic' rendering and 'custom' rendering. One could also in theory extend the YADIS service to offer a uf-rendering service, so a browser could look at uf-authored page, send the uf-snippet to the 'discoverd' uf2json parser, and than send the json to the discovered 'uf-json-renderer/storer'.etc. [1] http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-December/008500.html S. Sriram ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformat Base
From: Craig Ogg [EMAIL PROTECTED] On 12/1/05, Scott Reynen [EMAIL PROTECTED] wrote: I thought I'd go ahead and play around with a microformat-based alternative to Google Base. So far, I have a basic spider that I set loose from microformats.org to slowly wander the web. When it finds any known microformat-associated class names, it records the data which can then be searched here: This is very cool, but I don't think it is really an alternative to Google Base. As has been pointed out in some of the proposals for a discovery format here, to have to spider a web site to discover its data is not very efficient or accurate. I think microformats offer much more potential to aid adhoc discovery and use of information while you are browsing: drag this event to my calendar, add this person as a contact in my address book, give me driving directions to this location, give this blog post proper via credit, etc. Having this built-in to Firefox or Flock I think would be very cool. Craig P.S. I realize that rel-tag is being used to aid search already -- but I think it is being almost exclusively consumed from RSS feeds. Probably for the efficiency reasons stated above. Well put! this is the realization that has been dawning upon me i.e. the future format of web-data would not be centered around microformatted HTML but rather the RSS item overlaid with namespace attributes - to use your insight - in a sloppy user-friendly format. And just as users 'tag' items with labels of their choice, they would markup feed items with namespaces of their choice and search accordingly. Consensus attributes would evolve between peer groups and voila the future of the data-web. (The other development that will help nail this is the advent of SSE in OPML.) The micro micro-format for an item that I've been talking about effectively remains the item enclosure in an rss feed. Microformats(.org), will remain - as you point out- the manner in which highly specific data sets (meant for rapid user consumption, typically in browser environments) are painless-ly transferred. (bookmarklets, greasemonkey, ajax, flock etc.) To this -as you add- microformats will also assist ordinary users to augment their input such as what rel-tag does right now. Loosely speaking 'linkspeak' So microformats will be used for, - adding an event to my calendar - adding a contact to my address book - .. - adding a 'specific dataset' to my 'client' (stuff html-savvy programmers would undertake) and - linkspeak (rel-tag etc.) (stuff marginally tech-savvy folk could undertake) Searching the wild web, will not be by spiders crawling web pages and ferreting out microformats but rather whole-text as in current vogue and from within RSS feeds with namespace attributes (your Open Search + google base scenario) and 'linkspeak' So, I'd ammend my earlier suggestion of -'Open Base' as a microformats response to 'google base' to - microformats has really no response to google base because the vision of a semantic web, where folks post their wants to a web page that gets spidered and searched by the world seems likely to fade behind the vision of a semantic web where folks who want to share their content will do so by exposing it in RSS feeds for searching by the world marked up in a babel of xml namespaces that their clients output. If anything, a map between microformats and googles namespace declarations at http://base.google.com/base/base.xsd could be considered. Thanks S. Sriram ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
