From ryan at technorati.com Wed Feb 7 11:01:02 2007 From: ryan at technorati.com (Ryan King) Date: Wed Feb 7 11:01:09 2007 Subject: [uf-new] new 5 Message-ID: <84DE52DF-8EEE-4C4E-8283-70AB9AB84319@technorati.com> test 5 -- Ryan King ryan@technorati.com From jammie.knight at gmail.com Thu Feb 8 13:46:55 2007 From: jammie.knight at gmail.com (Jamie knight) Date: Thu Feb 8 13:47:00 2007 Subject: [uf-new] hCard to Gmail Converter Message-ID: hCard to Gmail Converter hiya, This is my first message to this list so I hope I don't make any mistakes! If I do please be gentle! A few months ago, I was clicking around with operator, trying to find a way to get a hCard into gmail, as gmail is the main e-mail service I use. After a lot of looking around and a bit of searching I found that there was a process which I could use to bring hCard formatted data into my gmail account. This process was quite simple; I have documented it more fully on my blog post entitled hCard to Gmail (http://jkg3.com/Journal/74/hcard-to-gmail) . In short, I used one service to convert the hCard to a vCard, then another service to convert this vCard to the CSV file the gmail contact importer required. >From here, I sought a way to automate this process. I downloaded copies of both scripts (they are both open source) and proceeded to hack them together. This was my first time with XLST, and my first time producing a CSV file within PHP, so after a lot of learning, I managed to "functionize" the CSV producing part of the code, and place it into the hCard to vCard code instead of it producing a file. I tried to upload this to my server, then I discovered that there was a different XLST service on my host to my local testing sever, after a few hours of fiddling around I decided that I did not know enough about XLST to be able to fix this problem, and instead required something that I could understand easier. So, my next move was to find a "simpler" way to extract my hCard data into a php array. Luckily for me, there was an exact tool for this staring me in the face. hKit hKit for those who are unaware, is a very useful bit of code by Drew McLellan which take a URL as input, and produces a PHP array of hCard objects as an output. find out more about hKit at http://allinthehead.com/hkit/ After downloading and playing with this script, I rewrote my converter, and produced a service which works. The process is still hCard ? vCard ? CSV I relise that this is not the best way to proceed so I am now learning more about producing gmail formatted CSV files. More information on the service (and a bookmarklet) is available at www.jkg3.com/stuff and i would welcome any input form the community regarding further development of this service. Thanks Jamie Knight From jammie.knight at gmail.com Thu Feb 8 13:51:39 2007 From: jammie.knight at gmail.com (Jamie knight) Date: Thu Feb 8 13:51:42 2007 Subject: [uf-new] Opps wrong list! Message-ID: sorry, i manged to send that last message to the wrong list! Jamie From pbohman at gmu.edu Fri Feb 9 12:23:54 2007 From: pbohman at gmu.edu (Paul R. Bohman) Date: Fri Feb 9 12:23:58 2007 Subject: [uf-new] Navigation Menu and "Standard Web Page" microformats Message-ID: <605ba9380702091223mbddf9c4uc04a1ab02368e5af@mail.gmail.com> I've been looking around to try to find an existing microformat for navigation menus and other "standard web page" items, but so far I've been unsuccessful. Does such a microformat exist? The navigation microformat could be something as simple as: And the possibility would exist for submenu items, which wouldn't need to have class="nav", but they could. Benefits: Primarily to allow screen readers, browsers, and other user agents to recognize where the main menu is for the web page. This would allow users to skip past menu items without requiring web developers to include a "skip navigation" link. Along those same lines... Is there a microformat (or perhaps more accurately a "metaformat") to describe the basic structure of common web pages? For example, the vast majority of web pages on the web could be described in these terms: header navigation content footer Those would probably be the core items, but other optional areas that could be defined: * logo (or "site identity" or something like that) * sidebar * ad (advertisers would probably object to this, as it would allow easy scripting to remove ads, but it still could be a useful designation for users at least) * help * ... and perhaps others Of course, not all web pages would fit this format, but that's fine. That's why it's a microformat, right? Anyway, what, if anything, has been done along these lines? -- Paul R. Bohman Faculty, College of Education & Human Development Lead Architect of Web Services, Office of Technology Support Technology Coordinator, Kellar Institute for Human disAbilities George Mason University From hober0 at gmail.com Fri Feb 9 13:46:26 2007 From: hober0 at gmail.com (Edward O'Connor) Date: Fri Feb 9 13:55:18 2007 Subject: [uf-new] Navigation Menu and "Standard Web Page" microformats References: <605ba9380702091223mbddf9c4uc04a1ab02368e5af@mail.gmail.com> Message-ID: <86abznatsd.fsf@rakim.cfhp.org> Paul R. Bohman wrote: > I've been looking around to try to find an existing microformat for > navigation menus and other "standard web page" items, but so far I've > been unsuccessful. Does such a microformat exist? [...] > Is there a microformat (or perhaps more accurately a "metaformat") to > describe the basic structure of common web pages? To the extent that any microformat covers "basic structure of common pages," it would be hAtom, which is useful not just for blogs and other such sites, but for any episodic content where each entry has a title, date, and body. For instance, I marked up http://federali.st/ in hAtom. Now, that being said, I think a more generic attempt to make a microformat for "basic structure of common pages" might run awry of the process, because there usually is a standard element or compound of standard elements that do the trick. In those cases where there aren't current elements or element compounds, I don't think a microformat is necessary where you could simply base your choice of class names, structure, etc., on the new elements introduced by HTML5: > header http://www.whatwg.org/specs/web-apps/current-work/#the-header > navigation http://www.whatwg.org/specs/web-apps/current-work/#the-nav http://www.whatwg.org/specs/web-apps/current-work/#menus > content http://www.whatwg.org/specs/web-apps/current-work/#the-section > footer http://www.whatwg.org/specs/web-apps/current-work/#the-footer > * sidebar http://www.whatwg.org/specs/web-apps/current-work/#the-section > * ad (advertisers would probably object to this, as it would allow > easy scripting to remove ads, but it still could be a useful > designation for users at least) http://www.whatwg.org/specs/web-apps/current-work/#the-section > * help http://www.whatwg.org/specs/web-apps/current-work/#link-type6 I've been doing this a lot lately -- I write up the idiomatic HTML5 for something, then convert new elements into some kind of backwards-compatible analogue, e.g. menu -> ol.menu, figure -> div.figure, etc. Ted -- Edward O'Connor hober0@gmail.com Ense petit placidam sub libertate quietem. From pbohman at gmu.edu Fri Feb 9 14:14:52 2007 From: pbohman at gmu.edu (Paul R. Bohman) Date: Fri Feb 9 14:14:57 2007 Subject: [uf-new] Navigation Menu and "Standard Web Page" microformats In-Reply-To: <86abznatsd.fsf@rakim.cfhp.org> References: <605ba9380702091223mbddf9c4uc04a1ab02368e5af@mail.gmail.com> <86abznatsd.fsf@rakim.cfhp.org> Message-ID: <605ba9380702091414k28700a20i79544e960e97265@mail.gmail.com> On 2/9/07, Edward O'Connor wrote: > I think a more generic attempt to make a > microformat for "basic structure of common pages" might run awry of the > process, because there usually is a standard element or compound of > standard elements that do the trick. Sort of. There are certainly unordered or ordered lists for navigation elements, but there might also be lists that aren't navigation elements. There are microformats for parts of pages with certain types of content, which is great, but it doesn't provide an "outline" of the whole page, which is what I'm after. Sighted people look at the whole web page and subconsciously organize it into sections. They can see the main logo and other components that make up the site's identity. They can see the main navigation, and they can see the main content. It probably takes less than a second for most people to do this visually, and they direct their vision to the part of the page that they're most interested in at that moment. Blind users don't have that luxury. But if their screen readers could give them a quick list of page components -- header, navigation, main content, footer -- they could achieve almost the same level of "quick overview" that sighted users take for granted. > In those cases where there aren't current elements or element compounds, > I don't think a microformat is necessary where you could simply base > your choice of class names, structure, etc., on the new elements > introduced by HTML5: HTML 5 will be great when there is such a thing, but in the spirit of microformats that work *now* rather than in some distant point in the future, wouldn't it be nice to have this sort of functionality available today? It would be a microformat with an expiration date: when HTML 5 is the common standard on the web, the microformat would fade away into obsolescence. But in the meantime, it will have served its purpose. It certainly wouldn't break anything, and it provide a bridge between the old and the new. Realistically, it will be many years before developers can assume that everyone is using HTML 5, right? Maybe 5 years. Maybe a decade. Nobody knows, but it won't be a quick transition. -- Paul R. Bohman Faculty, College of Education & Human Development Lead Architect of Web Services, Office of Technology Support Technology Coordinator, Kellar Institute for Human disAbilities George Mason University From anseljh at gmail.com Tue Feb 13 09:47:53 2007 From: anseljh at gmail.com (Ansel Halliburton) Date: Tue Feb 13 09:48:09 2007 Subject: [uf-new] Stock microformat - status? References: Message-ID: Hello! I came across an earlier discussion of a future stock microformat, and am interested in helping out. I would like to use such a microformat on a forthcoming project here at Stanford, and some other folks here might be interested too. Has any more work gone into this since the two links below were posted? I contacted the two people listed on the wiki page directly, but haven't had any response, so I fear things may be in limbo. http://microformats.org/wiki/stock-symbol-examples http://microformats.org/discuss/mail/microformats-discuss/2006-May/ 004180.html Ansel Halliburton Analyst, IP Litigation Clearinghouse Stanford Law School Email: anseljh@stanford.edu Phone: 650-736-8567 From scott at makedatamakesense.com Tue Feb 13 17:55:57 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Tue Feb 13 17:56:11 2007 Subject: [uf-new] Stock microformat - status? In-Reply-To: References: Message-ID: <67ABA8A3-0113-48E6-8A04-B406C2265860@makedatamakesense.com> On Feb 13, 2007, at 11:47 AM, Ansel Halliburton wrote: > Hello! Hi! > I came across an earlier discussion of a future stock microformat, > and am interested in helping out. I would like to use such a > microformat on a forthcoming project here at Stanford, and some > other folks here might be interested too. Has any more work gone > into this since the two links below were posted? I contacted the > two people listed on the wiki page directly, but haven't had any > response, so I fear things may be in limbo. > > http://microformats.org/wiki/stock-symbol-examples > http://microformats.org/discuss/mail/microformats-discuss/2006-May/ > 004180.html I think you're probably right that things are in limbo. Part of the problem might be that the problem statement is kind of vague. What exactly would you like to do with stock symbol data? Are existing microformats (e.g. rel-tag [1]) sufficient for your use cases? If so, we have no problem to solve. If not, let's identify what we're missing. [1] http://microformats.org/wiki/rel-tag -- Scott Reynen MakeDataMakeSense.com From fberriman at gmail.com Wed Feb 14 01:32:54 2007 From: fberriman at gmail.com (Frances Berriman) Date: Wed Feb 14 01:33:12 2007 Subject: [uf-new] Re: [uf-discuss] Microformats and Football In-Reply-To: References: <200702140013.l1E0D7h7009659@microformats.org> Message-ID: On 14/02/07, Danilo Medeiros wrote: > I?m still finding my way around, so any ideas on next steps would be > appreciated. I think we should move this discussion over to the -new mailing list so we can explore all of this a bit more (therefore closing this thread on this list). If you're not already subscribed, you can find out more here: http://microformats.org/discuss/#new Thanks, -- Frances Berriman http://fberriman.com From newsletter at 2000grad.com Thu Feb 15 09:39:46 2007 From: newsletter at 2000grad.com (Henrich C. Poehls) Date: Thu Feb 15 09:38:47 2007 Subject: [uf-new] Sign Microformatted content & Build Microformat for Digital Signatures Message-ID: <45D49AE2.6060503@2000grad.com> Hello, deep buried in the discussion around a way to find/trace an authoritative hcard on the uf-discuss mailing list [1] I proposed the idea of having the possibility to digitally sign microformatted content [2][3]. Nick Drago then helped to put the discussion of my 1st format proposal into the uf-Wiki [4]. I am going to shortly share some benefits of a Microformat for digital signatures I see here. I am really looking forward discussing it either here or on the discussion page on the WiKi. - Why a new Microformat? I think signing a "Microformat" (aka Microformatted Content) shall be possible within "Microformats" (so itself a microformat). Such as XML can be signed and the Signature stored in XML as well. - Why signing Microformatted content? Microformats facilitate reuse of semantically annotated content. It allows services and applications to cut&paste, convert, re-publish, link-to, cite Microformatted content. In any of these cases it might be interesting to see who the original author was. Additionally viewers want to verify authorship. Digital Signatures offer just this, Origin-Authentication. - Why use digital signatures and not some "Trace-Back-Mechanism" [1] Trace-back allows to find a "bigger", more complete version of Microformatted content. Trace-back only verifies that the pointer used for trace-back is now "self referencing". Trace-back will then verify the content's source based on a URI/URL. IMHO trace-back is a weaker "form of authenticity" than that achieved by a digital signatures. Also digital signatures are more versatile: -- Digital signatures add authenticity without the need to trace links back to some URL, so reduces the overhead if the content at view is "authoritative enough". -- Digital signatures allow to add authority to content that is placed on foreign URLs (e.g. Signing your whole Comment you left on a foreign Blog). I can come up with more good reasons, but I stop now, leaving room for your, much welcomed, thoughts :-) Henrich. [1] http://microformats.org/discuss/mail/microformats-discuss/2007-January/thread.html#8265 [2] http://microformats.org/discuss/mail/microformats-discuss/2007-February/008628.html [3] http://microformats.org/discuss/mail/microformats-discuss/2007-February/008661.html [4] http://microformats.org/wiki/digital-signatures From michael at donorschoose.org Fri Feb 16 08:45:56 2007 From: michael at donorschoose.org (Michael Everett-Lane) Date: Fri Feb 16 08:46:04 2007 Subject: [uf-new] hGive: Microformats and Microphilanthropy Message-ID: <41ED0E73B2268F4D9E4081FAB5ED05FD013B3F56@midas.utopiasystems.net> Hi, my name is Mike Everett-Lane and I work for DonorsChoose, a nonprofit philanthropic marketplace that benefits the public schools in the US. I recently joined this group (and have been learning about microformats) because I think microformats could greatly benefit microphilanthropy sites. This is building off of the "hGrant" idea which Eugene proposed some time ago. I mentioned the idea of expanding it to a more general "hGive" on the regular microformats list, but now that there's "-new" I thought I'd repropose it. I've written up some thoughts on my blog and also reproduce them below. I would really appreciate your help in figuring out how to proceed with standards and implementation. http://triptronix.net/ishbadiddle/archives/2007/02/15/15.20.40/ DonorsChoose (where I work) both gives grants (to teachers) and receives them (from the public). We have thousands of proposals that public school teachers have posted on our site, and individuals can give directly to those projects. Similar microphilanthropy sites include Kiva, Modest Needs, Global Giving, and GiveMeaning. All are essentially philanthropic marketplaces that bring together givers and recipients. And thus all could benefit from opening our data in a way that would make them accessible beyond our own websites. Picture the following mashup possibilities: * Phil has just moved to Brooklyn, and wants to get involved with his new community. He enters his address into a Philanthropic Mashup site (made with Yahoo Pipes?) which aggregates local funding needs. He can filter those needs by cost, by type of program, and by demographics of the recipients. He decides to fund a classroom project at DonorsChoose and make a Back-to-Work Grant to a local family through Modest Needs. * Jennifer has an old computer monitor she wants to donate to a local school. She calls a few schools but no one needs a monitor. She is able to search for local organizations that are seeking computer monitors, and finds a nearby women's shelter that is in need, so gives it there instead. * Ashley is teaching her fifth grade class about water quality. They go to the Philanthropic Mashup site and find water quality projects all over the world. They decide to raise funds for one of those projects in Burkina Faso, sponsored by Global Giving. Later they follow up by looking for other projects in the same village, and find a Kiva loan for a new small business there. * John is a programmer in Topeka who wants to help out literacy organizations, a special passion of his. He posts an offer of services his blog, with details of the hours he wants to commit and the types of services he offers. A literacy program in Saskatchewan has need of his skills, and is able to find John through Google because he has marked up his offer with the proper microformats. * The Bailey Foundation wants to improve its outreach and reach more nonprofits with its Animal population control grants program. It posts data on its grant program (available amount, application deadline, etc.) on its site. An animal shelter that has never heard of the Bailey Foundation is able to find them and get funding for its Spay Day program. These are the kinds of things that microformats could make possible. We at DonorsChoose have been talking about applying microformats to our proposals (each has its own page) to make them semantic, but none of the existing microformats seem to fit what we're doing. I also recently talked with Tom Williams at GiveMeaning who is also interested. I'm posting this here as what I hope will be part of a larger conversation about microformatting microphilanthropy. Ideally we would have a microformat "hGive". This would allow organizations that are seeking contributions / in-kind donations / volunteers to use it, as well as organizations/people who are looking to volunteer, donate, etc. (I'm thinking of online volunteer clearinghouses such as New York Cares which exist in most US cities I believe.) Here are some of the potential parameters: * direction: seeking or offering? * medium: cash or items or volunteers? * cost: (perhaps other pricing data like minimum donation, payment types accepted -- not sure what the standards are for price data among other microformats). Also, loan or grant? (For example, Kiva and ModestNeeds give loans, DonorsChoose and Global Giving give grants). There also could be total cost vs. cost remaining, interest rate data for loans, etc. * date: for expiration dates, volunteer event dates, application deadline dates, etc. Cf. hCalendar standards. * demographic: some kind of data about the recipients -- avg income?, number of people the project will serve, etc. * geotag: where is it? * guarantor: is there an organization that guarantees this request? This would separate an individual asking for help (I need a loan) from an organization asking for help on behalf of an individual (Modest Needs will provide a loan to the individual whose identity and need they have confirmed). * keyword tags: ("education," "Shakespeare," "clean water" etc.) The Foundation Center's Foundation Directory has a list of Foundation Fields of Interest which could be the basis for a standard Program Type list. * description: The executive summary. I'm sure there are other possibilities / desiderata, especially around volunteer projects (one time vs ongoing, group vs individual, etc) but this is what comes to mind. If there were an implementable standard, I'm pretty sure I could get DonorsChoose to start using it in the nearish future. And then, of course, Utopia Ensues. Thanks for your help with this. -- Mike -------------------- Mike Everett-Lane Executive Director, DonorsChoose New York 347 West 36th Street, Suite 503, New York, NY 10018 212-239-3615 ext 204 michael@donorschoose.org www.donorschoose.org From bewest at gmail.com Sat Feb 17 16:09:33 2007 From: bewest at gmail.com (Benjamin West) Date: Sat Feb 17 16:09:37 2007 Subject: [uf-new] hGive: Microformats and Microphilanthropy In-Reply-To: <41ED0E73B2268F4D9E4081FAB5ED05FD013B3F56@midas.utopiasystems.net> References: <41ED0E73B2268F4D9E4081FAB5ED05FD013B3F56@midas.utopiasystems.net> Message-ID: <8ad71be30702171609udb4f542o931ff97eef92f524@mail.gmail.com> Greetings Mike, First, this is the right place for your proposal. Nice. > > These are the kinds of things that microformats could make possible. We > at DonorsChoose have been talking about applying microformats to our > proposals (each has its own page) to make them semantic, but none of the > existing microformats seem to fit what we're doing. I also recently > talked with Tom Williams at GiveMeaning who is also interested. I'm > posting this here as what I hope will be part of a larger conversation > about microformatting microphilanthropy. > > Ideally we would have a microformat "hGive". This would allow > organizations that are seeking contributions / in-kind donations / > volunteers to use it, as well as organizations/people who are looking to > volunteer, donate, etc. (I'm thinking of online volunteer clearinghouses > such as New York Cares which exist in most US cities I believe.) > Sometimes people approach microformat technology with a great use case, notice that none of the formats have their particular use case listed, and proceed to suggest a new format. However, formats are not designed with a one-to-one relationship to use-case in mind. Existing formats can be used in new techniques to satisfy new use cases never intended by the authors of the original format. Documenting a technique using existing formats is a successful goal in the microformats community, and we find that most people can accomplish very creative things by re-using formats. In addition, it's usually much faster to get things done when we re-use previous work. > Here are some of the potential parameters: > [snip] > I'm sure there are other possibilities / desiderata, especially around > volunteer projects (one time vs ongoing, group vs individual, etc) but > this is what comes to mind. > Perhaps. Be careful of defining properties too early. Both properties and structure for new formats exhibit emergent behaviour following analysis of pre-existing examples. > If there were an implementable standard, I'm pretty sure I could get > DonorsChoose to start using it in the nearish future. And then, of > course, Utopia Ensues. > I'm not convinced a new format is necessary, without first trying to re-use the work already available to us. The process outlined at is designed to make it difficult to create a new format, and is designed to encourage new and innovative techniques for re-using available formats. Here are some suggestions: Create a wiki page outlining your use case, but don't call it hgive. Try calling it microphilanthropy, or just philanthropy. Start discussing the various datatypes necessary. Break things apart from one large microformat into smaller chunks of data. For example, a lot of your description involves the concept of a person (a people data type). Hcard is perfect there. Treat the current microformats and related technologies (including semantic html) as building blocks for a technique that satisfies the use cases you outlined. Another data type is listing of skills: the resume microformat might be perfect for that. You mentioned specifying directionality as a requirement, but I think it'd be a lot simpler if you designed a technique/protocol that always allows consumers to search for offerings. For example, instead of: > * Jennifer has an old computer monitor she wants to donate to a > local school. She calls a few schools but no one needs a monitor. She is > able to search for local organizations that are seeking computer > monitors, and finds a nearby women's shelter that is in need, so gives > it there instead. > Try: Jennifer has an old computer monitor she wants to donate to a local school. She finds a website that allows people to list things they own as donations. When she enters her items on this website, it marks it up using hlisting , and embeds it in an hatom entry. It's also rel-tag'ged with microphilanthropy, and the women's shelter is able to find it through the syndicated feed they signed up for, or the next time they log into the site. However, I just noticied that hlisting includes the concept of directionality as well, so the women's shelter could also list their need using hlisting, tag it as microphilanthropy, and the website could ping both parties when it finds that match. Anyway, that's the advice. Try using existing microformats as building blocks: rel-tag to glue things together, hlisting for products, hresume for skills, hreview for opinions, hcalendar for times and events, hcard for people, hatom for syndication. At the end of the day, I bet this will get you 80% there very quickly, and the rest can be filled in by describing some small additional semantic html techniques. Thanks, Ben West From kilian at kilianvalkhof.com Sun Feb 18 13:03:18 2007 From: kilian at kilianvalkhof.com (Kilian Valkhof) Date: Sun Feb 18 13:03:01 2007 Subject: [uf-new] starting work and discussion on XRN Message-ID: <45D8BF16.1090807@kilianvalkhof.com> Hello all, This reply is long overdue, but here it is: At the discuss-newsgroup, most people were in favour of joining XPN(the idea) and XFN into an XRN, an Xhtml Relationships Network. This to broaden the use. I think this would be a very smart idea. I would like to start working on such a thing (discussion pages, example pages, the likes) But I don't really have all the knowledge on the how, and there is only so much the site+wiki can teach you. So I would like to ask if someone would like to coach/mentor me. I know I can always ask things in the chat, but in my experience this is easier. So, for the technicalities: The idea is to extend XFN to XRN by adding business/professional relationships to it. LinkedIn already has a list of them, and I think it would be wise to at least incorporate those. Next to that, I think it would be smart to give company's a way to link to clients and suppliers, and to employee's (for example, the many web development company's that link to the personal blogs of their employee's) The next cause of action would be to expand the xpn examples page I already made ( http://microformats.org/wiki/xpn-examples ) or should we start a brainstorm/discussion page and work from there? Cheers, Kilian From bewest at gmail.com Sun Feb 18 13:42:16 2007 From: bewest at gmail.com (Benjamin West) Date: Sun Feb 18 13:42:19 2007 Subject: [uf-new] starting work and discussion on XRN In-Reply-To: <45D8BF16.1090807@kilianvalkhof.com> References: <45D8BF16.1090807@kilianvalkhof.com> Message-ID: <8ad71be30702181342q7d8f2d76uad1c9a9eb21e4c9@mail.gmail.com> Hi Kilian, > So I would like to ask if someone would like to coach/mentor me. I know > I can always ask things in the chat, but in my experience this is easier. > You are in the right place. :-) This list is dedicated to providing advice and encouragement for new projects. > So, for the technicalities: The idea is to extend XFN to XRN by adding > business/professional relationships to it. I'm a little confused. If we are simply increasing the number of relationships available, why do we need a new format with a new name? Is anything wrong with adding these values to XFN? Thanks, -Ben From alexander.graf at deri.org Sun Feb 18 13:44:23 2007 From: alexander.graf at deri.org (Alexander Graf) Date: Sun Feb 18 13:47:13 2007 Subject: [uf-new] starting work and discussion on XRN In-Reply-To: <8ad71be30702181342q7d8f2d76uad1c9a9eb21e4c9@mail.gmail.com> References: <45D8BF16.1090807@kilianvalkhof.com> <8ad71be30702181342q7d8f2d76uad1c9a9eb21e4c9@mail.gmail.com> Message-ID: <65BCDC56-E640-4B5F-9CE7-7923997844C6@deri.org> Hi. I think it's just about a name change since business relationship and "friends" doesn't really fit. So if I got that right, we should add more relationships to XFN and at the same time change the name to reflect the new types of relationships available. While I personally think adding relationships is a good idea, I'm not convinced a name change to XRN is required. - Alex On 18.02.2007, at 22:42, Benjamin West wrote: > Hi Kilian, > >> So I would like to ask if someone would like to coach/mentor me. I >> know >> I can always ask things in the chat, but in my experience this is >> easier. >> > You are in the right place. :-) This list is dedicated to providing > advice and encouragement for new projects. > >> So, for the technicalities: The idea is to extend XFN to XRN by >> adding >> business/professional relationships to it. > > I'm a little confused. If we are simply increasing the number of > relationships available, why do we need a new format with a new name? > Is anything wrong with adding these values to XFN? > > Thanks, > -Ben > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From alexander.graf at deri.org Sun Feb 18 17:06:53 2007 From: alexander.graf at deri.org (Alexander Graf) Date: Sun Feb 18 17:09:44 2007 Subject: [uf-new] starting work and discussion on XRN In-Reply-To: <8ad71be30702181342q7d8f2d76uad1c9a9eb21e4c9@mail.gmail.com> References: <45D8BF16.1090807@kilianvalkhof.com> <8ad71be30702181342q7d8f2d76uad1c9a9eb21e4c9@mail.gmail.com> Message-ID: <92C8DEA3-AD88-4046-9809-FFEB133F402B@deri.org> Hi. I think it's just about a name change since business relationship and "friends" doesn't really fit. So if I got that right, we should add more relationships to XFN and at the same time change the name to reflect the new types of relationships available. While I personally think adding relationships is a good idea, I'm not convinced a name change to XRN is required. - Alex On 18.02.2007, at 22:42, Benjamin West wrote: > Hi Kilian, > >> So I would like to ask if someone would like to coach/mentor me. I >> know >> I can always ask things in the chat, but in my experience this is >> easier. >> > You are in the right place. :-) This list is dedicated to providing > advice and encouragement for new projects. > >> So, for the technicalities: The idea is to extend XFN to XRN by >> adding >> business/professional relationships to it. > > I'm a little confused. If we are simply increasing the number of > relationships available, why do we need a new format with a new name? > Is anything wrong with adding these values to XFN? > > Thanks, > -Ben > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From newsletter at 2000grad.com Sun Feb 18 23:00:39 2007 From: newsletter at 2000grad.com (Henrich C. Poehls) Date: Sun Feb 18 22:59:42 2007 Subject: [uf-new] Sign Microformatted content & Build Microformat for Digital Signatures Message-ID: <45D94B17.2040602@2000grad.com> Hello, deep buried in the discussion around a way to find/trace an authoritative hcard on the uf-discuss mailing list [1] I proposed the idea of having the possibility to digitally sign microformatted content [2][3]. Nick Drago then helped to put the discussion of my 1st format proposal into the uf-Wiki [4]. I am going to shortly share some benefits of a Microformat for digital signatures I see here. I am really looking forward discussing it either here or on the discussion page on the WiKi. - Why a new Microformat? I think signing a "Microformat" (aka Microformatted Content) shall be possible within "Microformats" (so itself a microformat). Such as XML can be signed and the Signature stored in XML as well. - Why signing Microformatted content? Microformats facilitate reuse of semantically annotated content. It allows services and applications to cut&paste, convert, re-publish, link-to, cite Microformatted content. In any of these cases it might be interesting to see who the original author was. Additionally viewers want to verify authorship. Digital Signatures offer just this, Origin-Authentication. - Why use digital signatures and not some "Trace-Back-Mechanism" [1] Trace-back allows to find a "bigger", more complete version of Microformatted content. Trace-back only verifies that the pointer used for trace-back is now "self referencing". Trace-back will then verify the content's source based on a URI/URL. IMHO trace-back is a weaker "form of authenticity" than that achieved by a digital signatures. Also digital signatures are more versatile: -- Digital signatures add authenticity without the need to trace links back to some URL, so reduces the overhead if the content at view is "authoritative enough". -- Digital signatures allow to add authority to content that is placed on foreign URLs (e.g. Signing your whole Comment you left on a foreign Blog). I can come up with more good reasons, but I stop now, leaving room for your, much welcomed, thoughts :-) Henrich. [1] http://microformats.org/discuss/mail/microformats-discuss/2007-January/thread.html#8265 [2] http://microformats.org/discuss/mail/microformats-discuss/2007-February/008628.html [3] http://microformats.org/discuss/mail/microformats-discuss/2007-February/008661.html [4] http://microformats.org/wiki/digital-signatures From michael at donorschoose.org Mon Feb 19 08:13:10 2007 From: michael at donorschoose.org (Michael Everett-Lane) Date: Mon Feb 19 08:17:56 2007 Subject: [uf-new] hGive: Microformats and Microphilanthropy References: <200702190109.l1J19nix007726@microformats.org> Message-ID: <41ED0E73B2268F4D9E4081FAB5ED05FD299479@midas.utopiasystems.net> Ben -- thanks so much, this is just the advice I needed, being so new to the process and all. I'm glad to see that we can use a combination of existing formats and will start in on "the process." ------------------- Michael Everett-Lane Executive Director, DonorsChoose New York 212-239-3615 ext 204 michael@donorschoose.org | www.donorschoose.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 3819 bytes Desc: not available Url : http://microformats.org/discuss/mail/microformats-new/attachments/20070219/340241b5/attachment.bin From fberriman at gmail.com Mon Feb 19 09:06:51 2007 From: fberriman at gmail.com (Frances Berriman) Date: Mon Feb 19 09:06:54 2007 Subject: [uf-new] starting work and discussion on XRN In-Reply-To: <65BCDC56-E640-4B5F-9CE7-7923997844C6@deri.org> References: <45D8BF16.1090807@kilianvalkhof.com> <8ad71be30702181342q7d8f2d76uad1c9a9eb21e4c9@mail.gmail.com> <65BCDC56-E640-4B5F-9CE7-7923997844C6@deri.org> Message-ID: On 18/02/07, Alexander Graf wrote: > Hi. > > I think it's just about a name change since business relationship > and "friends" doesn't really fit. So if I got that right, we should add > more relationships to XFN and at the same time change the name > to reflect the new types of relationships available. > > While I personally think adding relationships is a good idea, I'm > not convinced a name change to XRN is required. > I think I'm inclined to agree. I think the best bet for this is to research and establish what's going on "in the wild" and see what relationships we genuinely feel are being suggested and used out and about, but aren't currently part of XFN. Then we can look at whether they're just being used because the current XFN relationships aren't being exploited fully or used correctly, or if indeed there is a gap in the XFN range. Renaming XFN should be the very last port of call. -- Frances Berriman http://fberriman.com From fberriman at gmail.com Mon Feb 19 09:34:02 2007 From: fberriman at gmail.com (Frances Berriman) Date: Mon Feb 19 09:34:09 2007 Subject: [uf-new] Re: [uf-discuss] Book microformat examples - published books or "web-first" books? In-Reply-To: References: Message-ID: On 10/02/07, Jeremy Boggs wrote: > I added two examples to the book-examples page[1], then I wondered: > Is the books microformat focused mainly on books that have been > published in print first, then published on the web? Or is the books > microformat open to including books published on the web first, then > published in print? It ought to be either. Since you're in the stage of the process specifically dealing with collecting examples, you should be collecting both kinds that ultimately end up being published and consumed on the web. I don't think the original source of the book matters as long as it ultimately has been published, digitally and in full, on the web. So, I see no problems... unless I'm missing a trick. Also - can we move this discussion over to the -new mailing list [1][2] (rending this thread on -discuss closed). I've already included this reply onto it. Thanks! For -new - Original thread began here: http://microformats.org/discuss/mail/microformats-discuss/2007-February/008671.html [1]http://microformats.org/wiki/mailing-lists#microformats-new [2]http://microformats.org/discuss/ -- Frances Berriman http://fberriman.com From kilian at kilianvalkhof.com Tue Feb 20 11:15:50 2007 From: kilian at kilianvalkhof.com (Kilian Valkhof) Date: Tue Feb 20 11:15:30 2007 Subject: [uf-new] Re: microformats-new Digest, Vol 1, Issue 2 In-Reply-To: <200702190109.l1J19mub007708@microformats.org> References: <200702190109.l1J19mub007708@microformats.org> Message-ID: <45DB48E6.1030609@kilianvalkhof.com> Hello, thanks for your answers. The problem most people in the discuss list had, was that you would define relationships to customers and business related entities using a "Friends network". This would most likely hold people back in adoption of using a standard to define those relationships. The link to the previous discussion in discuss: http://microformats.org/discuss/mail/microformats-discuss/2007-January/008327.html and: http://microformats.org/discuss/mail/microformats-discuss/2007-January/008373.html Cheers, Kilian > Hi. > > I think it's just about a name change since business relationship > and "friends" doesn't really fit. So if I got that right, we should add > more relationships to XFN and at the same time change the name > to reflect the new types of relationships available. > > While I personally think adding relationships is a good idea, I'm > not convinced a name change to XRN is required. > > > - Alex From kilian at kilianvalkhof.com Wed Feb 21 04:08:30 2007 From: kilian at kilianvalkhof.com (Kilian Valkhof) Date: Wed Feb 21 04:08:12 2007 Subject: [uf-new] re: starting work and discussion on XRN In-Reply-To: <200702190109.l1J19mub007708@microformats.org> References: <200702190109.l1J19mub007708@microformats.org> Message-ID: <45DC363E.6000608@kilianvalkhof.com> (resent because I messed up with the subject) Hello, thanks for your answers. The problem most people in the discuss list had, was that you would define relationships to customers and business related entities using a "Friends network". This would most likely hold people back in adoption of using a standard to define those relationships. The link to the previous discussion in discuss: http://microformats.org/discuss/mail/microformats-discuss/2007-January/008327.html and: http://microformats.org/discuss/mail/microformats-discuss/2007-January/008373.html Cheers, Kilian > Hi. > > I think it's just about a name change since business relationship > and "friends" doesn't really fit. So if I got that right, we should add > more relationships to XFN and at the same time change the name > to reflect the new types of relationships available. > > While I personally think adding relationships is a good idea, I'm > not convinced a name change to XRN is required. > > > - Alex From go at omnia-computing.de Wed Feb 21 05:32:55 2007 From: go at omnia-computing.de (Gordon Oheim) Date: Wed Feb 21 05:31:46 2007 Subject: [uf-new] RFC on privacy policy microformat loosely based on p3p Message-ID: <36B22F23F0E27E4C9E38198721D8BED5045D54@omnia-com.omnia-computing.de> Hi all, My name is Gordon. My company develops websites and webapplications and infrastructure solutions in Germany. I am writing to get some feedback on a new microformat in planning. The aim of this microformat is to inform visitors of a website about the data collection/privacy policy of a website. The background (and problem) for this microformat is a new law in Germany (the "Telemediengesetz"), which demands website owners to provide a policy about what data is collected about the user during his visit, by whom it is collected, for how long and why and how this data is used. This applies to personal data as well as connection data. The policy has to be presented before any data collection takes place. Since this is virtually impossible and heavily debated atm, I was looking for something to get close to this requirement. P3P policies might be one close solution, but its a hassle to implement and for small and medium sized businesses or even private website owners it is overkill. Forcing visitors to read any policies before they can access the content on site doesn't appear too user-friendly to me either. I need something simple, but effective. So I developed a small matrix to structure our policy information in compact form. This matrix is composed of three main elements "personal-data", "connection-data" and "cookie-tracking". For all those elements we get the attributes "collected" (indicating when), "duration" (indicating how long) and "access" (indicating who can access this data). All attributes can have several values: collected can be "always", "never", "opt-in" or "opt-out" and duration can be "once", "timed", "indefinite" and access can be "company", "isp" and "3rd party". Since this is just a request for comments I wont go into much more detail about what these values mean. I hope they are more or less self-explanatory anyway. I based them on the P3P specs loosely. This compact matrix could be presented to the user anywhere on the site to give him an idea about what to expect. He can then choose to read the entire policy or just surf on. My idea was to style this data into a graphic similar to the creative commons logos that tell about what a license allows and requires. Or maybe a browser plugin could read the format and popup when the data deviates from a user-specified setting (much like IE handles P3P policies). Well, so much for the basic concept. I'm looking forward to some constructive comments, whether this would be useful addition to the microformat family. Thanks. Cheers, Gordon -- Gordon Oheim Omnia Computing http://www.omnia-computing.de From teohuiming.work at gmail.com Fri Feb 23 09:21:11 2007 From: teohuiming.work at gmail.com (Teo Hui Ming) Date: Fri Feb 23 09:21:17 2007 Subject: [uf-new] Link relation for non-existing wiki page Message-ID: <73ec599d0702230921y28a160f7o5ec25b2d6cb6372b@mail.gmail.com> Hi all, There are two common approaches to represent non-existing wiki page links: 1. page name followed by a hyperlinked question mark. 2. hyperlinked page name, styled differently contrast from other links. When using the second approach, links are distinguished based on visual styling, which appears to be difficult to some readers (e.g. color-blindness[1], low-resolution display, screen reading etc). A guideline to represent non-existing wiki page links would be nice to improve accessibility. It seems microformats will be a right place to ask around. Some initial findings are available at [2]. Wish to listen your thoughts. :-) [1] http://bugs.splitbrain.org/?do=details&id=1065 [2] http://www.teohuiming.name/projects/rel-wikinew Thanks, -- Teo Hui Ming From hober0 at gmail.com Fri Feb 23 11:09:38 2007 From: hober0 at gmail.com (Edward O'Connor) Date: Fri Feb 23 11:17:57 2007 Subject: [uf-new] Re: Link relation for non-existing wiki page References: <73ec599d0702230921y28a160f7o5ec25b2d6cb6372b@mail.gmail.com> Message-ID: <86d5403d3h.fsf@rakim.cfhp.org> A link relation applies to the relationship between the linking page and the linked page. The fact that a wiki page hasn't been created yet is just a fact about that page, and AFAICT doesn't have anything to do with the page linking to it. So the use of @rel would be inappropriate -- @class would be a better choice. Ted -- Edward O'Connor hober0@gmail.com Ense petit placidam sub libertate quietem. From fberriman at gmail.com Mon Feb 26 08:36:29 2007 From: fberriman at gmail.com (Frances Berriman) Date: Mon Feb 26 08:37:07 2007 Subject: [uf-new] Re: [uf-discuss] Introduction; music microformat In-Reply-To: References: Message-ID: On 26/02/07, Marian Steinbach wrote: > Hello everybody! Hi Marian! Welcome to the -discuss. > I just joined the list because I am interested in the development of > (a) "music" microformats. Can I take this opportunity, before this thread gets a bit meaty, to redirect this discussion to the microformats-new list, which is specifically for the exploration and discussion of new microformats: http://microformats.org/wiki/mailing-lists#microformats-new -- Frances Berriman http://fberriman.com