Re: [uf-discuss] Hidden metadata no microformats
http://tantek.com/log/2005/06.html#d03t2359 Principles of visibility and human friendliness. One question invisible metadata raises is if it's not worth seeing, why is it worth publishing? -Ben On 6/30/07, Andy Mabbett [EMAIL PROTECTED] wrote: Several editors on Wikipedia are calling for the modification of the templates which implement microformat, to use hidden metadata. I thought there was a prohibition on hidden metadata in the specs, or at least somewhere on the wiki, but all I Can find now is: visible data is much better for humans than invisible metadata on: http://microformats.org/wiki/microformats#the_microformats_principles Can someone remind me what I'm missing, please? -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Hidden metadata no microformats
On 7/2/07, Patrick H. Lauke [EMAIL PROTECTED] wrote: Benjamin West wrote: http://tantek.com/log/2005/06.html#d03t2359 Principles of visibility and human friendliness. One question invisible metadata raises is if it's not worth seeing, why is it worth publishing? Because tools/extensions expose them to end users in a way that is far more user/human friendly than merely making the raw metadata visible. Whether or not authors forget to update the metadata, or purposely try to game it, if it's not visible is an authoring/policy issue, not a technical issue that should be solved by a language's specification (because some bad people tried to do bad things with it, we're just not giving you the opportunity, full stop). P -- Patrick H. Lauke I'm not sure what you mean. We aren't talking about raw data. We are talking about data that has been marked up. In addition, no one has said there is some kind of mutually exclusive relationship between authors of visible vs invisible data. FWIW, nothing in microformats actually prohibits invisible metadata. It's certainly possible to set display:none. In fact, the phrasing quoted by Andy was visible data is much better for humans than invisible metadata. -Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: hCard history and extensions (was Re: [uf-discuss] Date of Death in hCard)
On 6/28/07, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes For some of these I see quite a bit of utility (e.g. gender is often used in social network searches - an actual application in common use), whereas others seem to be merely driven by sense of semantic publishing completeness (e.g. date of death) and not by existing applications. On the contrary; you have been presented with evidence *and* use cases for date-of-death more than once; not least in the first post in this thread. Andy, I'm not sure which evidence you are referring to. All I noticed was a a sum of google search results. We've previously discussed using search engine hits as evidence. Can you reiterate which URIs were surveyed along with an analysis of the markup used? It would go a long way towards providing evidence for this feature. How are people currently publishing dates of death? Who is doing it? Are there common authorship patterns? Finally, any time you find yourself (or anyone else) arguing a positive from the absence of a negative, please call it out as a logical flaw. I.e. statements of the form: I can see no good reason why ABC should stop XYZ ... do not provide justification for XYZ. Allow me to correct myself: The justification for the hCard on that page including his date of death (and places of birth and death, for that matter) is not negated by the historical, almost accidental, relationship of hCard with vCard. I'm not sure the lack of negation or an objection is a good reason to decide on property names chosen without evidence. -Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
documenting techniques: Re: [uf-discuss] Logging information
On 3/15/07, Rob Crowther [EMAIL PROTECTED] wrote: On 14/03/07, Scott Reynen [EMAIL PROTECTED] wrote: There is currently no microformat for that specifically, but it looks like what you're logging is an event, so you can probably publish it with hCalendar: I was thinking it was more like hAtom: http://microformats.org/wiki/hatom Since that has all the elements of hCalendar plus it has a category and also author which might conceivably be the server name. Plus hAtom seems more like the concept of an event log - ie. there's an implicit association between the events. Rob This is great advice from both Rob and Scott. I think documenting techniques should be a successful goal for the microformats community (because it helps to document the need, or lack thereof, for new formats). I couldn't find a great spot on the wiki, so I satisficed on -advocacy#hatom: http://microformats.org/wiki/advocacy#hAtom. Thanks, Ben West ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Formatting arbitrary dates, not part of hCalendar
This is all relevant to existing specific-purpose date-time properties, [snip] What exactly would we want to do with a generic date apart from any specific context? Well, blog posts and articles online come to mind. They're normally dated, yet there's no convention that states that this is how you should date an article. Rather than debate, why don't we just ask Bob for more information about what he's trying to do? Bob: can you give us some more examples of what you'd like to do, not just request a specific technique? As far as periodicals, we already have hAtom http://microformats.org/wiki/hatom which includes mandatory dates. Blogs and articles, and other similar content, is can be marked up using hatom. As far as screen readers go: can anyone name some of the more popular screen readers so we can involve the authors in the semantic markup dialogue? Thanks, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: hCalendar property list (was Re: [uf-discuss] Formatting arbitrary dates, not part of hCalendar)
Question: would the community be ok with a draft approximate property list for hCalendar sooner than a comprehensive precise property list later? My standards/implementation instincts had biased me towards the latter, but I realize that in many ways, ironically, that's actually contrary to much of the methodology for how we get things done in microformats in general. Tantek Yes, having started an incomplete list is better than not having any list. The question in my mind is: how will people know if they are looking at a draft list or a comprehensive and precise list? If you publish an incomplete list, others will be able to help out, but everyone will need to know what defines completeness. -Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] User Groups
Hi Thom, On 2/22/07, Thom Shannon [EMAIL PROTECTED] wrote: I'm trying to come up with a way to join the huge network of user groups out there and make it easier to find user groups in your area. Sorry, I'm a little confused: what network of user groups? What's a user group? The obvious solution would be to create a website where people go and add their group. I can't imagine if I setup such a site the take up would be that huge, plus the data would quickly get stale. I think you're on the right track here... a decentralized mash up would be better and cooler. My problem is that I'm not sure how to come up with the right convention to start promoting, is a tag like usergroup a good idea? There are very few examples of people using it, but I can't find anything else specific that's used much. I'm still a little confused on the overall idea. However, it sounds interesting. Developing a convention/technique sounds like the right idea. I would suggest not looking for people using usergroup as a tag. I would suggest looking for examples of people doing similar use cases. Perhaps you could elaborate a bit more on the use case you are trying to facilitate? -Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Planet microformats (Was: Plant Microformats)
http://planetmicroformats.com/ At the moment it is just an aggregation of several other sites based on microformats. Any and all feedback is welcome. It is pretty crude at the moment, but in the style of microformats it is better to get something out and itterate on it rather than try to get it perfect the first time. Nice. I notice that apostrophes are coming out as question marks. Very good idea. Good idea. Personally, I think I'd find it more useful if it were more like the other planet sites I've used, which tend to pull from individual sources rather than aggregators. The signal:noise ratio is just too low to actually read everything tagged microformats on any of the aggregator sites. I'd say keep microformats.org, lose everything else, and add some of the individual sources discovered through the aggregators. Peace, Scott I'm also a little wary about the signal:noise deal. However, there don't seem to be too many currently, so I disagree for now. I'd suggest a two column layout ala http://useit.com/. The right column could go under the heading Microformats Around the World or something, might be a smaller type face, but otherwise containing pretty much the same information currently available: source, title, link, date published, and one or two lines. The right column could be dedicated for more permanent, vetted sources, similar to other planet sites. Typeface could be bigger, approaching the size currently there, with same information, but maybe a few more lines. At first, I suggest allowing the right column to be a bit more dominant, until we collect a satisfactory amount of high value sources. This strategy allows for an adaptive approach that amplifies the voices of all authors talking about microformats, yet also ensures that known, high-value authors are easily accessible. -Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Tutorial on AHAH (such a cool technology!)
I disagree. You should be practicing accessible, progressive
enhancement.
Agreed, so I don't think we're in disagreement. This was the reason
for my comment.
The first example does have a URI, it's the relative
path to Waldorf-Astoria-Photo.html and should be set up to work from
a spider, script disabled browser, or even a right-click to open
link in new tab.
I'm not sure if people are missing it or what... so here it is again:
---
href=javascript:ahah('Waldorf-Astoria-Photo.html','Photo');
This is a link only browsers with javascript can possibly understand.
My point was that if you don't intend to send the user somewhere, you
shouldn't use an anchor.
Your practice of wiring javascript to a button is
effectively hijacking the user's browser will do nothing except
ensure the content is inaccessible to all but a few targeted user
agents.
Perhaps. Or my suggestion reinforces the concept of using a button
when you don't intend to send your visitors to another page, instead
of a link.
a href=Waldorf-Astoria-Photo.html class=ahah-photophoto/a
I agree this is a better suggestion in this case /if/ the intent is to
provide a fallback to take the user to a new page: something not
possible in the original example. However, the intent to not send the
user to another page isn't something you can fix with progressive
enhancement.
Works as a regular link and–once the right event handlers are
assigned–will work as a JS-enhanced interface.
James
Thanks for pointing out the better solution.
Ben West
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Tutorial on AHAH (such a cool technology!)
Roger,
Neat stuff. I thought it was pretty good, but take some issue with the
following:
a href=javascript:ahah('Waldorf-Astoria-Photo.html','Photo');photo/a
The best practice is to wire the event up, and to use a button when
the element is not truly a link.
Something more like:
button onclick=ahah('Waldorf-Astoria-Photo.html','Photo');photo/button
or even better:
button id=photo_changer type=button photo/button
script type=text/javascript
// must be done either after onload fires or after the element appears
in the DOM...
// find the element.
photoButton = document.getElementById('photo_changer');
// wire up the event.
photoButton.onclick = function () {
ahah('Waldorf-Astoria-Photo.html','Photo');
};
/script
-Ben
On 2/10/07, Costello, Roger L. [EMAIL PROTECTED] wrote:
Hi Folks,
I have created a tutorial on AHAH (Asynchronous HTML and HTTP)
http://www.xfront.com/microformats/AHAH.html
Comments welcome.
/Roger
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Should microformat features (like rel-tag) have explicit scope?
On 2/7/07, Ryan King [EMAIL PROTECTED] wrote: On Jan 31, 2007, at 7:07 PM, Derrick Lyndon Pallas wrote: If I have a parser that only knows (and only cares about) the rel- tag format, it will be confused by people that use rel-tag for the category property in hCard. It seems unreasonable that every microformat should have to know about every other microformat, especially when they are nested. Actually I think it *is* quite reasonable to make parsers know about every microformat. Microformats are designed to be easy to publish, even when that means that they're hard to parse. Simple economics show that it's much more valuable to make publishing low-cost, because the increased in published data will allow you to amortize the cost of writing and maintaining parsers across more transactions. Also, microformats are not designed to be generic or open ended, but specific solutions to specific problems. Requiring authors to add markup in order to make rel-tag's scope explicit makes it hard to publish the data and doesn't solve any real problem. No one has said anything about any required mechanism, except for the unreasonableness of requiring a parser to know about every possible semantic available for a given encoding. The point is that the rel-tag spec lays out a contract: http://microformats.org/wiki/rel-tag#Scope Scope rel=tag is specifically designed for tagging content, typically web pages (or portions thereof, like blog posts). ...that seems to contradict itself... If you need to define tags as part of a more specialised format, rel=tag is the recommended way to do so, and xFolk, hReview, hCard and hCalendar all do this. The assumption here seems to be that when a microformat appears on a page, the subject matter of the microformat is highly correlated with what the page is about (whatever that means...). The justification given for this assumption is the historical record for real publishing, and by concrete example, the book publishing industry. If this assumption is true, then the subject of the rel-tag is largely a non-issue. It's hard to swallow this assumption, because it seems possible, and highly likely, that authors' intentions are different. As an author, it would surprise me to learn that the categories I specify to describe my friend would also be understood by a parser to describe the page itself. This creates a mismatch between the functional model and the mental model of the author, and possibly other human consumers as well. (Human consumers aren't going to consider the page a subject of contained rel-tags, either...) When I explicitly publish a piece of information, I expect it to be interpreted within that context. When other behaviour creeps in, the integrity of my authorship becomes brittle. I agree with Ryan that this is an authorship issue, and disagree that it's not an issue. Authors should know that any rel-tag useage could be applied to the page as a whole. This isn't made clear in the formats that reuse rel-tag. Currently, rel-tag is difficult to use as a publisher, because the subject the tag applies to has become modal. Either we need to remove the modal nature of the subject, make it explicit, or provide a mechanism to control it. -Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] New new mailing list
Would it be worthwhile to draw attention to this list on the blog for those that only follow that, or get just the digests? F -- Frances Berriman http://fberriman.com Frances, Good idea. MF blog: http://microformats.org/blog/2007/02/08/new-mailing-list/ my blog: http://bewest.wordpress.com/2007/02/07/microformats-new-mailing-list/ -Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] New new mailing list
On 2/7/07, Michael McCracken [EMAIL PROTECTED] wrote: So, is the microformats-new mailing list now the appropriate place for discussing hCite development? Thanks, -mike Good question. My personal opinion is that we should kind of grandfather older stuff, while encouraging newcomers with new ideas to the -new list. I think some others will have other opinions. My feeling is that hcite should remain here; because hcite discussion has always happened here, it would be inconsistent to suddently switch venues. It's kind of confusing, which is why I never liked the name -new to begin with, however it did win the votes. -Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats, WebApps 1.0 and UI widgets in browsers
The specific class names are root class names. Non-root class names
(e.g. title) only make microformats sense if they're under the DOM
tree of a root class name. The root class names have been chosen not
to conflict with known existing uses [1][2].
Regards, etc...
David
[1] http://microformats.org/wiki/naming-principles#Unique_Root_Class_Names
[2] http://microformats.org/wiki/hcard-parsing#root_class_name
--
David Janes
Exactly. In other words, instead of looking for an invisible profile
attribute, or some marker in an ancestor, when a top level container
is found, required properties are tested in order to determine whether
or not the element represents what we think it is.
instead of:
function isMicroformat(element) {
// returns a boolean representing whether or not the given
// element is the root container of a microformat
return isRootMFContainer(element);
}
the problem is solved by:
function isMicroformat(element) {
return isRootMFContainer(element) hasRequiredProperties(element);
}
This (feature detection) is (or is becoming) a standard idiom that
many javascript developers are familiar with, thanks to sites like
www.quirksmode.org.
Ben West
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Moderation Governance
* http://microformats.org/wiki/faq#Q:_Who_controls_microformats.3F * http://microformats.org/wiki/issues#Governance_Issues I would also like to revive the idea of a meta-discuss list to handle governance and other non-technical issues. This appears to be off-topic for the current wiki page on mailing lists for new micorformats: * http://microformats.org/wiki/mailing-lists-proposals#microformats-meta So, can anyone suggest the appropriate venue for proposing/discussing that? -- Ernie P. Ernie, Thanks. I think you nailed it. Let's try to keep -discuss on-topic. Issues can go on either the to-do page or on http://microformats.org/wiki/issues#Governance_Issues. Joe, There are people on the -admin list who are not considered admins. These include service providers and other influential contacts. In addition, Ryan and I have had conversations about how the admins are cautious to make changes without seeking feedback and corroboration with others. This includes not [mis]representing others, which I believe Scott was doing. However, this also means that there won't be any broad sweeping changes overnight. I can assure you that all of the admins will be apropriately listed on the wiki page. Until that list is complete, my original suggestion remains: you can create the list of active admins by looking at the IRC logs. If you can be persistent in your criticisms without resorting to hyberbolic imagery, it would allow, at least, me, more strongly consider your points. As for the policing metaphor, it's simply not true. There is no policing of the list that I'm aware of. Andy's moderation was a public decision, as have all the other decisions I'm aware of. Voting for many things takes place on the wiki. If you feel that there are policies or information that are unclear, I encourage you to ask about them, or perhaps bring them up on the issues page mentioned earlier. Finally, I'd like to encourage posts to this list to remain on-topic, lest we devolve into senseless bickering. Thanks, Ben West ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Moderation [was RE: [uf-discuss] Andy Mabbet's moderation]
On 2/2/07, Martin Owens [EMAIL PROTECTED] wrote: On 02/02/07, Scott Reynen [EMAIL PROTECTED] wrote: I don't believe anyone has said they are only willing to participate in the -admin list secretly. But a few haven't said anything at all, I assume because they're busy people. I expect they'll be happy to add their names to the public registry when they get around to checking their email relating to the volunteer position. Or maybe they'll see you've been calling them secret police with a connotation [1] that they would take someone away in the middle of the night to be murdered, and decide it was a mistake volunteering in the first place. Either way, give it a little time and I expect the published list will soon reflect everyone on the list. Perhaps some sort of page explaining not only who is in a restricted group, why and how other community members can join may also be information that would put fears at ease. Do we have admin minutes? cat we read the logs for -admin? all of the interactions within the administration of an organisation even a sudo one need to be made public where they interact with the public. A page dedicated to who is banned, moderated, for how long and _why_ might be helpful too. Best Wishes, Martin Owens Martin: You make some good points... Can you add it to the -issues page described by Ernie? http://microformats.org/wiki/issues#Governance_Issues Thanks, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Moderation [was RE: [uf-discuss] Andy Mabbet's moderation]
Moderation is a form of punishment, whether it is seen that way by the cabal or not. It ostracizes the moderated and prevents them from participating in the community like everyone else. In this case, it has made Andy a second-class uF citizen whose posts are censored in an ill-defined, unchecked process run by unnamed moderators. I say unnamed because although we know some of the moderators, unnamed others have apparently joined the effort as a means of spreading the governance beyond the founding cabal. That's progress, but these new volunteers have remained anonymous. Kind of like the secret police, really. Joe, I'm having trouble gauging how serious you are, because this interpretation of events is so different from how I, and I believe others, percieve the same events. The -admin list discussed what to do and the proposed actions were disclosed to the public. The fact that he was moderated instead of banned was due to community input. All actions taken were clearly taken by Tantek, who has always been an influential leader in this community. What part of this is secret? The community did have a say in what happened, and Tantek executed exactly that plan. Since this censorship judgment was issued by dictatorial fiat at a point when Andy was agitating over governance issues, I found it particularly disingenuous. Again, this is an interesting interpretation. The actions were discussed on the -admin list by a worldwide group of volunteers. The results were disclosed on the -discuss list. The community gave feedback on the results. This didn't happen because Andy disagrees, it happened because of his behaviour while disagreeing. That it has continued as long as it has only buttresses my concerns about governance. Obviously, the cabal has the power to do this thing. However, I remain unconvinced that this instance is not simply an abuse of that power. I would appreciate it if someone could forward me the bad posts that have justified Andy's continued moderation. In the face of the good posts, there needs to be some non-zero level of bad posts to justify continued moderation. Perhaps there is merit to the moderation. If so, I think it is appropriate for evidence to be shared with those in the community who care to review it. Or, if taking Andy off moderation has simply been overlooked, ok. Mistakes happen. In which case he should be allowed to post normally and we should remember as a community that we don't have the wherewithal to manage fine-tuned corrective procedures. Again, Andy has been extremely helpful during his moderation, and the posts that cause negative influences in the community, personal attacks, and list membership to drop have ceased entirely. There was a limit set on the ban, but no such limit was proposed for the moderation. All evidence suggests that moderation is working. Thanks, Ben PS. There hasn't been many formal announcements regarding governance issues for several reasons. One reason is that the group is fairly conservative about making changes and being an official voice. Another reason is that we are simply more interested in doing actual work and making progress than dealing with meta-discussions about governance. While I expect this is an area we might improve in, if you are interested in finding the list of admins, you can deduce this list by looking at the admins in the IRC channel. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Fwd: [uf-discuss] Species microformat process
I accidently sent this to just Andy, when I meant to send it to the list. Oops. Anyway, I think the input others have had on this thread is very good, and I look forward to seeing the results. -- Forwarded message -- From: Benjamin West [EMAIL PROTECTED] Date: Jan 31, 2007 9:28 AM Subject: Re: [uf-discuss] Species microformat process To: Andy Mabbett [EMAIL PROTECTED] To be honest, the use case for the species microformat is a little bit weak. In what way do you think it could be weak? What information do you think is lacking? It's not clear what the problem is. The statements refer to a future filled with software agents that know where to search. Most of the examples you collected exhibit a hyperlinking behaviour to link the name being referenced to a more substantial article on the subject. It's not clear why a new format is required because it appears that the problem can be solved with either simple hyperlinking or with some clever application of rel-tag. It could be that if there is a lack of demand, it is due to the weak use case and the gap between the research and the proposal. In what way do you feel there is a gap between the research and the proposal? How do you fee that the two could be more closely linked? The proposed format doesn't bear any resemblence to publishing behaviour in terms of the content and properties being published. The markup also does not resemble current publishing practices. Why would you want to differentiate between two types of publishing? How would you decide where to draw the line? Right tool for the right job. Publishing behaviour would draw the line. Different types of publishing may or may not need different techniques for doing so. Ben West ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Moderation [was RE: [uf-discuss] Andy Mabbet's moderation]
Hehehe. Sorry. I was merely suggesting that method because it is accurate and public, if a bit tedious. We're working to correct that at http://microformats.org/wiki/faq#Q:_Who_controls_microformats.3F. Thanks, Ben (BTW, there are coffee recipes intended to be consumed via non-oral means.) On 2/1/07, Christopher St John [EMAIL PROTECTED] wrote: if you are interested in finding the list of admins, you can deduce this list by looking at the admins in the IRC channel. Thanks a lot. I was drinking coffee when I read that, and I ended up spurting some out my nose. I can tell you one thing, hot coffee is definitely not meant to be taken nasally. Just when I thought this thread as entirely humorless :-) -cks -- Christopher St. John http://artofsystems.blogspot.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] microformat proposal: dependancy graphs (for software)
Hey Derrick, I think you are on the right track with regard to process here. I especially liked the in-depth treatment of the problem statement, with specific examples that came in addition to (instead of soley) your own frustrations. It also seems like you've looked over how to gather examples, so I'd like to encourage you to continue with this effort. There are a few things I'm a little concerned about. For example, who would consume this microformat? Many of the existing microformats have centered around end-users as potential consumers. However, I'm not sure the average person has an interest in consuming software information. I'm not sure what impact this might have on the would be creation and subsequent adoption of your proposal. Documenting and codifying existing publishing practices is a worthwhile effort, so it may not matter. You seemed to hint on how this technique might be adapted to other areas in some of our hallway conversations. Are there other practical problems that might be solved on a lower level, or would this technique map directly into other problem domains? I also liked how you mentioned how your proposed microformat would work in conjunction with other microformats to compose a larger system. I'd like to hear more about this vision because it sounds interesting, and may inform developments in other microformats, or inspire would-be extension authors. Would you mind starting a wiki page, as described in the process? http://microformats.org/wiki/process. What do you think the name should be? Something like versioning-examples? softwaredependency-examples? version-resolution-examples? What would the most apropriate name be? http://kernel.org/ * uses link to provide RSS feed * div id=versions uses word versions * uses links to deliverable with version string as anchor text * uses a kind of product/software id (my made up term) table class=kver to identify the thing being described * includes a description of the software * includes the date published * uses keywords as anchor text to perform operations or view additional features. for example, V for view diff, changelog to see the changelog, etc... http://libpng.org/pub/png/libpng.html * LINK REV=made HREF=http://pobox.com/~newt/greg_contact.html; Interesting. made by his guy :-). hcard would seem to be a perfect fit here. * Blibpng/B name of software in an element * A HREF= http://libpng.sourceforge.net/;http://libpng.sourceforge.net//A link to homepage * requires Bzlib 1.0.4/B or later (B1.2.3/B or B1.1.4/B lossy markup of requirements * The current public release, Blibpng 1.2.15/B again, lossy markup * includes a description of the software * Blibpng 1.2.12/B another mention of the software in it's own element * the site contains links to test suites, documentation, and download links * also includes a description of how to verify the contents * lots of content about the software, but very little semantic markup. good example: easy to see how some semantic techniques would help. would marking this up using hatom help at all? http://freshmeat.net/projects/libvc/ * uses link to an rss feed * links to other project areas... issue tracking, forums etc... * branch info published * date added, created, modified all published * description * author * trove categories * might list dependencies, but there are none for this particular example * stats listed: vitality, popularity, downloads, graphs... * hits, subscribers * other projects depending on this one are listed * license published * download links provided * no semantic markup present. http://raa.ruby-lang.org/project/fcgi/ * link and meta used to convey authorship, made, author, and some other attributes: search, index, home, glossary * interesting, there is some semantic html... p class=captionfcgi / 0.8.7/p table class=entry * key value pairs (in a table) for: short description, category, status, created, last update, owner, homepage, download, source vieweing, license, dependency, versions as link text to the deliverable with date published outside the link * uses address to list contact for the document, and other uses of semantic html such as class names footer, header, and caption. Shows a receptivity to semantic techniques as well as confirming the list of properties published by software vendors. http://www.gentoo-portage.com/dev-lang/erlang/Dep#ptabs * link to rss feed * body id=gentoo-portage intended consumer published in markup * links to other project areas * h2 id=packageiddev-lang/erlang /h2 product name * h5 used for description * div id=website_listul.../ul/div used to list project websites * div id=ebuild_listul... used for consumer-specific parameters * view and download links. * h3Runtime Dependencies/h3 dependencies published using div class=depbox with links. * =a href=/dev-lang/perldev-lang/perl/a-5.6.1 * the previous behaviour is used for each version of the published software Lots of semantic html. Could be clues for possibles
Re: Vote on this: rel=me self to indicate an authoritative hCard {was: Re: [uf-discuss] Authoritative hCards [was RE: Canonical hCards (was: Search on CSS element)]}
I'm trying to catch up, but I'm finding it a bit difficult. The problem with rel=me is that it's merely an alternative version, and not authoritative or canonical, right? Why is rel=me self desirable though? Were there any other alternatives considered? Thanks, Ben West On 1/31/07, David Janes [EMAIL PROTECTED] wrote: On 1/31/07, Ben Ward [EMAIL PROTECTED] wrote: We are voting only on the use of @rel=me self to reference an authoritative hCard that parsers should follow. e.g. div class=vcard a class=fn url href=http://ben-ward.co.uk/about; rel=me selfBen Ward/a /div Just to be 100% pedantically clear: (Part I) If Ben puts this on his home page, parsers look at http://ben-ward.co.uk/; will know to look for an authoritative hCard because of these two things: 1. there's a vcard 2. it has a url link with rel=me self (Part II -- implication) If Ben places a vcard on a random page with url=http://ben-ward.co.uk/;, a consumer can optionally look there to find an authoritative hCard. The 80-20 rule covers the case where we would want to have more than one authoritative hCard per page (i.e. it's not that common) (Part III - rel-self) We're getting the definition of rel-self from here [1]: self: the feed itself. It's a small stretch, but I just did some searching for counter-examples (i.e. where rel-self doesn't point to the best URI for a feed) and came up empty. (Part IV -- the word authoritative) I can't think of a better word. See definition 2 here [2] So +1 Regards, etc... [1] http://atomenabled.org/developers/syndication/#link [2] http://www.answers.com/authoritativer=67 -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://blogmatrix.blogmatrix.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Vote on this: rel=me self to indicate an authoritative hCard {was: Re: [uf-discuss] Authoritative hCards [was RE: Canonical hCards (was: Search on CSS element)]}
There is quite a lot of interest in this topic. With all the voices, it's becoming quite difficult to keep track of what we're talking about, and who thinks what. I've added this issue to the hcard-issues page. http://microformats.org/wiki/hcard-issues#Canonical.2FAuthoritative_Hcard I would greatly appreciate everyone filling out the details of this issue, as well as adding their opinion on this page. Hopefully the discussion will be easier to track. There seems to be enough interest to sustain this issue in a real-time chat on IRC. I invite all of you to continue discussion on the wiki and IRC so that more people can participate without getting hopelessly lost. Thanks, Ben West On 1/31/07, digital spaghetti [EMAIL PROTECTED] wrote: Just chiming in my two pence here: Rather than something like @rel=me self, would a better idea not be to look at including some kind of way of authenticating the source such as a MicroID hash? This has already been discussed on the MicroId list along the lines of this: @rel=me microid-mailto+http:sha1:hash (has being a full sha1 or sha256 hash), then services like claimID can then look at the tag, and convert back. If your registered ClaimID email address and the URI of the source match the hash in the rel tag, then the source is verified as being you? There are more details on the spec at http://microid.org/microid.html Tane On 1/31/07, Colin Barrett [EMAIL PROTECTED] wrote: On Jan 31, 2007, at 9:47 AM, Ben Ward wrote: My understanding therefore, is that @rel=me indicates that it is the same person. @rel=self indicates that it is the same hcard. Therefore the absolute authoritative hcard we speak of may (I expect will) contain other links with @rel=me but will not contain a link with @rel=self. This is what I understood. From here on, is a braindump: I'm still unsure of the original objection, which seems to be that @rel=me must be symmetric. XFN does not have the concept of one of those pages being more authoritative than the other, right? If we have the following page structure (bare minimum markup included for brevity): Document A: a href=B rel=me/a Document B: a href=A rel=me/a to XFN, both pages are equally authoritative, in that they represent the same author. XFN doesn't seem to care much about which one is more authoritative than the other, just that they are referring to the same person, and that's fine. Adding @rel=self is a proposed way of breaking this loop, and letting one settle as the authority: Document A: a href=A rel=me self/a Docment B: a href=A rel=me/a I think that would be the use case (judging by what Chris Messina posted)? The problem there seems that A no longer tells us anything about wether or not it recognizes B as another, valid source of information. Simply adding another URL with @rel=me doesn't seem like it would work though -- then the following case could occur: Document A: a href=A rel=me self/a a href=B rel=me/a Document B: a href=B rel=me self/a a href=A rel=me/a In which both A and B claim authority, and both link to each other as slaves, which leaves a parser in a strange situation -- now you don't just have two pages claiming to represent one person, but two pages claiming to be the authoritative source for one person. This doesn't seem like it would make a whole lot of sense. end braindump. Is this (one of) the issues being discussed? I'm basing a lot of this on Chris Messina's email to the thread, which was a bit unclear. If so, I wrote a second part to this (attempting to solve that problem), but decided to save it until I know wether or not I even have my assumptions in order. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] microformat proposal: dependancy graphs (for software)
I stumbled upon Danny Ayer's hDoap, which maps DOAP into xhtml. http://dannyayers.com:88/xmlns/hdoap/profile/hdoap-index.html This clearly doesn't capture the dependencies which is a big part of your use case. I'm interested to see how more real world examples pan out. -Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Species microformat process
On 1/30/07, Charles Roper [EMAIL PROTECTED] wrote: I'm very interested in the Species microformat, but the process seems to have stalled and I just wanted to poll opinion here as to why that might be. Is it due to a lack of demand? Charles, I don't know about demand, but I do know that many people have stepped up to participate in gathering research and analysis for species. Many of them have also been driven away. To be honest, the use case for the species microformat is a little bit weak. It could be that if there is a lack of demand, it is due to the weak use case and the gap between the research and the proposal. (The use case essentially describes a hyperlinking behaviour that is already present and used on many sites.) This is just my own opinion though. It seems that the successful microformats have been developed, in the main, by web designers and developers for web designers and developers. Could it be that web designers and developers of the microformats community do not perceive the value of a species microformat in the same way that they can see the value of, say, hCard, hReview, XFN, etc. The more successful microformats seem to be riding on the back of the social web zeitgeist, with many (most?) being used in this kind of context. I don't see species as being of particular interest to the bloggers and the other social-networking, mashup-making, digerati of current times. Is appealing to this demographic the key in getting a microformat developed? I'd appreciate the view of people in this community. If I think I know what you mean here, I disagree a bit. Who, what, when, how, where are all answered by these microformats. They are extremely common, and are probably the first data types to be represented by any new technology. For example: how old is the calendar compared to taxonomy? hcard describes who, xfn describes how are they related, hcalendar describes when Again, this is my own opinion, and I don't have any evidence. I also wanted to ask about the fundamental microformat principle of paving the cowpaths in relation to hCard. It seems to me that hCard was derived from vCard rather than being based on existing markup practice. How does this square up with the cowpaths philosophy? I'll leave this to others. However, I do think the kind of path vcard took is qualitatively different than the one species is taking. This brings me to a question about Species. The Species proposal doesn't really reflect current mark-up practice but instead represents what might be a good way of doing things in the future if authors were to start using it. I agree completely, and I think this is a problem with the current effort, but it's one that is solveable. The vocabulary in the proposal isn't plucked out of thin-air, though; it is taken from the taxonomic hierarchy as used by biologists. It seems to be modelled on hCard in this respect, hence my cowpaths question. My own feeling is that the current proposal is too complex. The current usage patterns as far as I can see (in the majority of cases) either have species names as plain text or marked-up with simple strong tags, or em or i. However, I'm not adverse to having a rich vocabulary of class names to call on should I need them (which 9 times out of 10 I won't), as long as a species name can still be marked-up very simply. This is similar to the way in which hCard has a rich vocabulary, but can still be very simple. Charles, this is a great analysis. This matches my observings, at http://microformats.org/wiki/species-examples-regrouped. I think the format would benefit greatly from taking a fresh look at the examples collected. It look to me like there should be two pieces. One should be the way authors mention species in text, the other should be how authoritative sources represent the information about a species. In any case, the first behaviour can be accomplished, perhaps entirely, by using tagging techniques. Perhaps the in-depth use of unambiguous names can be used by a second format intended for publishers of the authoritative information. Thanks, Ben West ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] wikia and hcard?
http://wikia.com/wiki/Collaboration_of_the_month/Genealogy/Blurb These folks just popped up on my radar, and I think there is a great opportunity here. I don't know too much about their requirements, but this is a quote from the web page: - Of particular importance is developing a simpified system for entering basic data about an individual. Individual articles vary in organization, but all person articles include certain basic data such as Date of Birth, Date of Death, Spouse, Children, etc. Because of the nature of genealogy the same data often has to be entered on several different articles. For example, a typical article includes a list of the person's children (a child list). That list usually includes basic information about the child, such as their date and place of birth and maybe spouse, etc. Eventually each child on the list may get a separate article as well. That article will include the same information as given in each parent's child list. Currently, that information has to be manually duplicated; what's needed is a system that automatically creates the child page, and then transfers the needed information from the parental page - as stand-alone genealogy programs have been doing for years. It can probably be done with text boxes, etc., but currently that doesn't seem to be a capability of the wiki programming. An extension is needed to add that capability. -- Sounds like a great use case for rel and hcard to me. Anyone have any idea what a prototype for this would look like? We already have hcard and rel creators, which might make a great starting point for someone. Ben West ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Re: Re: [uf-discuss] Conference Schedule Creator
Dmitry, Sorry about that. My work on the creators was 'approved' by Ryan King. I'm pretty sure he'll put it up there, but he's often busy. Ben On 1/7/07, Dmitry Baranovskiy [EMAIL PROTECTED] wrote: I am going to ask one more time: Who should approve it to push it on Code section of microformats page? I hope it deserve an honour to stand next to hCalendar creator? -- Best regards, Dmitry Baranovskiy http://dmitry.baranovskiy.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Splitting the FAQ?
I don't see any reason for splitting this. What is the problem and why does it need to be split? How would splitting solve that problem? It looks great to me as-is. Ben On 1/3/07, Andy Mabbett [EMAIL PROTECTED] wrote: The FAQ http://microformats.org/wiki/faq is getting long. I propose splitting it into two or more parts. Would that be OK with everyone? How should it be done? It might break some links :-( -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Splitting the FAQ?
I don't recommend splitting it. I'm not sure what too long means. My guess is that if you do make such a change, it'll be reverted. Ben On 1/3/07, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Frances Berriman [EMAIL PROTECTED] writes I read your email. I don't see your concerns outlined. Then I suggest that you did not read it well. Try reading the first sentence again. getting too long? Yes. -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Banning for meta-discusion [was RE: [uf-discuss] previously non-referenced in the specReferences]
A small group of like-minded individuals with a common background who know each other personally is easy to organize. This was that, but it ain't no more. I'm not sure how much this applies... the group of administrators is a world wide group of volunteers. Although this hasn't always been true, even the very earliest of adopters and active community members have origins all around the world, and no personal connections. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: looking for patterns vs. dreaming up patterns (was Re: ecommerce was Re: [uf-discuss] Principles of Microformats?)
On 12/21/06, Tantek Çelik [EMAIL PROTECTED] wrote: I'm not sure who originally wrote: I did. Others skip the collecting examples (data) step and simply dream up patterns based on their intuition (or expertise) - perhaps that is what you mean by allowing myself to look for patterns. It was based on an IRC conversation, http://rbach.priv.at/Microformats-IRC/2006-10-28#T222748, http://rbach.priv.at/Microformats-IRC/2006-11-15#T223713. That non-scientific technique has been tried in many (most) standards and results more often than not in bloated overly complex (certainly not micro) standards. There are exceptions, where an individual with exceptional discipline and near obsession with simplicity makes something small and elegant, but they are the exception, not the rule. I'm not using this hypothesis to synthesize new standards. It's just something I've been thinking about, and am looking for evidence to test it. It is as basic a question as why some technology seems to work and some doesn't. http://microformats.org/wiki/why-examples This is nice. Thanks, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: looking for patterns vs. dreaming up patterns (was Re: ecommerce was Re: [uf-discuss] Principles of Microformats?)
Ah, thanks for the context Ben. The quote makes more sense in that context, but I still feel makes a statement that I wouldn't make. Oops! I didn't mean to do anything like that! It's an interesting hypothesis, but I believe what I was pointing out from the IRC conversation is that you may wish to pursue more formal study in those fields (anthropology/ethnology/psychology in particular) and refine your hypotheses accordingly before spending time trying to prove or disprove it. You may find that similar hypotheses may already be proven/disproven in the formal fields and thus you won't have to duplicate the effort. If not, you will likely be able to at least refine your hypothesis to build on existing work. Tantek, your advice is always welcome. I may have under-represented myself in an attempt to be humble. I don't have the formal education that an expert would. However, I have taken several college level classes, and my current reading list is comprised of the materials that you are suggesting. The subject also includes cognitive studies, which has been the concentration of most of my recent reading activities. Anyway, this is probably way off topic of uf-discuss now, but if you have suggestions for particular programs nearby or books to read, I'm all ears. Thanks, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: comma or semicolon in geo (was: [uf-discuss] Operator: Microformat detection for Firefox 2)
On 12/17/06, Brian Suda [EMAIL PROTECTED] wrote: On 12/16/06, Andy Mabbett [EMAIL PROTECTED] wrote: It might be best of parsers accepted either; since some schemes use comma (e.g. ICBM), others semicolon (e.g. geotag) At the moment the ';' semicolon should be used. There is an FAQ about it on the hCard-faqs page[1]. I'll update the hcard cheatsheet page accordingly. The ';' comes from the vCard RFC, because hcard is modeled after vcard the syntax was just reused. One issue with using a ',' instead is that a comma sets off a 'list' of properties, this can be seen in RDATE and others. And (if for some reason) there was a need for plotting 2 dimensional figures, my first thought would be to just have a list of lat;lon: abbr title=12;34,56;78,90;12.../abbr so i would prefer to stick with a single lat/long delimiter and continue using just the ';' to separate values. However, most people probably use a comma. See the coordinate studies done at http://awis.blogspot.com/2006_06_01_awis_archive.html. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
ecommerce was Re: [uf-discuss] Principles of Microformats?
Mike, I was particularly interested in a part of your reply: On 12/16/06, Mike Schinkel [EMAIL PROTECTED] wrote: 17.) Inspired by needs of Bloggers and blog-related services Use cases involving bloggers are easy to come up with, however I started working on microformats before I had a blog! Anyway, I suspect blogger-based use cases are good because they are so user-centric. It is certainly not the focus of microformats, I think. However, a blogging aggregator/search engine is funding time spent my the leads of the process, so there will inevitably be subtle biased towards bloggers, even if they try not to because those are the use cases they identify as having value. For example, use-cases which enable e-commerce companies to exchange data with their vendors and suppliers is not on their radar. This is extremely interesting. First: I'm only vaguely familiar with some e-commerce issues. You may find that the the early creators of microformats, because of a relatively common background, may simply not have enough exposure to this kind of thing. I believe most of the earlier members of the community work for search companies or other large websites, or even makers of web browsers and web technology, and not many are familiar with ecommerce. I've also noticed that many of the more successful technologies I can think of first implemented use cases with user-centric data: people, places, things, times, and events. That doesn't mean other use cases aren't of interest to the community. It simply means that time and energy are limited, and people tend to spend most of it on things they are good at. Second: Can you elaborate a bit more on these kinds of use cases? Are there some basic categorizations of ecommerce? What are the common things sites need to do? Where and how do they need to talk with other systems? High level answers are good. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: ecommerce was Re: [uf-discuss] Principles of Microformats?
Mike, Nice reply. I've also noticed that many of the more successful technologies I can think of first implemented use cases with user-centric data: people, places, things, times, and events. I don't know that to be true, but it certainly makes sense. I don't know if it's true either. Tantek suggests I'm being a bad scientist by allowing myself to look for patterns. Nonetheless, I've been working on investigating it more. I call this data environmental data types because their concrete place in the world we evolved in. Anyone have suggestions on putting this to the test? That doesn't mean other use cases aren't of interest to the community. It simply means that time and energy are limited, and people tend to spend most of it on things they are good at. Correct. The problem (as I've seen it) is the vision and process for microformats inhibits addressing those other issues. Again, this is just an observation, I am explicitly no longer advocating they change it. I respectfully disagree. I'd like to start investigating the use cases your business had trouble fulfilling, starting with: are the problems you described with vendor communication common? Can you elaborate a bit more on these kinds of use cases? Are there some basic categorizations of ecommerce? What are the common things sites need to do? Where and how do they need to talk with other systems? High level answers are good. Let me give you a real world example. I used to run Xtras.Net (www.xtras.net) We sold products from companies like www.infragistics.com and www.componentone.com, but at certain points we dealt with well over 500 different vendors. Had we need able to manage the logistics, we could have dealt with well 2500 vendors and our sales would have increased significantly. Realize that most of these vendors were starving artists, i.e. one or two man shops making less than US$100k/year in revenue. They certainly were not going to be buying any ecommerce infrastructure, but they did update their websites whenever they had a new version. If an appropriate semantic markup could have been defined we might have been able to get most of those vendors to apply it and then we could have run crawlers to get a lot of our data. I actually had this vision in 1997 when I first heard of XML, but for many reasons was never able to make it a reality (many reasons=lack of capital to fund the development :) It would be that much easier with semantic markup with today scripting languages and other tools. But realize that Xtras.Net's business volume was a gnat on the back of a dog in a car on a ship crossing the Pacific ocean when compared to the world economy. So take all the other gnats, and dogs and cars and ships and have them all start creating their own industry specific semantic markup and BAM; you got some serious eff-ing chaos, and I declare that will be a Bad Thing(tm) for the web. Mike, this is real good stuff. Can you continue elaborating? The thing I'm hearing is: We had trouble keeping our product list in sync with our vendors' lists, even though they had it published on their own website. This is the kind of problem statement we know how to handle. There are some questions to answer: 1.) How many ecommerce sites have their inventory published on the web? - my guess is nearly all of them, although I suspect there are some confounding factors. 2.) How many sellers have trouble getting product information from their vendors? - this one kind of surprises me, I thought everyone had at least a php script hooked up to their database to produce a CSV. 3.) How many esellers use vendors to populate a part of their online offerings? 4.) Would hlisting http://microformats.org/wiki/hlisting solve this particular use case? Finally, What other challenges did you face/are aware of? Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Non-visible microformats was [uf-discuss] Principles of Microformats?
On 12/16/06, Angus McIntyre [EMAIL PROTECTED] wrote: The FAQ makes it clear that the concern is that invisible markup is associated with spam; because spammers like to hide stuff in their pages that causes a search engine to see them differently from human viewers, any proposed microformat that encourages people to put normally-visible markup into a page invisibly runs the risk of getting pages that carry it sanctioned by Google and friends once the spammers learn how to abuse it. Without commenting on the rest, I'd just like to point out that the main reason for avoiding invisible meta data is because visible data is updated more often than invisible data. Spam is secondary to this principle. This is a usability phenomenon, not a spam prevention measure. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Q
I think you guys are on the right track. I'd like to encourage you to do some market research. Start collecting examples and see what you can distill. Here are some questions I've got: * Are lots of people publishing questions and answers? - My bias is yes! * How are they doing it? - My bias favors the dl idiom, but it'd be interesting to find out how widely it's used. You might ask Ian Hixie what research he's uncovered wrt to class=question and its ilk. There are also tools my employer offers that would help with this research, but I don't want to mention it inapropriately, and I'm working on ways to benefit open source communities with this tool. - Browse around and see if we can collect a handful of idioms used for this. I suspect that there are a few classes of sites publishing QnA (which we should verify through research): * Commercial sites offering QA to inform the public of their products * Project/personal sites offering QA to help with encountered problems * Informative sites whose focus is QA I bet we can find common idioms and patterns for publishing this kind of material. Finally, there are a few things keeping me from starting a wiki page: 1.) What is the scope of this format? Is it strictly questions and answers? Is there a slightly more general concept that would yield much more benefit without a corresponding increase in complexity? 2.) What are the use cases for this format? 3.) Are there any other formats that cover the would-be use cases/problem space? Finally, on a more personal note: I'd like to encourage the community to help with this research. There have been some negative things going on, and this is a good opportunity to reset our expectations: * Be positive * Do research * Build consensus * Constructive collaboration. There will be more on this in a separate thread. -Ben On 12/15/06, Paul Kinlan [EMAIL PROTECTED] wrote: Paul, what do think? I personally think that the qa is a good idea, I belive that you would be easily able to seperate questions and answers out and you will be able to start infering meaning from the text inside the qa section, however like with all microformats it is useless unless people use it (and if it is only you and me then there is little point in having a microformat because only ourselves will be publishing and consuming our own data). I don't belive at the moment that people will be bothered with microformats unless the tools are there that create them without people knowing about them, but obviously when you get to that level of integration I don't think microformats will be needed at all. However on a lighter note, as far as I am aware the dl, dt suffice (although it looks like dt is not ment for questions) I don't think classes are needed to distinguish questions and answers, and if this can start to get used by people I have lots of ideas for it. Paul On 14/12/06, Ciaran McNulty [EMAIL PROTECTED] wrote: On 12/14/06, Taylor Cowan [EMAIL PROTECTED] wrote: This might break when there are multiple answers, not sure if one to many dt 2 dd is ok, but a surrounding di would help. One-to-many DT/DD is allowed, as are many-to-many. dl dtA term/dt dtAnother term/dt ddA definition/dd ddAnother definition/dd /dl It's a DT that follows a DD that 'starts' a new block, if that makes sense? -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] QA
On 12/15/06, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Andy Mabbett [EMAIL PROTECTED] writes FAQs There are, of course, complications Let's try to stay focused: can you point us at any URLs using the idiom you outlined? One solution might be: I suggest we avoid proposing markup before we look at existing mark up and obtain a rich understanding of the problem we're solving. Until we do those things, it's all hypothetical, and a sub-optimal use of time and effort. Another complication is the non-questioning questions, like sign me up, the last item on: http://www.sfgate.com/chronicle/faq.shtml Nice find! I wonder how many sites do this, ie is this behavior in the 20% or the 80% of publishers choosing to publish faqs? I also wonder if it even matters, since this is trivially transformed into How do I sign up?. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats in Opera
because I could find no mention of microformats being recognised by Opera. That might be neat. What does it mean? Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: XFN: Proposing rel='respect' (was RE: professional relations and XFN usage stats and Re: [uf-discuss]rel=muse implies romantic relationship?)
Aren't claims that you are respected by ___ kind of arrogant? Is a reverse useful? It's one thing for someone to claim they respect another, and another thing entirely to claim to be respected. On 12/13/06, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Rob O'Rourke [EMAIL PROTECTED] writes I'm curious in the absence of rev, what would be the reverse relationship of respect? rel=diss Ah, but that's the opposite, not the reverse. -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Principles of Microformats?
Mike, interesting list. 1.) Includes visible-only Yeah, microformats only represent visible data. 2.) One flat namespace Not sure what this means. There is one namespace for class names, yet the markup itself is hierarchical. 3.) No solution for resolving ambiguities Not sure about this. The mailing list, IRC, and the wiki serve as venues to build consensus in the face of ambiguities. 4.) No Microformat registry What would a registry look like? We have XMDP and the wiki. 5.) No versioning capability Someone recently brought up versioning. It will be interesting to see where that goes. What is the use case for versioning? 6.) Recognition is exclusive Yes, a microformat exclusively refers to the product of the microformats process. I honestly don't know why other usage has cropped up. 7.) Requires community process and approval One of the key ingredients in a microformat is wide and pervasive represenations of the data being considered on the web already. Without this, microformateers are likely to consider a representation esoteric. I'm not sure what community you mean here, and I'm not sure it's *required*, but OTOH I don't know how you can create a microformat without the help of the community: at least to the extent that many people are already trying to publish the data being considered. 8.) Envisions limited scope With regard to what? The problem-space is typically well defined. Use cases help us define what we are doing. OTOH, we see wide adoption of microformats as well as applications to use cases we had not considered. 9.) Process favors expedience Compared to what? 10.) Specifications allowed to evolved w/o explicit finalization 11.) Considers existing HTML usage If a particular type of data isn't already being representing in HTML, we typically avoid developing a format for it. Also, we use the same techniques many authors use, such as using class and semantic HTML. 12.) Centralized control and approval authority Controlling what? Authority of what? Some resources are secured by a few for the health of the community, eg the mailing list, the wiki, the domain name... 13.) One design discussion mailing list Dunno about this; what's the status of the mailing list proposal? 14.) No delegation of decision authority Decisions are spread throughout the community. Does this conflict with 12 or is the authority over something different? 15.) Implementations not part of process I'm not sure what this means. Plenty of people implement stuff, seemingly through the phases of the process. In fact, I imagine it would be possible to design a microformat from pre-existing implementations and formats they operate on. 16.) No officially recognized implementations What would an officially recognized implementation look like? We have many community implementations. Aren't those official? 17.) Inspired by needs of Bloggers and blog-related services Use cases involving bloggers are easy to come up with, however I started working on microformats before I had a blog! Anyway, I suspect blogger-based use cases are good because they are so user-centric. It is certainly not the focus of microformats, I think. 18.) Emphasizes general purpose needs How does this compare with number 8? 19.) Focuses on existing content publishing models Agreed. 20.) Aims to avoid changing publishing behavior I'd say we aim to codify publishing behavior in a way that minimizes the need to change where possible. For example, IIRC, all semantic lists are valid XOXO. 21.) Envisions exposing existing content semantically 22.) Constrained to enhancing known use-cases. I've recently come to believe that working without a use case is silly. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Misc (was: [uf-discuss] Disambiguation Conventions? (was CommentsfromIBM/Lotus rep about Microformats))
For the most part, our dictators have been pretty reasonable at trying to keep things functional and on topic. Joe, nicely said, and I agree with much of it. However, I thought I would just point out that the the group of administrators does no't consist of just Ryan and Tantek. The administrators of the forum, wiki, and IRC channel are now a wordwide group of volunteers. This is a recent, relatively quiet change, and done to address some of the things you mentioned. Ben PS: Kevin Marks has always been an administrator, but is frequently overlooked. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: class=hack? Re: [uf-discuss] Comments from IBM/Lotus rep aboutMicroformats
On 12/11/06, Mike Schinkel [EMAIL PROTECTED] wrote: Chris, are you aware that Ian Hickson and Lachan Hunt on the WHATWG list are prescribing microformats as the generalized extension mechanism for HTML (whenever anyone asks for a more generic extension mechanism?) Mike, this isn't quite true. What's being prescribed are the techniques. Techniques using mechanisms already available in HTML. These are the same techniques that Microformateers apply to well defined problems to create a microformat. But just because microformats are a notable use case for these techniques doesn't mean that anything using those techniques is a microformat. What has been confirmed on the WHATWG list are the techniques available to extend HTML. Ben ___ 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
On 12/11/06, Mike Schinkel [EMAIL PROTECTED] wrote: Benjamin West wrote: I'm not quite sure what you mean here. Is there a difference between lowercase microformats and uppercase microformats? lowercase microformats = unofficial semantic markup embedded in HTML uppercase microformats = Official Microformat That's the first I've heard of this usage. I think what I'm hearing (and agree with) is a need for a term that describes the product of semantic markup techniques in a general way. Lots of people are already doing this, and don't need any official body to bless them. Microformats (any casing) would be a subset of these products that are blessed by pervasive use across the web. I'm hesitant to pick out such a name, lest I choose badly (eg AJAX). I'm happy to let the market pick that name (eg I don't think anyone should deliberately pick it out.), but at the same time, I'm hesitant to let the term microformats be applied to general applications of general techniques. Does that reverberate at all with you, Mike, or anyone else? ___ 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
Some clarification: Isn't microformats more than one microformat? And what is a microformat? I thought a microformat was a specific collection of defined names and structure defined by a rigorous process of market research intended to consider pervasive use of semantic html in order to increase data fidelity of HTML-borne data widely distributed on the web. When people mention microformats they often are referring to the use of semantic html to increase data fidelity. This is extremely confusing because a microformat, or Microformat, is something more than any use of semantic html, it's a specific use to represent specific data. That is to say that the word microformats does not refer to a technique of data representation. Microformats are not a general extension mechanism, and such language is very confusing, and harmful to discussion. The general extension mechanism is to publish data using the best semantic techniques available, currently via class,rel,profile... The fact that microformats use these means doesn't somehow turn microformats into a technique for doing so. Vendors, authors, or anyone, can use the same techniques to raise proprietary data fidelity in HTML, but that doesn't turn them into a microformat. Data formats using these techniques achieve candidacy as a microformat when their use is widespread. Talk of general microformats doesn't make sense. Talk of microformats as technique also does not make sense. Talk of microformats as a group makes sense, but only when it refers to more than one actual microformat. When applied to people, Microformateers is probably better. Ryan, Thanks for helping to clear this up on the whatwg list, to some degree. Do we need to be more protective of our vocabulary? -Ben P.S. The definition I've given is what I understand microformats to be. AFAIK, there is no official definition, which may be contributing to the splintering of our vocabulary and mindshare. If I'm wrong I'm sure someone will correct me. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] species microformats OpenSearch
.could ever contribute to the semantic web in a meaningful way will stand the test of taxonomic revisions I agree with this. It's unclear to me how the current proposal even relates to the research gathered, and what use cases it might support. Typically, microformat proposals are heavily influenced by the analysis of examples collected. I've tried doing this work at http://microformats.org/wiki/species-examples-regrouped. Most of the useful examples look similar to one of the sites you mentioned: a href=/data/spiders/14441 onMouseOver=window.status='';return true title='Click for species description' iAculepeira carbonarioides/i (Keyserling, 1892) /a Looks to me like most mentions of species don't contain much information about them, but rather link to to another page that does. To me this resembles tagging, where species mentioned is the tag, and the endpoint of the url is the resource representative of the tag. Perhaps with further analysis, we can modify hReview or xFolk to be useful for species, in order to model what is actually happening in the market. Can you: * elaborate on the kinds of use cases you would expect a species microformat to support * confirm whether or not the above model is the most common way of publishing species mentions * collect intances of the authoritative resources and their markup of the species * what is the most commonly published information (on the authoritative end) * how is it represented (on the authoritative end) Ben On 12/5/06, Shorthouse, David [EMAIL PROTECTED] wrote: Folks, I am a relative newcomer to microformats and come with a biological sciences background so am most interested in the species microformat group of discussions (http://microformats.org/wiki/species). Rod Page and I with contributions from Charles Roper have been having an interesting discussion about OpenSearch on his iSpecies (http://darwin.zoology.gla.ac.uk/~rpage/ispecies/) blog (http://ispecies.blogspot.com/) as it relates to The Nearctic Spider Database's use of some software called Zoom Search. Of particular concern to me is: 1) using correct appropriate nomenclature and, 2) providing a means to aggregate the sorts of species pages produced as exemplified by The Nearctic Spider Database (http://canadianarachnology.dyndns.org/data/canada_spiders/). To that end, I now make use of uBio LSIDs marked-up species pages with: h1span class=species urn:lsid:ubio.org:namebank:2029133Theridion agrifoliae/span Levi, 1957/h1 .in the hopes that uBio's and other LSIDs will eventually contribute to the semantic web in a taxonomically intelligent way. This in my opinion is the way to go with microformats. I simply cannot comprehend how something like: h1span class=speciesTheridion agrifoliae/span Levi, 1957/h1 .could ever contribute to the semantic web in a meaningful way will stand the test of taxonomic revisions (i.e how do the current species microformats deal with synonyms, homonyms, and other recognized nomenclature?). Finally, what steps have been taken to aggregate or make use of species microformats and can OpenSearch play some sort of role here in taking the next step? David P. Shorthouse -- Department of Biological Sciences CW-403, Biological Sciences Centre University of Alberta Edmonton, AB T6G 2E9 Phone: 1-780-492-3080 mailto:[EMAIL PROTECTED] http://canadianarachnology.webhop.net http://arachnidforum.webhop.net -- ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats
Benjamin West wrote: Talk of general microformats doesn't make sense. Talk of microformats as technique also does not make sense. If that is true, then having Microformat Design Patterns[1] doesn't make sense. Which is it? I'm not sure what you mean. A design pattern is a technique, which is separate from what a microformat is. A microformat is an application of several techniques to a specific end. When some techniques prove successful, they become patterns. The techniques are means for generalized extensions, while a microformat is a specific application of those techniques for a specific extension. Microformats exhibit emergent characteristics from wide usage on the web; this characteristic means that these formats only exist because they have already scaled --even before they were borne. So I guess I'm not sure what the concern for scaling is. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Mailing list debate moved new proposal
If people want to filter things out, or draw particular attention to a thread being related to a specific proposal, using the [hCard] notation (for example) works quite well in the subject field. I concur. Filtering features are well supported on many of the mail clients I've seen, and a simple filter with the convention of tagging threads with square brackets would probably work fine. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCalendar spec- no specification included!
It's now two weeks since I wrote the above, and nothing has changed. Seems like a lot has changed to me. Lots of people are working on the wiki. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Mailing list debate moved new proposal
It's too bad we can't tag e-mail messages. That way your colleagues could filter this mailing list and only get the messages they want. Don't we already employ a sort of tagging through use of square brackets? [uf-discuss] seems like a tag to me. Followed by [hcard] or [species] would tag that thread as particularly relevant to those formats. This may be especially handy with the forthcoming list. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] attention profiling mark-up language?
huh? I thought technorati already had attention.xml, not to mention whatever format attentiontrust uses. On 10/23/06, Chris Messina [EMAIL PROTECTED] wrote: Anyone seen the attention profiling mark-up language? Any thoughts? They've got a draft spec: http://www.touchstonelive.com/apml/spec/APML%20v0.5%20Draft%20Specification%20v0.2.pdf I talked with them -- they're down with microformats... but, is this a good application for XHTML data storage/collection? Chris -- Chris Messina Citizen Provocateur Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Visible Data...a Microformat requirement?
So, what if your take on this problem and use-case? Search engines make use of shingles to identify pages and their aliases. Some search engines employ teams of editors and solicit feedback from the web community to ensure their aliasing techniques are correct. As far as I can tell, this isn't in the same class of problems that microformats solve. This probably best resolved by agreeing what we mean by metadata, as the scope of definition and contents of that term seem to be somewhat disputed and/or misunderstood as well as the scope of the problem space of microformats. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Size considerations and other property-names for species
I'm going to poll a few experts on this. I'll let you know when I get some feedback. It's probably more important to poll already published content, to learn how the market place is already doing it. This is the whole point of documenting examples, analyzing publishing behaviour, and only afterwards determining what the schema and names should be. Time would be much better spent continuing work on organizing examples by publisher and publishing behaviour, documenting existing practices, and discovering the implied schema, as the other microformats have done. To my knowledge, this process still isn't complete. Is there any precedence? The exact question I'm interested in. :-) Thanks, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] species questions; process: examples questions
Andy, I don't want to get in the middle of a disagreement, but I think that part of Ben's issue is that the terms you're asking about are fairly self explanatory, or at least appear to be to him. You aren't in the middle. I'm deliberately stepping back so that others can comment. This is a sanity check for me. Do I know what what authoring practices are? I thought I did, and it seems to me that this meaning is shared with others in the community. A good test if to step back and find out if other people resonate with what I'm thinking or not. Authoring practices are the current practices and conventions used by people authoring content. The structure of the markup is the syntactic structure of pages marked up with (X)HTML. Right, but this uses the term in the definiton. In another thread, metadata and the scope of microformats are also being called into question. I suppose this is a good thing, since it will force us to say what we mean instead of implying it. I'm not interested in writing dictionaries though, so perhaps this work is best left to those more patient than I. Thanks, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Size considerations and other property-names for species
I work with experts in this field and so it's a simple task for me to ask around. Neat. Going back to learning how the market place is doing it, I've yet to see an example that uses the term binomial as a class name in markup. If I find an example, I'll post it. Great, that's exactly what I think is needed. Thanks! I will focus efforts in this area. In my own experience working in the field of biodiversity informatics and web design, I would anecdotally say that there are very few common existing practices apart from those I've already pointed out. I'll work these into the examples. Again, I REALLY appreciate this. This is exactly the work that needs to happen, and is what I intended to encourage with my regrouping effort. I also appreciate your comments so far on that effort. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] species questions; process: examples questions
This is catered for, in the current proposal, thus: span class=biota [1] abbr class=binominal title=Solanum tuberosum span class=variety [2] Maris Piper /span /abbr /span Allow me to simplify my earlier post. My main concern is that none of the examples (that I've looked through so far), with the exception of Andy's site, use any markup that looks anything like this. *-examples pages contain analyses of the markup from those examples. This work then informed the proposals which followed. The resulting format clearly reflects the behaviour of existing practices. As far as I can tell, the current strawman proposal doesn't seem to reflect existing publishing practices. How does the proposal reflect existing publishing behaviour? Where is the analysis for many of the examples' markup? Where is the list of common publishing behaviours? Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] species questions; process: examples questions
Andy, Perhaps you could be more clear about what it is you want to know. ... What do you mean by authoring practices? ... What do you mean by the structure of the markup? ... I don't know how to be any more clear. I've assumed up until now that everyone had a relatively shared meaning of authoring practices, publishing behaviour, and what structure means in the context of markup. Clearly we don't, so your answers aren't making any sense to me. I've already expended too much energy on this to further explain, so perhaps others can jump in. Furthermore, by moving my work off the page it was meant to be on, I assume you find it tantamount to useless, and since there are many other areas my work has been deemed useful, I won't be interrupting yours anymore. Sorry, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] species questions; process: examples questions
It reflects current publishing practice as precisely and completely as possible ... I'm still wondering how it does so. I'm not sure what else I can tell you. Perhaps we have different understandings of some words? We must not be sharing some crucial foundational concepts. Allow me to summarize from my perspective: Me: How does $x relate to $y. You: It's relates precisely and completely. Me: I didn't mean does it, I mean how does it? You: Not sure what to tell you. Surely we can begin communicating better. We seem to be talking past each other. Have you find a reference to a living thing, in the context of biology or taxonomy, which the proposal does not fit? The markup suggested doesn't seem to reflect, to me, any of the authoring practices already being used. Furthermore, it's hard for me to evaluate how the suggested markup was proposed because I can't find the analysis and commonalities of already published markup. The structure (which is very flat) is also dictated by the rules of taxonomy. I don't mean the structure of domain specific taxonomy information, I meant the structure of markup. The names of taxonomy are already provided by science. I understand that. I'm specifically talking about the structure of markup. What analysis would you like? [...] What do you mean by common publishing behaviours, that isn't already provided in the examples listed? I suggest looking at the other *-examples pages, in particular http://microformats.org/wiki/review-examples and http://microformats.org/wiki/citation-examples. Please take careful note of the analysis sections and implied schema sections. Oh, and next time you feel the need to accuse me of editing a wiki page on behalf of another user, kindly check the page history, first. Thank you. I was looking at the history, which is what made me curious, to begin with. As far as accusations go, I'm not sure I've made any, but in the case that I have: I officially unaccuse and revoke any accusations towards you. I'm glad for your work and efforts. But just so we're clear: I'm concerned about species. Thanks, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] mailing list greatest hits
Yes, I was thinking of something like this. We can think of a given microformat as being at some place along a spectrum that ranges from: not thought of, interesting/compelling, rejected, needs work, documenting examples, brainstorming, official, drafts, iterations... and so on. I agree that we should be capturing lessons learned from discussions that don't always yield official microformats, or even start new microformats, if only to prevent repeat conversations. Chris, this should be included in http://microformats.org/wiki/to-do#Information_Architecture somewhere. I believe this idea was touched on briefly by some others as well, but it could use some fleshing out in the to-do area. I suggest using the to-do area to both flesh out ideas and build consensus so we can get more people doing real wiki work. :-) For now I've simply added: - The wiki should also capture wisdom that stems from discussions that don't produce microformats. For example, Chris Messina suggests a Best Of page suitable for capturing this kind of wisdom. I think we can think of a given microformat as being at a place in a spectrum that ranges from not yet thought of, to interesting but needs work, or even rejected, and of course including all the stages familiar to the microformats processes (eg examples, brainstorming, etc...). If there were such a page would it: * Belong to a microformat? (eg hcard-bestof) * or to the global namespace? (eg /wiki/wisdom/foobar-format) (I think Chris Messina suggests that it belongs to a given microformat, but then how do we collect wisdom from non-microformats?) - Thanks, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Size considerations (or how to choose abbreviations)
I think this has been mentioned before, but I'll mention it again. From http://microformats.org/wiki/geo: geo is a 1:1 representation of the geo property in the vCard standard (RFC2426 (http://www.ietf.org/rfc/rfc2426.txt)) in XHTML As you can see, the authors of the spec weren't the ones doing any abbreviating. The name was picked to reuse a pre-existing standard. In picking out class names, you might find it fruitful to look at names already be used to describe the kind of data you hope to mark up. This is a core tenant of microformats. There are some simple tests to resolve debate around whether or not to use sci: * Are there any examples on the web where people are using sci as a class name in a way that roughly means what you also intend it to mean? * Are there any standardized, or conventionalized, formats that describe what you mean to describe? Do they use sci or something else? One effects of networked systems is that re-use raises the efficacy of both the original and the copy. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard URL for page being visited
Isn't address supposed to contain contact information for the page itself? On 10/21/06, Andy Mabbett [EMAIL PROTECTED] wrote: I seem to remember mentioning this before, but can't find where I did so, nor any responses. It seems to me that there should be some way to say that the URL of an hCard or hCalendar event is the URL of the page itself, without having to include a redundant, and accessibility-damaging link to that page, on the page itself. Or has anyone already devised a way to do this? The URL of the visited page can be available, in a Dublin Core metadata header, thus: meta name=DC.identifier scheme=DCTERMS.URI content=[URL] or could be auto-discovered by a parsing agent. One solution might be to have, say: span class=vcard selfurl were the latter class value declares that the URL of the visited page is to be included. (I'll put this on the relevant issue pages on the 'wiki') -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] IRC Chat Client?
I use gaim. Nice unified interface for all my chatting needs. On 10/20/06, Mike Schinkel [EMAIL PROTECTED] wrote: Sure then, next week. :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tantek Ç elik Sent: Friday, October 20, 2006 5:01 AM To: microformats-discuss Subject: Re: [uf-discuss] IRC Chat Client? On 10/20/06 1:52 AM, Mike Schinkel [EMAIL PROTECTED] wrote: Thanks for the all input on chat programs! I'll check'em out and get on the IRC after I come back from this long weekend. Mike, perhaps you could add a page to the wiki irc-clients listing the recommendations so far and adding your experiences? http://microformats.org/wiki/irc-clients Then we could even add an FAQ regarding IRC clients. Even if it is not specific to microformats, IRC is very frequently used by the community to rapidly discuss and make progress on various topics/issues and thus having such a resource is a nice convenience. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCalendar spec- no specification included!
Justin, Would you mind visiting http://microformats.org/wiki/to-do#Information_Architecture and adding your support? While we're on the subject of newbies, if they first hear about microformats from the sources you mentioned, what kind of people are they? Are they graphic designers? Web developers? Business people? It appears that microformat newbies are the kind of people that go to conventions. What do these people expect when they visit for the first time? Most web browsing is task-oriented. Do they want to find out how to author microformats? Learn more about what they are? Find out why they exist? Ben On 10/18/06, Justin Thorp [EMAIL PROTECTED] wrote: I really like this idea. What if the landing page for the microformat wasn't the spec but it was some warm and fuzzy intro for newbies? It could then link to the spec for those that were interested to it. A good example of this would be the W3C WAI's intro for WCAG that they give you before you get sent right into WCAG 1.0. http://www.w3.org/WAI/intro/wcag I would expect that a lot of newbies start off hearing about microformats on tutorials like: http://www.digital-web.com/articles/microformats_primer/ http://www.thinkvitamin.com/features/design/how-to-use-microformats Or from presentations like: http://tantek.com/presentations/2006/09/microformats-practices/ They get linked to the spec and then get offly confused. -justin thorp ** Justin Thorp Web Services - Office of Strategic Initiatives Library of Congress e - [EMAIL PROTECTED] p - 202/707-9541 [EMAIL PROTECTED] 10/17/06 3:39 PM In message [EMAIL PROTECTED], Benjamin West [EMAIL PROTECTED] writes Regarding the specs bit, I meant to refer to the various stages of the process. The spec landing page might contain the big questions, with a status section pointing to pages dedicated toward how the spec is moving through the process, and with the learn more section pointed at the spec itself. If the spec itself is on a secondary page, then the landing page isn't the spec. -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Size considerations
Should this stuff be in a FAQ or be made into a uF principle page? On 10/18/06, Charles Roper [EMAIL PROTECTED] wrote: Is is considered better to have longer, easier-to-read, more descriptive, more semantically correct attribute values over shorter, more concise, bandwidth-saving ones? On small pages, a few extra bytes of HTML won't make a big difference, but on very large pages (in terms of markup), all those extra HTML classes and their uF values could pile on the KBs. I would argue that on-the-fly compression of HTML (mod_gzip, mod_deflate, PHP's zlib et al) is mature enough now to be considered a better solution for reducing page size over using shorter uF attributes. I would also argue that longer, more readable attributes are more in keeping with the uF goal of being for humans first, machines second. Here are some pros/cons off the top of my head: Longer attribute pros: More easily readable Less likely to be namespace collisions More sematically correct More precise Longer attribute cons: Uses more bandwidth, especially on larger pages More typing when authoring manually What do others think? -- Charles Roper www.sxbrc.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCalendar spec- no specification included!
On 10/18/06, Mike Schinkel [EMAIL PROTECTED] wrote: A form would be nice, but it takes time to develop and we can't expect they will be developed before people are interested. Actually this is already done. There are generators/creators/___-o-matics or whatever the current term is for hReview, hAtom, hCard, and hCalendar, AFAIK. I believe they are all linked to from their respective wiki page. OTOH, most people can't read a spec and make heads nor tails of it (I know that I struggle with W3C specs), so there is the spec and then there is the tutorial (or similar.) All can be clearly linked from the mini-home page. This is just like Creative Commons where they have the human readable license and then you can see the lawyese if you really want. I've never even looked at the lawyered one, have you? I don't need to; the simple version works much better for me and is all I need. Something that tells the average Joe how to author in simple language with good examples is what will be most beneficial for most people. I think we all agree that some parts of the wiki have room for a lot of improvement. Reasonable, but it needs some content, so as not to appear dry and unwelcoming. Not to be contrary, but see How Users Read on the Web[1]. Content for content sake is less than useful. Google's home page is dry but it's used by more people than any other (or if not, I don't know what is) because it meets people's needs better than the alternative (or they would switch.) Yahoo is much more used than Google :-). However, that's irrelevant. I believe the landing page for each format should answer the big questions common to all readers when they arrive at a landing page, and then quickly and thoughtlessly funnel readers into the sections most relevant to their interests. This includes information how authoring, principles of creation, what the format is suited for, and of course the spec itself. I don't mean that these resources are on the landing page, but rather that the landing page should act as a funnel, quickly allowing the reader to sort out which direction has the scent of information they are looking for. Let's be careful to not exclusively talk about the specs. The wiki contains many kinds of information. While the specs are arguably the most important kind, they aren't the only kind. There is a lot of supporting material, including web authoring tips, faqs, principles, community information, discussions of goals... I want to make sure we can identify what's on the wiki in terms of larger categories, AND organize the specs. The two categorization efforts should inform each other. Now that we've got a few suggestions on how the spec space should be organized, can we work on classifying the other kinds of materials on the wiki? Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCalendar spec- no specification included!
Justin, Great input. Let me see if I can summarize it in bullet form: * Bleeding Edge Adopters * Looking for new things * Might be looking/adopting things for the sake of coolness/newness * uF's seem new and cool? * Probably little exposure to uF (did they see it mentioned in a blog, search, or conference?) * Veteran Experts * Fulfilling obligations from above * Trusted expertise for business decisions * Referred from a non-expert source to check viability First Experience: * Quick Background/Overview * Short Salient Examples * Cheat Sheet for Authorship * Tools * Authoring * Parsing * More Resources * Authoritative Spec * Examples Something like that? Ben On 10/18/06, Justin Thorp [EMAIL PROTECTED] wrote: I think the people reading the articles about microformats and jumping into the spec cold are the early adoptor web developers. My uneducated opinion is that microformats is a fairly new movement. Regardless, it seems like it would be in the best interest of what we are trying to do to write all of our stuff and organize it so that it also works for the 50 year old web systems programmer who may be slow to adopting (stubborn) new technologies but was told by his boss he has to look at the business applications of adopting microformats. If I land on Microformats.org for the first time, just wanting to learn, I am going to be looking for something that says intro or new or tutorial. It needs to answer the who, what, when, where, why, and how. It shouldn't use jargonny language. If I am new and reading about hCard or hCalendar for the first time. I want to figure out BRIEFLY what the background is. I don't need a history of vCard. I'd want some examples. Id want to know about what sites use them. I'd want tools to help build them. Id want a list of all the different class names and where I can and can not use them (the rules). I'd leave semantic principles in a doc that you can link to. Maybe mention it briefly. Hope this helps. Cheers, Justin Thorp ** Justin Thorp Web Services - Office of Strategic Initiatives Library of Congress e - [EMAIL PROTECTED] p - 202/707-9541 [EMAIL PROTECTED] 10/18/06 12:59 PM Justin, Would you mind visiting http://microformats.org/wiki/to-do#Information_Architecture and adding your support? While we're on the subject of newbies, if they first hear about microformats from the sources you mentioned, what kind of people are they? Are they graphic designers? Web developers? Business people? It appears that microformat newbies are the kind of people that go to conventions. What do these people expect when they visit for the first time? Most web browsing is task-oriented. Do they want to find out how to author microformats? Learn more about what they are? Find out why they exist? Ben On 10/18/06, Justin Thorp [EMAIL PROTECTED] wrote: I really like this idea. What if the landing page for the microformat wasn't the spec but it was some warm and fuzzy intro for newbies? It could then link to the spec for those that were interested to it. A good example of this would be the W3C WAI's intro for WCAG that they give you before you get sent right into WCAG 1.0. http://www.w3.org/WAI/intro/wcag I would expect that a lot of newbies start off hearing about microformats on tutorials like: http://www.digital-web.com/articles/microformats_primer/ http://www.thinkvitamin.com/features/design/how-to-use-microformats Or from presentations like: http://tantek.com/presentations/2006/09/microformats-practices/ They get linked to the spec and then get offly confused. -justin thorp ** Justin Thorp Web Services - Office of Strategic Initiatives Library of Congress e - [EMAIL PROTECTED] p - 202/707-9541 [EMAIL PROTECTED] 10/17/06 3:39 PM In message [EMAIL PROTECTED], Benjamin West [EMAIL PROTECTED] writes Regarding the specs bit, I meant to refer to the various stages of the process. The spec landing page might contain the big questions, with a status section pointing to pages dedicated toward how the spec is moving through the process, and with the learn more section pointed at the spec itself. If the spec itself is on a secondary page, then the landing page isn't the spec. -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman
Re: [uf-discuss] hCalendar spec- no specification included!
On 10/18/06, Andy Mabbett [EMAIL PROTECTED] wrote: You forgot: Actually, I was summarizing and synthesizing, not forgetting. * Veteran Experts * Looking for new things * Might be looking/adopting things for the sake of coolness/newness * uF's seem new and cool? * Probably little exposure to uF (did they see it mentioned in a blog, search, or conference?) * Bleeding Edge Adopters * Fulfilling obligations from above * Trusted expertise for business decisions * Referred from a non-expert source to check viability HTH I'm not sure this helps. This essentially washes out the picture of two types of users. Perhaps we should continue coalescing to include humans in general, because looking for new things is in the nature of the human spirit. My approach to this is to identify differences, although subtle, between users in order to better understand what kinds of resources would be most helpful. To do that, I'm attempting to build consensus using synthesis and simple questions. I'm a little confused about what you are suggesting. Can you elaborate? My current thoughts are that you meant either to say that there is only one type of new user, or that the list proffered is useless. Then again, I'm not a mind reader, so feel free to correct me. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCalendar spec- no specification included!
Mike, But I'm so lazy. Point taken, I'll include more URI's when I should. Mike, your comments are under http://microformats.org/wiki/to-do#Information_Architecture. I did the hAtom creator and am interested in further work on the creators. http://microformats.org/wiki/to-do#Creators If there is a creator missing, I'll gladly come up with something. Ben On 10/18/06, Mike Schinkel [EMAIL PROTECTED] wrote: See my todo list. Suggestion: can you be sure to include the actual URL of any referenced item in any emails to make sure I can actually find it. :) Do you think you can do a refinement of your categories on the to-do list? Can you also enumerate the categories of content generally available on the wiki? Again, same comment... And was this for me, or everyone? -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin West Sent: Wednesday, October 18, 2006 7:24 PM To: Microformats Discuss Subject: Re: [uf-discuss] hCalendar spec- no specification included! The point is there isn't necessarily one for a new spec. Until someone builds one. No worries here. I'm commited to doing this. See my todo list. Is there any that are missing? So my point was I wouldn't see a generators/creators as the entry point for a microformat, that's all. Ah, ok. Summary: * Support Scanning * Don't overwhelm with resources/text * Provide strong scents for where relevant information lives. And sorry if I'm overstating that which everyone may already be agreeing on. Building consensus and making sure we understand one another isn't a waste of time. But now that we all agree, let's please start taking notes and mentally sifting through everything. Do you think you can do a refinement of your categories on the to-do list? Can you also enumerate the categories of content generally available on the wiki? I'm thinking: * Advocacy of Best Practices ( Do we really want to do this? there are other places that do this) * FAQ ( Both general and specific to each format. how do we present this?) * Spec Materials (Landing page, getting started, guides, and spec.) Can we somehow fit all the content on the wiki into these areas? Would it address the concerns on the wiki-feedback page? Are there categories missing? Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] there appears to be a calm in the species/currency/mars storm
Andy, it's hard to say for sure.. I assume you are referring to the irc logs from yesterday[1]? I remember being in the channel at the time, so let me add some context to the quote: -- # # [18:32:56] kingryan re the mailing list proposals... # [18:33:01] tantek maybe a diagram would help ;) # [18:33:05] kingryan why don't we try fixing uf-dev first and see if that helps? # [18:33:11] Phae No, it's not that complicated :P # [18:33:16] tantek uf-dev is the wrong place for *new* microformats # [18:33:18] tantek two problems # [18:33:20] kingryan I know # [18:33:24] kingryan I know # [18:33:28] tantek uf-dev should be focused on code # [18:33:28] kingryan but why don't we fix it? # [18:33:32] Phae uf-dev is just mostly unused isn't it? I glance at the archives sometimes and they seem short # [18:33:38] tantek see uf-dev thread on that kingryan # [18:33:48] kingryan it's unused because we don't let people join # [18:33:52] Phae heh # [18:33:53] kingryan I've read that tantek # [18:34:02] tantek then reply to it # [18:34:04] kingryan I'm just sayin', let's just change one variable at a time # [18:34:08] tantek if no-one objects within a day or so # [18:34:12] tantek then we can make that change first # [18:34:27] tantek we'll give the new list name discussion a bit more time # [18:34:43] tantek since there appears to be a calm in the species/currency/mars storm # [18:34:46] tantek ;) # [18:34:47] kingryan that's exactly what I'm proposing # [18:34:52] tantek excellent # [18:35:13] kingryan the Martian currency birdstorm of 2006 # [18:35:16] Phae heh # [18:36:13] kingryan we'll be telling our grandkids about this someday -- I think that's enough context. A discussion about what to do about the mailing list starts up. A suggestion is given to continue deliberating. Then there are some comments, one of which you inquired about. I'll try to explain, if I can. This is an exciting time for microformats. Many exciting implementations are being created and millions of microformats are being published on the web. In the midst of this is a lot of energy and activity on the mailing list. You might say, a storm of activity or a flurry of activity. This is just word play, and a common idiom in the USA. I think the implication is that since there appears to be a brief lull in activity, they can afford to take a bit more time on the problem at hand. After the comment in question, the word play and associated idioms continue: it is common for news shows to try and dramatize certain happenings, especially storms and such. You'll hear things like Storm of '98 or Blizzard of '05 or whatnot all the time on local news shows. It's so common that I believe even comedy shows have done many parodies, involving situations like Bee attack of '05. To me, this is all just word play; a brief moment of levity to help the work go more smoothly. Some day, these technologies may be so common that youngsters will have a hard time believing that it took hard work and many dedicated people to triumph with the accomplishments we are all working towards. Tantek, Ryan, and friends, employ a vocabulary rich with all kinds of word play and alusions. Here are some other brief examples: * Boiling the oceans * 80/20 * Tower of babel * fidelity of data I also frequently make up words; the technology we are discussing has simply never been done before, and I sometimes find (and enjoy) the need to make up new terms. Some of my examples include: * virtual card sort * ORM over the web And more generally many people have started using terms like web application and web api. I hope that clears things up, it can be hard to explain subtlety. If anyone has alternative interpretations, I'm open to correction. Ben [1] http://rbach.priv.at/Microformats-IRC/2006-10-16 On 10/17/06, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Andy Mabbett [EMAIL PROTECTED] writes Can anyone tell me what is meant by there appears to be a calm in the species/currency/mars storm ? Surely someone must know? -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCalendar spec- no specification included!
Andy, Thanks for the prompt response; apologies if my own aren't so prompt. There also seems to be a presumption that newbies will initially be interested in authoring, that is almost certainly fallacious, and at best unsupported by evidence. Ah, that's interesting. Mind if I quote you on this in my to-do list? What are newbies interested in? How are they finding our content? Ryan, are there any particularly interesting referrers in the logs? cgriego's suggestion that wiki/* (where people are mostly likely to go) should be the intro page and it should link to wiki/*-spec is far more sensible. Yes, I agree. I like how http://simile.mit.edu/solvent/ and friends do this. The big questions are right out front to help guide you to the information you are interested in. I happen to think that they are What is this? What can I do here? How can I learn more? Are there examples? Is this what you envision as well? I may add a skeleton-type of example to my to-do list (help is needed with this). Regarding the specs bit, I meant to refer to the various stages of the process. The spec landing page might contain the big questions, with a status section pointing to pages dedicated toward how the spec is moving through the process, and with the learn more section pointed at the spec itself. I suppose there might be more than one way to do this: one choice might be to rename pages. Another choice might be to reorganize existing spec changes. Another choice might be to create newly named new landing pages that conform to some structure we work to converge on. There might be other choices I'm not considering. Perhaps we can even run some kind of virtual card sort to help establish how things should be organized. Anyone have any ideas on how to do this? What do you mean by a virtual card sort? I'm not sure. All I'm sure of is that I would like to align my desire to improve the state of affairs with others. I also believe that the first step is to converge around some organization scheme. I've been asking around for specific sticking points on the site, hCard and hCalendar have risen to the top. Card sorts are useful to learn how people expect things to be organized, but I'm having trouble picturing how this would work as this is a virtual community and whatnot. Please fix you software to remove sigs when replying; or do so manually. Thank you. Oops, sorry! gmail hides these automatically for me. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCalendar spec- no specification included!
On 10/16/06, Justin Thorp [EMAIL PROTECTED] wrote: Ben, I really like your idea of giving the wiki a better sense of organization. Justin, thanks, but this isn't my idea. Many others have expressed their ideas and desires as well. Is it possible within MediaWiki to have some type of sidebar navigation with this site organization on it? Interesting idea. Would you mind suggesting this on the to-do page? You can create your own section or feel free to put it under mine. If enough people comment in my section, I'll split the whole section off as it's own Wiki Improvement section. Please add this to http://microformats.org/wiki/to-do#Ben_West_.28bewest.29 under information architecture. Be sure to leave your name. I think this would help users to better find the information that they are looking for. For example, I am a user who could care less about the specification and cares more about how to write an hCard or hCalendar. I want to see whats possible and some examples. So your first inclination is authoring? What kind of websites do you author? Are you more of a graphic designer or a web developer? If there were a landing page for a specific microformat (as Andy and cgriego have suggested. I beleive I'm hearing more and more consensus on this.) that had large items such as: * What is this? * What can I do here? * Show me a demo. * Create an hCard Which one would look most promising? If create an hcard went to the hcard creator, would this suprise you? I didn't even see that there was a page on authoring within the pages and pages of specification. Even with it at the top of the page. I glanced right over it. It seems like most tutorials on hCard or hCalendar point people to the spec to get more information. Should we be encouraging people to point to the authoring page? I think a newbie would be very very very intimidated being pointed right to the spec. Call me sick, but this is exactly the kind of thing I'm looking to collect. I've added it to http://microformats.org/wiki/wiki-feedback. Can everyone add their favorite complaint? Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCalendar spec- no specification included!
Mike, Thanks for you suggestion. I believe this is exactly what cgriego and Andy and I have just suggested. Would you mind confiming this on the to-do page under my name [1]? If it somehow differs from the suggestions there (under information architecture) would you please explain how it differs? Also please list your specific suggestions, as well as, if possible, where content for the pages you suggest may be gleaned, and which pages would need new content that doesn't yet exist. I think you may have illuminated the intent more clearly than it has been explained so far, and so your refinement on the wiki would be very helpful. Thanks, Ben [1] http://microformats.org/wiki/to-do#Information_Architecture On 10/16/06, Mike Schinkel [EMAIL PROTECTED] wrote: I agree that the current layout is confusing. After reading several of these email I would like to make a suggestion that is smaller scope than an entire reorganization (which still might be a good idea.) Tantek suggests that the specifications are not tutorials and others have said that they (think newbies would be) interested in authoring, not the specification and I concur. What if we use a convention that the entry page (i.e. http://microformats.org/wiki/hcard) would be an index into a list of (psuedo) standardized sub pages so that it would be very people to find what is important to them. For example, is a list of potential sub pages: * Specification * Tutorial * Examples * Use cases * Reference * Discussion * Brainstorming (might be combined w/Discussion) * Implementations * Related Pages * Further Reading * All (Uses Mediawiki's includes to create a page including all sub pages; very useful for printing reading offline) These pages would be located respectively at * http://microformats.org/wiki/hcard/Specification * http://microformats.org/wiki/hcard/Tutorial * http://microformats.org/wiki/hcard/Examples * http://microformats.org/wiki/hcard/Use_cases * http://microformats.org/wiki/hcard/Reference * http://microformats.org/wiki/hcard/Discussion * http://microformats.org/wiki/hcard/Brainstorming * http://microformats.org/wiki/hcard/Implementations * http://microformats.org/wiki/hcard/Related_Pages * http://microformats.org/wiki/hcard/Further_Reading * http://microformats.org/wiki/hcard/All Please note I am suggesting an architecture not a specific list of sub pages. The list of sub pages should be defined by both reviewing existing information during site reorganization, and then via discussion on the list in an attempt to discover and extract which sub pages are needed for most/all microformats. Hope this is useful... -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin West Sent: Monday, October 16, 2006 5:29 PM To: Microformats Discuss Subject: Re: [uf-discuss] hCalendar spec- no specification included! On 10/16/06, Justin Thorp [EMAIL PROTECTED] wrote: Ben, I really like your idea of giving the wiki a better sense of organization. Justin, thanks, but this isn't my idea. Many others have expressed their ideas and desires as well. Is it possible within MediaWiki to have some type of sidebar navigation with this site organization on it? Interesting idea. Would you mind suggesting this on the to-do page? You can create your own section or feel free to put it under mine. If enough people comment in my section, I'll split the whole section off as it's own Wiki Improvement section. Please add this to http://microformats.org/wiki/to-do#Ben_West_.28bewest.29 under information architecture. Be sure to leave your name. I think this would help users to better find the information that they are looking for. For example, I am a user who could care less about the specification and cares more about how to write an hCard or hCalendar. I want to see whats possible and some examples. So your first inclination is authoring? What kind of websites do you author? Are you more of a graphic designer or a web developer? If there were a landing page for a specific microformat (as Andy and cgriego have suggested. I beleive I'm hearing more and more consensus on this.) that had large items such as: * What is this? * What can I do here? * Show me a demo. * Create an hCard Which one would look most promising? If create an hcard went to the hcard creator, would this suprise you? I didn't even see that there was a page on authoring within the pages and pages of specification. Even with it at the top of the page. I glanced right over it. It seems like most tutorials on hCard or hCalendar point people to the spec to get more information. Should we be encouraging people to point to the authoring page? I think a newbie would be very very very intimidated being pointed right to the spec. Call me sick, but this is exactly the kind of thing I'm looking to collect. I've added it to http://microformats.org/wiki/wiki-feedback. Can everyone add their favorite complaint? Ben
Re: [uf-discuss] ANN: The Purpose of Microformats
Mike, I've added the lack of goals to wiki-feedback. I've also added to the faq http://microformats.org/wiki/faq#Class_semantics to add your point about multiple classes in elements. It needs some polishing; I did little more than ask the question and then answer yes. Ben On 10/16/06, Mike Schinkel [EMAIL PROTECTED] wrote: Another nit I just realized. I think you need to point out that it is legal to have more than one class in a class attribute (i.e. class=foo bar). I always assumed that you could have only have one class per element. My immediate reaction to Microformats was they were not practical until my misconception was cleared after which I became a convert. I would guess a lot of people might have a similar misconception. -Mike -Original Message- From: Mike Schinkel [mailto:[EMAIL PROTECTED] Sent: Monday, October 16, 2006 9:45 PM To: 'Microformats Discuss' Subject: RE: [uf-discuss] ANN: The Purpose of Microformats Roger: Nit: Semantic Hooks mentions class, rel, and rev but not title. Next, my first thought was I found the beginning confusing. The first slide I read is Purpose of Microformats and the second is (X)HTML. As I read the second (and third) I'm trying to figure out where the microformat examples are. I guess I was expecting and introductory statement about the purpose and then an overview of what your are going to tell explain. You know, the old Tell 'em what you're going to tell 'em, then tell 'em, then tell 'em what you said. I understand why you are giving background on XHTML, but for someone who doesn't already understand the subject I think the current organization could be very disorienting. That said, I started jotting down notes until I had completely restructured your presentation (based on my 7+ years experience in developing programming courseware and delivering those courses.) I'll include my note below my signature, but please accept them as merely suggestions to consider and, as I have no price of authorship, feel free to incorporate or discard any of my suggestions. Also please note, I didn't flesh everything out, so if you do incorporate a significant number of my suggestions you'll certainly need to rework some of it as I didn't flesh it out exhaustively, and in two case I left to be written with notes. JMTCW. -Mike Schinkel http://www.mikeschinkel.com/blog http://www.welldesignedurls.org/ = * Title Slide * Purpose of Microformats -- The purpose of microformats is to enrich the semantics of web Pages * To be covered -- What Problem do Microformats Solve? - See USe-cases for Microformats below, To be written -- Background: Let's Define Web Pages - Use (X)HTML page, Browser Rendering, (X)Html Semantics -- Goals and Constraints Chosen for Microformats - Use Microformat Goals (See below, to be written) - These Constraints are Sacred (from below) -- Example Microformat - Use existing -- Benefits - Use Aggregating Microformats, Other? -- Summary - Use (edited version of) Purpose of Microformats (Revised) -- Brilliance of Microformats - Use existing * Use-cases for Microformats -- (I don't think I've an explicit list mentioned anywhere yet) -- (If would be good to get a common set of use-cases to help everyone target the same outcomes) * Microformat Goals -- (This I know instintively but can't put into words in the context of goals. -- (Nothing I could find on Microformats.org is explicit in defining goals) -- (If would be good if there were a consensus, or at least if we were all aware.) * These Constraints were considered Sacred: -- No Update to existing Browsers Required - Use No New Markup (Change Markup to (X)HTML Tags and add Required) - Use Semantic Hooks, rename to Enhancing Semantics using Existing (X)HTML Tags - Use Many Ways to Mark Up Information, rename to Any Element can be Described -- No Impact to Presentation - Use existing slide -- Controlled process to eliminate Chaos - Use Standardized Class Values = -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Costello, Roger L. Sent: Monday, October 16, 2006 7:28 AM To: Microformats Discuss Subject: RE: [uf-discuss] ANN: The Purpose of Microformats Thanks Rob. Good suggestion. I have added two new slides - one that shows an example Microformat, the second shows an aggregator collecting Microformats in Web pages. http://www.xfront.com/microformats/Purpose-of-Microformats.html Thanks! /Roger -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Unsworth Sent: Sunday, October 15, 2006 7:56 PM To: Microformats Discuss Subject: RE: [uf-discuss] ANN: The Purpose of Microformats On Sun, 15 Oct 2006, Costello, Roger L. wrote: Thanks a lot Tantek. That's exactly the kind of feedback I was seeking. I have made a few changes (added a couple new slides, modified a few slides). Please let me know if
Re: [uf-discuss] hCalendar spec- no specification included!
Mike, this is great. I really like it. Remember to check back and make sure progress is happening. Feel free to give me a nudge if I'm unresponsive. Ben On 10/16/06, Mike Schinkel [EMAIL PROTECTED] wrote: Would you mind confiming this on the to-do page under my name [1]? I added, see if it is what you were wanting... If it somehow differs from the suggestions there (under information architecture) would you please explain how it differs? Okay. Note I did not change anything outside my comments, I just added my comments. Also please list your specific suggestions, as well as, if possible, where content for the pages you suggest may be gleaned, The current microformat pages (i.e. http://microformats.org/wiki/hcard/) and any they reference. I think this will become obvious during reorganization. and which pages would need new content that doesn't yet exist. I think any list I create on my own (beyond my first list, which is just a starting point) will be ill-conceived and incomplete. They need to be gleened during the process of reorganization as a collective effort. I think you may have illuminated the intent more clearly than it has been explained so far, and so your refinement on the wiki would be very helpful. Thanks for the ack. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin West Sent: Tuesday, October 17, 2006 12:12 AM To: Microformats Discuss Subject: Re: [uf-discuss] hCalendar spec- no specification included! Mike, Thanks for you suggestion. I believe this is exactly what cgriego and Andy and I have just suggested. Would you mind confiming this on the to-do page under my name [1]? If it somehow differs from the suggestions there (under information architecture) would you please explain how it differs? Also please list your specific suggestions, as well as, if possible, where content for the pages you suggest may be gleaned, and which pages would need new content that doesn't yet exist. I think you may have illuminated the intent more clearly than it has been explained so far, and so your refinement on the wiki would be very helpful. Thanks, Ben [1] http://microformats.org/wiki/to-do#Information_Architecture On 10/16/06, Mike Schinkel [EMAIL PROTECTED] wrote: I agree that the current layout is confusing. After reading several of these email I would like to make a suggestion that is smaller scope than an entire reorganization (which still might be a good idea.) Tantek suggests that the specifications are not tutorials and others have said that they (think newbies would be) interested in authoring, not the specification and I concur. What if we use a convention that the entry page (i.e. http://microformats.org/wiki/hcard) would be an index into a list of (psuedo) standardized sub pages so that it would be very people to find what is important to them. For example, is a list of potential sub pages: * Specification * Tutorial * Examples * Use cases * Reference * Discussion * Brainstorming (might be combined w/Discussion) * Implementations * Related Pages * Further Reading * All (Uses Mediawiki's includes to create a page including all sub pages; very useful for printing reading offline) These pages would be located respectively at * http://microformats.org/wiki/hcard/Specification * http://microformats.org/wiki/hcard/Tutorial * http://microformats.org/wiki/hcard/Examples * http://microformats.org/wiki/hcard/Use_cases * http://microformats.org/wiki/hcard/Reference * http://microformats.org/wiki/hcard/Discussion * http://microformats.org/wiki/hcard/Brainstorming * http://microformats.org/wiki/hcard/Implementations * http://microformats.org/wiki/hcard/Related_Pages * http://microformats.org/wiki/hcard/Further_Reading * http://microformats.org/wiki/hcard/All Please note I am suggesting an architecture not a specific list of sub pages. The list of sub pages should be defined by both reviewing existing information during site reorganization, and then via discussion on the list in an attempt to discover and extract which sub pages are needed for most/all microformats. Hope this is useful... -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin West Sent: Monday, October 16, 2006 5:29 PM To: Microformats Discuss Subject: Re: [uf-discuss] hCalendar spec- no specification included! On 10/16/06, Justin Thorp [EMAIL PROTECTED] wrote: Ben, I really like your idea of giving the wiki a better sense of organization. Justin, thanks, but this isn't my idea. Many others have expressed their ideas and desires as well. Is it possible within MediaWiki to have some type of sidebar navigation with this site organization on it? Interesting idea. Would you mind suggesting this on the to-do page? You can create your own section or feel free to put it under mine. If enough people comment in my section, I'll
Re: [uf-discuss] Four questions about hCard
http://microformats.org/wiki/hcard#Organization_Contact_Info covers the issue of how to use an hCard to represent an organization:. Some questions for Roger: * Did you see this resource? * If you hadn't seen it, if you had seen it, would it still have been unclear how to mark up for an organization? * If you did see it, was there anything in particular that was ambiguous? * Any suggestions on making the resource mentioned a bit more salient? (easier to find, easier to read?) Thanks. Ben On 10/7/06, Brian Suda [EMAIL PROTECTED] wrote: On 10/7/06, Costello, Roger L. [EMAIL PROTECTED] wrote: Hi Folks, 1. Can an organization have an hCard? --- sure, the easiest way to achive this, is to use FN and ORG on the same element span class=fn orgABC Widgets Co./span 2. Is the property n (name) mandatory? --- no, for companies this is just left blank. (or omitted in your case) 3. The property n is composed of these subproperties: family-name, given-name, additional-name, name-prefix, name-suffix. Which of the subproperties are mandatory, which are optional? --- for companies it is optional. For people, we ask that you fill-out as much as possible, but if i had to say minimum, then a first name or last name would be nice. 4. If n is mandatory, and the hCard is for an organization, what is the meaning of family-name, given-name, additional-name, name-prefix, name-suffix in that context? --- it's not manditory, so you don't have to worry about any of this. -brian -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Tentative proposal for What's New listings
Wow. Nice job all around! Here's my added twist to it. I took the URI Andy just posted, and sent it through lm orchard's xstlproc on the web to fetch my rss to hyperscope xslt and transform it. Since he's got hyperscope on his host, the document displays just fine. Incredible stuff. http://decafbad.com/2005/11/gopher-ng/xsltproc?xslAddr=http://dichotomize.com/hp/rss2hp.xsldocAddr=http%3A%2F%2Fxoxotools.ning.com%2Fhatom2rss.php%3Fxn_auth%3Dno%26url%3Dhttp%253A%252F%252Fwww.westmidlandbirdclub.com%252Fladywalk%252Flatest.htm Ben On 10/7/06, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Stephen Paul Weber [EMAIL PROTECTED] writes Wow... this converter has never been through a full-scale test before (only tested on my own pages)... so ya... that shouldn't happen. I think I may know the problem, and will try to fix it soon :) Thanks for finding all this stuff! I'd like to thank Stephen publicly, as I have done in private e-mail, for the sterling work he's done, resolving these and other issues, as can be seen in: http://xoxotools.ning.com/hatom2rss.php?xn_auth=nourl=http%3A%2F%2Fwww.westmidlandbirdclub.com%2Fladywalk%2Flatest.htm -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Examples in Wiki
Can you make a list of places that don't seem consistent and add them to the todo page? On 10/5/06, Ryan King [EMAIL PROTECTED] wrote: On Oct 4, 2006, at 9:45 PM, Bob Jonkman wrote: Hi all: I've been looking at the examples on the Wiki, especially hCard, hCalendar and hResume. Many of the examples in the Wiki give the original format (vCard, iCalendar), then how the microformat should be coded, then How this might look. But not always: sometimes the original format portion is missing; sometimes the How this might look is missing. Sometimes the How this might look is actually marked up with microformats, which allows those of us with microformat tools in our browsers to see the proper behaviour. Most often that's not the case, tho. Are there any style guidelines for preparing examples? If not, any suggestions from the list? I've written a good deal of those examples- there aren't any specific style guidelines, just try to keep things consistent. I propose that whereever possible an example should consist of all three portions, with the How this might look portion properly marked up so that it triggers all the correct behaviours in the browser. I agree. Go for it! :D -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Live Writer and microformats
Just to build on what Ryan said about optimization for publishers: Yes, microformats can be hard to parse. However, it is significantly easier than attempting to parse this information in the absence of microformats (just plain text, or plain old html [POH, anyone?]). Ben On 10/6/06, Ryan King [EMAIL PROTECTED] wrote: On Oct 6, 2006, at 1:19 AM, Joe Andrieu wrote: Because of the current structure of microformats, as a way of thinking and as a process, I believe it is inherently incapable of handling a rapidly growing list of microformats. Someone once said to a proposal of mine that a large number of microformats was in fact an anti-goal. The way the system is set up, neither the supporting technologies nor the uF community is capable of handling a rapidly growing set of uF. We have a very slow, painstaking process, Have you tried any other standards processes? According to a talk [1] given by Tim Bray (see notes [2]), the atom syndication format took over 17,000 email messages to work out. And you know what? It's not done, its still in draft (or maybe proposed). They have at least one more round before finishing. On the other hand, I see 6,277 total messages in the history of this mailing list. In that time we've done hAtom, hResume, adr, geo, rel- directory, hListing and talked about a number of other examples. It may not seem it, but this is the fast way to do data format standards. Consensus takes time. Community takes time. Second, because there is no mechanism for discovery of microformats, every tool has to be hand-carved to handle each microformat it wants to support. In contrast, if we required profiles, and if profiles provided a machine readable schema of the microformat, tools could at least present users with structured data that at least retains its typed values. Of course, the /semantic/ value of that auto-discovered microformat is more challenging; we don't have a good way to define arbitrary semantics. But at least the data can be extracted and managed in a lossless fashion. Plus, if the format contains well-understood components such as hCard or hEvent, at least the application could provide reasonable interfaces and functionality for those. The idea of auto-magically making microformats work is a dream. I'll believe it when I see it. For a hint at some of the challenges, read http://microformats.org/wiki/hcard-parsing . Parsing, extracting or using microformats is not intended to be easy for consumers. Remember, we're optimizing for publishers, which means that we'll often create situations that put a burden on consumers. However, there's more producers than consumers, so the economics here are good. Also, we could try to require profiles, but I don't think it'd make any difference. The reality is that a lot of content on the web is published with systems that don't allow authors to edit the head / of the document. If we were to require them, I could see two outcomes: 1. Only a minority of people use them. Consumers will have to deal with it the same we deal with it today. 2. The publishing tools start putting all of the profile URIs in the [EMAIL PROTECTED], just in case their users publish microformatted content through their CMS. I don't see either of those scenarios being helpful for us. So, I think it is important to realize that the fundamental structure of uF as a process, organization, and way of thinking, inherently restricts the pace of growth. uF is set up to slowly forge several dozens of uF, crafting socially accepted, shared semantics and encoding standards for use in semantic XHTML. Good stuff. And far more accessible and useful than most of the other semantic web technologies out there. The structure of the process and community is built to produce good results. Good results take time and work. Still, as I mentioned above, I think we're able to produce good results in less time with less work. With all that said, maybe I'm looking at things upside down. I asked Tantek early on how microformats scaled. His reply was that could be better answered over a beer. Unfortunately, I haven't made it to any of the social functions to chat over that beer, so maybe I could get some clarification here. I'm I missing something? Or is the scaling of uF, in terms of the # of uF, constrained as I've outlined here? The growth is constrained to the formats we can successfully create. Quality is better than speed. At the same time, organizational development is a wicked hard problem and one we should be very delicate in approaching, if approaching it at all. Perhaps even harder than writing software or developing data format standards. :D -ryan 1. http://www.tbray.org/talks/etech2006 2. http://www.windley.com/archives/2006/03/tim_bray_on_ato.shtml ___ microformats-discuss mailing list microformats-discuss@microformats.org
Re: [uf-discuss] Live Writer and microformats
Quick Summary: * MF mention starts about a quarter of the way in. * hCalendar in particular Neat. It's a bit long; microformats are mentioned about a quarter of the way in after talking about tables and links. Much of the discussion that follows is about microformats, hCalendar in particular. Eventful is also mentioned favorably. Just past the halfway point, the developers start turning discussion more towards live clipboard. They briefly wrap up mentioning the benefits of federated publishing services, but don't touch on the fact the benefits stem from the fact that microformats are visible data. They go on to talk about plugins for Live Writer. On 10/3/06, Conor O'Neill [EMAIL PROTECTED] wrote: I'm not sure if any of you spotted this as it was not part of the original release notes but Windows Live Writer now has a plug-in which allows you to insert hCalendar events in your blog posts. You can also search for events in Eventful and paste them in and thirdly, Live Clipboard now works from Eventful to Live Writer which is a fabulous real world example of Live Clipboard and hCalendar. I'm really impressed that MS have done this. Fingers crossed they start supporting some of the other microformats. I wrote more about it over at argolon.com and I originally saw it in a video interview that Jon Udell did with Jack Ozzie and JJ Allaire over at http://weblog.infoworld.com/udell/screenroom/livewriter_flv.html. Conor ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Wiki editing issues
This is clearly a usability problem. This is a re-ocurring complaint in the IRC channel as well. Is our only answer really you need to change your username to UserName.!? On 9/27/06, brian suda [EMAIL PROTECTED] wrote: Andy Mabbett wrote: Finally (from me, for now), I've had an e-mail from someone wanting to comment on the species proposal, saying: I've just tried creating an account on the microformats site so that I can join in with the discussion, but whenever I try to sign up, I get a message telling me 'You have not specified a valid user name'. I've tried various permutations without any luck. Did you have any trouble when signing up? and, indeed I did - and couldn't figure out why the user name I wanted to use was not being accepted. The Microformats Wiki runs on Media Wiki, so some of these weird editting problems are out of our hands (not sure which version we are running and if there is an upgrade? - i don't think we did much customization?) As for creating accounts. You UserName has to be CamelCase[1], there should be a note about it on the sign-up page, it is on the FAQs, *Any Suggestions about how to make it more visible* are certainly welcome? [1] - http://microformats.org/wiki/faq#wiki_specific_questions ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Re: [uf-discuss] XOXO-2-OPML LazyWeb Request
This has already been done twice by Les Orchard: http://decafbad.com/trac/wiki/XoxoOutliner http://decafbad.com/blog/2005/12/01/feedrolls-in-xoxo-from-opml-via-xslt-and-url-line-magic http://decafbad.com/2005/11/gopher-ng/xoxo-to-hyperscope.xsl http://blueoxen.net/c/hyperscope/wiki.pl?HyperScopeTransformers#nidG8 Enjoy. Ben On 9/25/06, Brian Suda [EMAIL PROTECTED] wrote: excellent! looking at the code, we pretty much arrived at the same thing - what license do you plan on releasing this as? and when you finish you should add it to the Implementations list on the Wiki. what i'd really like is to find out, via Lazy Web, what and if any, New Readers can accept XOXO straight and/or which properly import the XOXO2OPML.xsl output. I also had a look at the NING implimentation and they mostly do the same thing, except it is a flat OPML, no nested outline and they don't manage to create Absolute URLs from any @href, but they do take input/output to various formats. Does anyone know who wrote that and under what license it is? and we look under the hood and see/improve what it is doing? thanks, Anyone else know of any links/services? -brian On 9/25/06, Dietrich Ayala [EMAIL PROTECTED] wrote: I wrote this a few months ago, but haven't had time to look at since. YMMV :) http://dietrich.ganx4.com/microformats/xoxo2opml.xsl On 9/25/06, Brian Suda [EMAIL PROTECTED] wrote: As most folks have some sort of Blogroll (hopefully marked-up with XFN and XOXO[1]). I have begun to look into easily converting those into OPML. I've only worked with OPML for a day now and it has left a sour taste in my mouth!!! So i never want to write OPML again, instead i want to write happy XOXO and build (if needed) OPML from that. I went and started in on an XSLT and web service[3] to convert any HTML page with XOXO into OPML. It isn't perfect, and makes use of the Special Properties section[2] of the XOXO spec - so if you find issues/errors/problems/ideas let me know. I have tested it on my own site*, but now i envoke the Power of Lazy Web! I am looking for Folks to do two things: 1) run their XOXO files through the web sevice and see if they get the expected OPML back 1a) which blog platform are you using (if any) 2) document which NewsReaders/OS correctly consume the OPML. 2a) does the RSS reader do 'auto-discovery'? meaning if i send it a link to the blog homepage, does it extract the RSS correctly from the HTML link? I have started a wiki page with a simple structure to let others add their information too[4]. Thanks, -brian [1] - http://microformats.org/wiki/xoxo [2] - http://microformats.org/wiki/xoxo#Special_Properties [3] - http://suda.co.uk/projects/microformats/xoxo/ [4] - http://microformats.org/wiki/xoxo-opml-issues * - i am aware that not everything in my XOXO list is a feed - some NewsReaders Ignore them, some try to fetch something and just fail. -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Employee number
I do this kind of thing all the time. For example, I have something that allows me to transclude bug information across internal wiki's by including some javascript that looks for things like span class=sugar bug title=bug_number345/span . When the bookmarklet/javascript runs, it looks up the bug in the bug database and includes the information about the bug on the page. Sounds very similar to what you are trying to do. Have fun with it :-). On 9/19/06, Ryan King [EMAIL PROTECTED] wrote: On Sep 19, 2006, at 1:08 PM, Scott Reynen wrote: On Aug 16, 2006, at 4:46 PM, Paul Denning wrote: Within my company, a number of internal services use our employee number in the URL. I would like to have bookmarklets that can find and extract the employee number from the current page in my browser, then insert the employee number into a different URL for another internal service that uses the employee number as a parameter.. Is there a microformat that would help me find the employee number on a page? Is there a microformat to indicate that a string is an employee number, or more generically, an identifier from a particular identifier system or identity provider. Sounds like a use case for URIs [1] and/or UIDs [2]. It also sounds like a very specific use case. Create your own standard markup and write the bookmarklet then share as much as you can. Perhaps others will follow suit and create a common practice. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Re: [uf-discuss] hAtom editor?
What is the DashPress widget? I copy/pasted from Firefox's view source from hReview creator. Tantek's name got mangled somewhere in there... fixing any moment now. On 9/10/06, Chris Messina [EMAIL PROTECTED] wrote: BTW, typo on Tantek's name in the credits. How easy would it be to take something like the DashPress widget, extract the XML-RPC JS and allow people to post to any blog from that page? Chris On 9/10/06, Benjamin West [EMAIL PROTECTED] wrote: Here's a really dumb, minimal version: http://dichotomize.com/uf/hatom/creator.html 1.) no harm in doing it anyway. 2.) it was a rather easy win 3.) It generated a lot of ideas. see the todo list. 4.) it still fulfilles the purpose of showing other developers how fields match classnames. 5.) good practice for fancier editors in the future. On 9/9/06, Lucas Gonze [EMAIL PROTECTED] wrote: On 9/9/06, Stephen Paul Weber [EMAIL PROTECTED] wrote: Uhh... hAtom is more meant to mark up your entire blog, not just individual posts. Better to edit the blog's template Ah! Right! Like a lot of sexy ideas, it didn't make sense at all. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- Chris Messina Citizen Provocateur Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: Use with Greasemonkey?
Great idea! I'm cross posting lists because this particular post has a lot in common. Seems to be that copy-pasting the behaviour.js script inline with your GM script would work no need to load it remotely. Not sure what you mean by the obvious way, although I'm not terribly familiar with GM. Another, perhaps simpler, solution is to just steal the getElementsBySelector() implementation from either behaviour.js or prototoype.js (introduced in 1.5 as $$() ). I'd like to point you to microformats.org. The folks over there (including myself) are always interested in collecting and advocating these kinds of instances of semantic markup. Have you seen many people publishing links like this? The more people that do this kind of thing, the more effective html becomes. Specifically, the microformats crowd tries to catalogue and agree upon these kinds of uses, so that more people can use them. Ben West On 8/12/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Is it at all possible to use behaviour.js with a GreaseMonkey script? If so, I'd love to add user behaviors to the list of user-overridable features, along with user styles and user scripts. Seems like it'd be very useful for some things like my idea for a voluntary NSFW blocker. If any link has rel=nsfw, I'd like the page to throw up a dialog box asking the user if they intended to follow the link or not. Seems safer for work environments than a small NSFW in parens, but I digress. I was just wondering about the use of GM/behaviour. I tried the obvious way, but it failed due to security constraints within GM. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Behaviour Javascript Library group. To post to this group, send email to [EMAIL PROTECTED] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/behaviour -~--~~~~--~~--~--~--- ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Is Music dead? (I hope not!)
I've been watching this thread with some hesitation. I'm from the classical world and am usually frustrated with the attributes most people capture in music meta formats. Consumption of classical music is a bit different from pop music. The attributes of data that are important shift meanings through different genres. In classical, the concept of composer and performer is relatively loosely coupled compared to pop when they are usually the same thing. In addition, composers often stand on the shoulders of giants, and there are multiple versions built on top of eachother... an example would be the Bach-Gounod Ave Maria. For this, you essentially have attributable text, a melody composer, and then an arranger, all from very different time periods. On top of this, you would have subsequent arrangements (a choir version vs a solo version) in addition to the performer or groups performing in addition to date and location of that specific performance. What I find is that most people into New Media miss these subtleties. I've never seen an id3 tagging that does a good job conveying all of this information. I know microformats aim to take advantage of the 80/20 rule... does this mean classical music will get the cold shoulder with all its edge and special cases? On the other hand separate formats for genres of music doesn't seem like a good solution either. Anyway, a site to check out would be http://www.allmusic.com/ . For years, they've been publishing data /about/ music in every genre. They used to have separate sites, eg, allclassical.com alljazz.com and then combined them under the now familiar allmusic.com. Notice that the emphasis on what information is conveyed is different within each genre. It seems to me that a microformat for music would either have different formats for different genres, leave certain attributes out (which I'm convinced would almost only negatively impact classical), or be incredibly time consuming flushing out all the edge cases (typically avoided). -Ben (classical training in voice, cello, percussion, piano, some conducting) On 6/29/06, Alex Iskold [EMAIL PROTECTED] wrote: While we are on the subject of music. What about books and movies? Are ther any examples of these? Thanks, Alex alex iskold founder ceo adaptiveblue http://www.adaptiveblue.com - Original Message - From: Ryan Cannon [EMAIL PROTECTED] To: microformats-discuss@microformats.org Sent: Thursday, June 29, 2006 3:59 PM Subject: Re: [uf-discuss] Is Music dead? (I hope not!) Coincidentally I was kicking this around in my head last night. I plan on researching and co-opting existing idioms if they exist, and actually started listing some examples of Artist/Release/Track data in music-examples before it became clear to me that this may not have been its intention-- it reads like it may have been set up to do something more along the lines of what media-info is set up to do. One thing that neither of these pages mention is ID3v2[1], whose implementation in iTunes appears (from a consumer's standpoint) to contain all necessary metadata for music files, and is pretty widespread. A little wikipedia reading let me know that there are some competing formats: APEv2[2] and Vorbis Comments[3]. One problem that creating such a microformat might solve is the idea of an authoritative media tag—i.e. a publisher could create (x)html pages that can provide generate the official metadata for digitized music. [1] http://www.id3.org/ [2] http://en.wikipedia.org/wiki/APEv2_tag [3] http://en.wikipedia.org/wiki/Vorbis_comment -- Ryan Cannon Interactive Developer MSI Student, School of Information University of Michigan http://RyanCannon.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
