RE: [uf-discuss] how do i submit something for consideration?
Charles, Funny, I've been planning to write a blog post entitled something like What's the one thing wrong with Open-Source? Forking! :) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Iliya Krempeaux Sent: Thursday, October 26, 2006 4:45 PM To: Microformats Discuss Subject: Re: [uf-discuss] how do i submit something for consideration? Hello Jonathan, (This does NOT have anything to do with the Microformats aspect of it, but) Just out of curiousity, why the No Derivative part for the license for the specification? (To be open wouldn't anybody need to be able to make derivatives, and not just one person or more group of people?) Here's a good article on openness and specifications... http://goland.org/buyingopenstandards (I'd probably go further than this article... but it's a good start.) See ya On 10/26/06, Jonathan Vanasco [EMAIL PROTECTED] wrote: Hi. I've recently soft-launched a distributed identity webapp that I've split out of another project, and released several aspects of that application as open standards ( Creative Commons Attribution-No Derivative Works 2.5 License ) I don't know how / where to submit it for potential consideration as a microformat , or even if they qualify ( one supports human readable , but is geared to be machine readable ; the other is more of an interchange format , but works well as semantic markup ) - so I came here. The summaries: findmeon design: essentially a subset of XML-DSIG with some FOAF / XFN semantics tossed in , and coerced to validate in XHTML strict designed for machine readability , but supports human readability (90% of content would usually be hidden though) unfortunately must support a non-standard 'compressed' url- encoding to let it clear as validated text on several social networks and forum software ( required because certain tags/attributes were often stripped ) usage: openly claim / verify / link multiple websites together via RSA 1024 public key pairings within a distributed self-sufficient framework hopefully will end proprietary 'i own this blog/whatever' codes designed so that resources do not need to know about one another or a central server in order to be linked/verified by a public key originated from: a need to map artist/label/venue/etc information on a music site to official sites / online profiles ; map users of a music site onto other sites for verifiability in trading concert tickets or making online requests / contest entries specification status: the current release works as it should, so any feedback/changes would be merged into a future release open_sn design: a dirty dirty hack standardizes the most common social network / dating site / online account profile fields that do not natively appear in existing specifications its really quite a bad 'standard' -- but it serves its purpose primarily designed as an interchange format, but works pretty well in terms of semantic markup usage: mostly an interchange format for migrating data between accounts specification status: very much open for immediate improvement / replacement. its a dirty dirty hack. The full text / description of both standards are available at http://findmeon.org I'd welcome any feedback. Thanks, // Jonathan Vanasco | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | FindMeOn.com - The cure for Multiple Web Personality Disorder Web | Identity Management and 3D Social Networking | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | RoadSound.com - Tools For Bands, Stuff For Fans Collaborative Online | Management And Syndication Tools | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ 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] include-pattern support for data outside of the current page? [Was: Visible Data...a Microformat requirement?]
Is it good for the interpretation of the data on one page to rely on data on another page? anyone has an opinion? My knee-jerk reaction is that it is very bad practice to have what would essentially be the legend to be on a separate page. Very, very bad. When I use to teach programming, one of the things I always pointed out was that proximity increases maintainability. This is kinda similar. (Of course I'm open to someone explaining a use-case and/or rationale for this situation that I had not previously considered.) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guillaume Lebleu Sent: Thursday, October 26, 2006 2:23 PM To: Microformats Discuss Subject: [uf-discuss] include-pattern support for data outside of the current page? [Was: Visible Data...a Microformat requirement?] The thread around invisble microformats reminded me of this example from the visible Web. Maybe relevant to this discussion, if not relevant to the include-pattern. An index page (http://www.eia.doe.gov/emeu/international/oilprice.html) contains currency information that applies to all pages it indexes. For instance, in this data page (http://quotes.ino.com/exchanges/?r=NYMEX_CL), there is no unit/currency defined, and we only know the numbers are U.S. Dollars per barrel b/c it was defined in the separate page we came from. Should my data page contains an include-pattern link to the currency definition from the other page? Is it good for the interpretation of the data on one page to rely on data on another page? anyone has an opinion? I'm asking since I haven't seen on the include-pattern page any clear direction on this. Guillaume ___ 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?
Because it hasn't gone through the (fairly rigorous) demands of the uF process -- the process page on the wiki[1] outlines this. But what I'm hearing is that if it's not visible it cannot go through that process... -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colin Barrett Sent: Thursday, October 26, 2006 1:38 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? On Oct 26, 2006, at 7:28 AM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Dr. Ernie Prabhakar [EMAIL PROTECTED] writes As long as you don't call it a microformat, feel free to experiment. :-) Why shouldn't he call it a microformat? Because it hasn't gone through the (fairly rigorous) demands of the uF process -- the process page on the wiki[1] outlines this. -Colin [1] http://microformats.org/wiki/process ___ 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?
Yes I was joking, but in the sense of Many a truth said in jest. In my 20+ years in the tech industry I don't think I've a group of people who can be more religious than those discussing technical matters, excepting fundamentalists in any real religion. :) And because religions tend to promote absolutes, they create lots of problems and impede the forward progress of pragmatists. Thus I was trying to make a point without being too pointed. ;) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Mabbett Sent: Thursday, October 26, 2006 1:28 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? In message [EMAIL PROTECTED], Mike Schinkel [EMAIL PROTECTED] writes cardinal sin Is this a pragmatic group that I'm working with, or a bunch of religious zealots that I've managed to get entangle with? [assuming you're not joking] cardinal in this sense means: essential; of foremost importance; paramount and cardinal sin is a common idiom. See, for example: http://www.answers.com/cardinalr=67 -- 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] Visible Data...a Microformat requirement?
that is *only* for machine consumption Conversely, if he's unsure whether the metadata *has* to be invisible, then perhaps this is still a worthwhile discussion. For clarity, there is nothing that says that the metadata I was proposing and am additionally envisioning couldn't be visible. It might even become a best practice to make it visible. But in current practice today the data typically isn't visible (if it is there, which is unlikely) and some people might not want to make it visible (probably because they have a pre-Web 2.0 mentality, IMO.) However, if the end result is *outside* the scope of how we as a community understand microformats, don't expect to get a lot of official support Without support, it make little sense to do it, which IMO means creating a parallel initiative which is duplicated effort, will confuse the public, and is just not a good idea all round. But if I can't convince the group that it makes sense, I certainly can't berate the group into doing it. So if I get a consistent no then that's that (kinda funny how in the early days of the web everyone wanted to splinter. :) In particular, it would be confusing for him to call his proposal a microformat if it did not go through the documented microformat process Agreed. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dr. Ernie Prabhakar Sent: Thursday, October 26, 2006 1:38 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? Hi Andy, On Oct 26, 2006, at 10:28 AM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Dr. Ernie Prabhakar [EMAIL PROTECTED] writes As long as you don't call it a microformat, feel free to experiment. :-) Why shouldn't he call it a microformat? Sorry, I may have conflated too many issues. The point I wanted to make (which I communicated poorly) is: a) If he's committed to marking up *invisible* metadata that is *only* for machine consumption, then [IMHO] that's beyond the scope of what this group was constituted to do. b) Conversely, if he's unsure whether the metadata *has* to be invisible, then perhaps this is still a worthwhile discussion. c) Either way, he's welcome to experiment with microformat-derived ideas d) However, if the end result is *outside* the scope of how we as a community understand microformats, don't expect to get a lot of official support e) In particular, it would be confusing for him to call his proposal a microformat if it did not go through the documented microformat process http://microformats.org/wiki/process I apologize if that came across as needlessly confrontational. Best, -- Ernie P. ___ 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?
My suggestion to use invisible data formats was prefaced with the scenario that your data is invisible, based on the subject of this thread. The above criteria seem to contradict the subject of this thread. If that is the case, I apologize. I envision several different needs although not all of them are fleshed out yet. And these are not needs I just think people might have, they are needs that I've envision I will need in order to optimize some projects I have planned. Is the data published on the web today or not? If it is, you should start collecting it and analyzing to see if it's suitable for a microformat. It is possible. I'm doing tons of research right now (killing many trees printing off documents at the W3.org and elsewhere). But maybe not. If it's not published, we can't research the publishing, so we'd be creating a microformat based on assumptions. The example I gave is straightforward, and respectfully I don't think there would be a lot of assumptions. Let me give another example for this use-case (although I'm learning there may be existing things in HTML to resolve this one specific use case.) Consider these three URLs: http://www.foo.com/toyota/4runner/1999/ http://www.foo.com/toyota/1999/4runner/ http://www.foo.com/1999/toyota/4runner/ Assuming they point to the same basic content but have different breadcrumbs: Home Toyota 4Runner 1999 Home Toyota 1999 4Runner Home 1999 Toyota 4Runner However, there really are the same page and I'd like to be able to say that one of them is the primary or authoritative one (the website owner would decide which one) and in the two that are not primary or authoritative they would point to the one that is. It's possible that you could have the following visible on the page: This page is a duplicate of a href=http://www.foo.com/toyota/4runner/1999/; rel=primarywww.foo.com/toyota/4runner/1999//a. As I said, this is but one example of data that helps describe a page that I can envision I will need and that I believe could benefit the web in general if it exists. I wish I had fleshed out my other examples at this point but I haven't yet, and I certainly don't want to get the shot down because I present them prematurely prepared. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Reynen Sent: Thursday, October 26, 2006 1:46 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? On Oct 26, 2006, at 3:07 AM, Mike Schinkel wrote: I'm still not convinced. I've only heard generalities and no specifics on anything I've heard regarding my use-case. RDF is far to complicated for the average person creating HTML; one reason why I don't think it will ever fly. I still know of nothing else besides Microformats that can fill this role; can you give me some specifics that: * Is very simple to add * Doesn't require access to head * Can be done today My suggestion to use invisible data formats was prefaced with the scenario that your data is invisible, based on the subject of this thread. The above criteria seem to contradict the subject of this thread. Is the data published on the web today or not? If it is, you should start collecting it and analyzing to see if it's suitable for a microformat. If it's not published, we can't research the publishing, so we'd be creating a microformat based on assumptions. Such an assumption-based process doesn't meet the standards we've been applying to the word microformat. We're not changing that standard because we, as a community, believe that basing formats on existing behavior is an important practice. There are other formats that are based on assumptions, and the complication you don't like is largely a result of that practice. Pick your poison. Peace, Scott ___ 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] how do i submit something for consideration?
Jonathan Vanasco wrote: I don't know how / where to submit it for potential consideration as a microformat Read the process. Then read it again, and again until you fully understand it, and then follow it. http://microformats.org/wiki/process You really need to start by documenting real world websites and the markup they use. The process most certainly doesn't start with a pre-written specification. Creative Commons Attribution-No Derivative Works 2.5 License That no derivatives clause effectively means we couldn't work on it to improve it, only you could, so that effectively rules it out of acceptance anyway (regardless of the other problems with the proposal). ... coerced to validate in XHTML strict Any microformat really needs to be usable in HTML, not just XHTML, because roughly 99.999% of the world effectively uses HTML. So that means the example markup you provide in the spec should be in HTML, not XHTML, or at the very least follow the guidelines in Appendix C. i.e. You can't use span/, which seems to be in every example. This is a copy of the long format example, copied from your current spec. span class=findmeon span class=Spec title=http://findmeon.org/spec/0_09/ * XML empty element syntax is not recommended. * Span is the wrong element for links. Use a. * What's the point of that element Is that a poor attempt at replacing the profile attribute? span class=SignedInfo span class=resource title=http://www.FindMeOn.com/ * See previous 3 points. span class=type title=url/ span class=subtype title=business/ span class=attributes span class=attribute title=primary/ /span * What the? span class=timestamp title=2006-04-26 19:18:45-04/ * See datetime design pattern. http://microformats.org/wiki/datetime-design-pattern /span span class=Signature span class=SignatureValue title=akjhasd span class=KeyInfo title= /span * That's not even well-formed. * Why is the signature hidden within the title attribute? * What is KeyInfo? Why is it empty? span class=SeeAlso a class=SeeAlso href=http://www.FindMeOn.com/findmeon/xx; rel=repository me/ a class=SeeAlso href=http://www.roadsound.com; rel=repository me/ a class=SeeAlso href=http://www.2xlp.com/foaf.rdf; rel=foaf me/ a class=SeeAlso href=http://www.2xlp.com/info.html; rel=xfn me/ a class=SeeAlso href=http://www.2xlp.com/info.html; rel=openid me/ * What are all these links for? * Why are they empty? * It looks like some sort of list, why not mark it up as such? /span /span designed for machine readability , but supports human readability (90% of content would usually be hidden though) Human readability? In that entire example, there was not one piece of visible content that the user could see. It's designed entirely for machine processing. usage: openly claim / verify / link multiple websites together via RSA 1024 public key pairings within a distributed self-sufficient framework hopefully will end proprietary 'i own this blog/whatever' codes designed so that resources do not need to know about one another or a central server in order to be linked/verified by a public key originated from: a need to map artist/label/venue/etc ... I have no idea how you think this format meets that use case. open_sn design: a dirty dirty hack standardizes the most common social network / dating site / online account profile fields that do not natively appear in existing specifications See http://microformats.org/wiki/profile-examples It would help if you could expand that page with more examples, and maybe even progress it to the next step. its really quite a bad 'standard' Fully agree! Also, search the archives for the recent discussion about personal profiles. -- Lachlan Hunt http://lachy.id.au/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Semanticizin': Significance of order in argument lists
This is something I just now realized, and while all excited, I thought I'd send to the list: When using HTML lists (ul/ol) for representing operand argument lists, it appears very logical to identify the distinction between ordered and unordered as that of and and or, respectively. In other words, ol lithis/li lithat/li /ol Can mean this and that. While, ul lithis/li lithat/li /ul infers this or that. I am sure somebody has thought of this before, but I haven't. Don't you think it's beautiful? :DG ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Semanticizin': Significance of order in argument lists
Dimitri Glazkov wrote: When using HTML lists (ul/ol) for representing operand argument lists, it appears very logical to identify the distinction between ordered and unordered as that of and and or, respectively. ol Can mean this and that. While, ul infers this or that. I really don't understand how you can equate the significance of the list item's order with the items having an and or an or relationship like that, nor what purpose such a distinction has. Could you please elaborate? -- Lachlan Hunt http://lachy.id.au/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Document Revision History uf
Hi, I was wondering if anyone has a working drafts or specs for a microformat for presenting document revision history. I don't want to reinvent any wheels -square, round or otherwise funny shaped - if I can help it. :) The reason I ask is that I've been looking at the Microsoft Simple Sharing Extensions to RSS which enable an easy way to add synchonization information to a RSS feed, and was investigating whether something similar could work for hCal, hCard, and hAtom. This could allow a calendar or addressbook client to easily know when it's data needs to be refreshed from a microformatted web page. For those of you who might not want to google for it, I'll summarize what SSE adds to RSS. 1) There are three extensions to the Channel information allowing a feed to be a time-based subsection of a larger feed. The first adds a tag for adding information about the time period a feed covers, the second adds a url pointing to a feed containing all the information rather than just the information in the subsection. The third extension indicates approximately how frequently a feed is updated. 2) There is also an extension to the Entry information which allows for versioning of the entry based on a unique id, as well as presenting a minimal revision history having only when an entry was modified and by whom. My personal opinion of the SSE spec is that the revision history could be enhanced to be more generally useful (at least add the potential to add a URI to retrieve an earlier version) and it should definitely support hCard for the modifier information. My understanding is that the vCard, iCal specifications do not include this information and Atom has the concept of updated but does not retain any revision trail. Without this information, the burden of determining when something is updated and should be reimported is shifted to the consumer of the information (which can be a rather difficult process), rather than the producer of the information (who should easily know when something is modified). The SSE spec has been produced under a Creative Commons License, unlike the majority of MS specs, so I don't see any licensing problems with incorporating some of it's concepts as a microformat. I have a rudimentary microformat based on SSE in the preliminary design stages - basically some thoughts I had while reading through things last night, which I'll post for your consideration and thoughts when I've had a few days more to think about it. Cayle Missouri ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Primary among alternates Re: WAS: Visible Data
Hi MIke, I think we may the victim of a major miscommunication, aggravated by the choice of subject. Let me start over, to see if I understand. resolve this one specific use case.) Consider these three URLs: http://www.foo.com/toyota/4runner/1999/ http://www.foo.com/toyota/1999/4runner/ http://www.foo.com/1999/toyota/4runner/ Assuming they point to the same basic content but have different breadcrumbs: Home Toyota 4Runner 1999 Home Toyota 1999 4Runner Home 1999 Toyota 4Runner Given your use case, you are trying to distinguish between various human-clickable links that point to the same resource. You want to mark one as preferred or default while still making it clear that the other links are alternate views of -- or rather, routes to -- the same content. Is that a reasonable formulation of your problem? When put that way, this sounds like very analogous to alternates: http://microformats.org/wiki/alternates-brainstorming While the context is different, I think the semantic load is very similar. The difficulty I have is that -- at least the way I understood your description, I have difficulty imagining a page where I see all three at the same time. Given that, it is hard for me to understand *where* the information would be encoded, as your proposed footer: This page is a duplicate of a href=http://www.foo.com/toyota/4runner/1999/; rel=primarywww.foo.com/toyota/4runner/1999//a. feels (at least to me) somewhat contrived. It is precisely that difficulty in conceptualizing concrete use cases that makes me feel like this isn't a viable candidate for the microformat process. However, I'm willing to be proved wrong. If you could perhaps give me a link to a single real-world web page that -- in itself -- needs this solution, then I might feel we could actually help you. Otherwise, this sounds like more a matter of using appropriate HTML head tags to link the page against some authoritative metadata, e.g. where multiple pages link to an authoritative GUID with different rel attributes. But if that's what you want to do, then this group doesn't have a core competency in that area, so we may not be the appropriate place to discuss that. Does that make sense? Best, -- Ernie P. On Oct 27, 2006, at 12:46 AM, Mike Schinkel wrote: Let me give another example for this use-case (although I'm learning there may be existing things in HTML to resolve this one specific use case.) Consider these three URLs: http://www.foo.com/toyota/4runner/1999/ http://www.foo.com/toyota/1999/4runner/ http://www.foo.com/1999/toyota/4runner/ Assuming they point to the same basic content but have different breadcrumbs: Home Toyota 4Runner 1999 Home Toyota 1999 4Runner Home 1999 Toyota 4Runner However, there really are the same page and I'd like to be able to say that one of them is the primary or authoritative one (the website owner would decide which one) and in the two that are not primary or authoritative they would point to the one that is. It's possible that you could have the following visible on the page: This page is a duplicate of a href=http://www.foo.com/toyota/4runner/1999/; rel=primarywww.foo.com/toyota/4runner/1999//a. As I said, this is but one example of data that helps describe a page that I can envision I will need and that I believe could benefit the web in general if it exists. I wish I had fleshed out my other examples at this point but I haven't yet, and I certainly don't want to get the shot down because I present them prematurely prepared. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
