Re: [uf-discuss] What to do about SEO abuse of hcard-examples-in-wild?
On Wed, 2011-05-11 at 10:51 -0700, Edward O'Connor wrote: > Hi. > > Lately there have been lots of questionable edits to the > hcard-examples-in-wild page. I don't mean outright spam edits, which > happen there about as often as on the rest of the wiki. The linked pages > do technically have hCards on them. But there are many links from > hcard-examples-in-wild to pages of dubious utility. Some examples: > > * http://www.newtosandiego.com/Ocean-Beach-People's-Organic-Foods-Co-op/ > * http://howdoyouknowifyouhavebedbugs.com/ > * and many more along those lines. > > I suspect some "SEO specialists" have adopted hCard on spammy pages like > these precisely so they can link to them from our (high PageRank) wiki. > > Personally, I think we should more heavily curate, or maybe even remove, > this page. Back when hCard was new, having real-world examples was > helpful to implementors. These days, hCards are on hundreds of millions > of web pages. We can meet the needs of implementors by having a much > smaller list of examples. > > Thoughts? * If even spammers use microformats, is mission accomplished? At that point I imagine that microformatted pages is a fairly common practice. I doubt that the examples in the wild wiki page would have much use. * "Spammy" is a gray area. What makes one site any more spammy than another when it comes to online marketing? What about the nature of the content at given resource? Who gets to say topic X is okay but topic Y is not? * How would the community derive at a short list of sites? Would it be by votes from the community, popularity, special ops "admins" making a decision? * What about the quality of the example resources in the list? Have they been verified to contain valid hCards? -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] re: HTML5 support
On Wed, 2010-07-21 at 16:33 +0200, Philip Jägenstedt wrote: > On Wed, 21 Jul 2010 15:46:08 +0200, Stephen Paul Weber > wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > Somebody claiming to be Philip Jägenstedt wrote: > >> On Tue, 20 Jul 2010 15:47:19 +0200, Scott Reynen > >> wrote: > >> > >> >Distributed vocabulary development requires a general purpose > >> >solution. Microformats don't have that requirement, so > >> >vocabulary-specific solutions are common. > >> > >> Yes, which is why general purpose parsers cannot exist, and why > >> browser support is unlikely. > > > > I'm pretty sure Firefox already supports µfs... > > Are you sure it's not a plugin? If not, I'd be very interested to see it > in action. > It has some support. See also resource://gre/modules/Microformats.js and https://developer.mozilla.org/en/Using_microformats Probably the best way to see it in action is via JetPack: https://jetpack.mozillalabs.com/ -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] 2 billion hCards! gathering material for a "microformats.org turns 5" blog post
On Sat, 2010-07-03 at 19:18 -0700, Tantek Çelik wrote: > According to Yahoo! Search Monkey, there are now over 2 billion hCards > on the web: > > http://search.yahoo.com/search?p=searchmonkey% > 3Acom.yahoo.page.uf.hcard > > This is perhaps due to a few fairly large recent deployments: > * BrightKite.com - all venues and user profiles have hCard (millions) > * Gravatar - all profiles now have hCards (millions) - used on > WordPress.com etc. > > Some additional recent news: > * microformats has 94% marketshare compared to alternatives (e.g. > RDFa) according to Google (announced at the Semantic Technology > conference) > - > http://www.readwriteweb.com/archives/google_semantic_web_push_rich_snippets_usage_grow.php > - http://www.readwriteweb.com/images/richsnippets_june10b.jpg > > I'm collecting these into material for "microformats.org turns 5" blog > post - additional suggestions welcome! > > http://microformats.org/wiki/microformats-turns-5 > > -- > http://tantek.com/ I'm not sure about exact numbers, but a StatusNet instance (e.g., http://identi.ca/ ), has hCards for all users and groups. It includes representative hCards. Updated wiki. -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] how to enrich hCard with business category info
On Tue, 2010-05-25 at 16:37 -0400, Arnaud Sahuguet wrote: > how would you enrich the hCard of a local business with some category > information? I think VCARD:CATEGORIES (or possibly VCARD:ROLE) is what you are looking for. See sections '3.6.1 CATEGORIES Type Definition' and '3.5.2 ROLE Type Definition' at http://www.rfc-editor.org/rfc/rfc2426.txt -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Level of rel=contact
On Tue, 2010-04-06 at 22:48 +, Brian Suda wrote: > On Tue, Apr 6, 2010 at 9:23 PM, Sarven Capadisli wrote: > > I'm thinking that rel="contact" is generally attributed to someone that > > we have at least a "lowest form of friendship" with. [...] > > Additionally, > > if the user doesn't have control over the declaration of such > > relationship, wouldn't it be more meaningful and safer to exclude this > > bit of information in the output? > > --- You lost me on "exclude this", exclude what exactly? My bad. My reference was to the example. > rel=contact > isn't symmetrical, so you might be my contact, but i'm not yours. I > can't control what you declare about me. That's exactly the case I was working with. > > The example I had in mind was 'Subscribers list' at > > http://identi.ca/csarven > > --- if you are subscribing to someone, then it probably at minimum > meets the definition of: someone that we have at least a "lowest form > of friendship" > > Are you suggesting it isn't and we should exclude it? No, I'll clarify. What I was trying to say was that, if I have a profile page where it lists a bunch of people that are subscribed to me, I wouldn't necessarily call them my contact since I don't really know them. Hence, in my example at http://identi.ca/csarven , rel=contact should be removed from Subscribers list. I agree that rev="contact" makes more sense here, but, I'm focused on the incorrect use of rel="contact". rel=contact is/should be reserved for people that meets the basic requirement of that "lowest form of friendship". In loose terms, it would be someone that I acknowledge or okay with. Do you agree with this general definition? I was looking for clarification on the "someone you know" bit. Thanks. -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Level of rel=contact
A little bit of semantics. http://gmpg.org/xfn/11#contact says "contact: Someone you know how to get in touch with. Often symmetric." I'm thinking that rel="contact" is generally attributed to someone that we have at least a "lowest form of friendship" with. It would also be someone that we don't dislike e.g., blackhat SEO expert. Additionally, if the user doesn't have control over the declaration of such relationship, wouldn't it be more meaningful and safer to exclude this bit of information in the output? The example I had in mind was 'Subscribers list' at http://identi.ca/csarven What do you think? I've found http://microformats.org/wiki/xfn-clarifications#is_contact_a_better_lowest_common_denominator but is this better documented elsewhere? -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] geo shorthand in anchor
On Thu, 2009-12-31 at 07:10 -0800, Tantek Çelik wrote: > One quick bit of feedback on this thread (which I'll also note on the > wiki next to the examples added) - use of the title attribute for > semicolon separated lat-long may not be the user-friendliest thing to > do. > > Given microformats experience with various uses of the the title > attribute - a good rule of thumb is to check to make sure that the > content you are putting into the title attribute is both reasonably > human readable and listenable. I've noted my observations on your observations http://microformats.org/wiki/index.php?title=geo-brainstorming&diff=41657&oldid=41586 re: your notes in the Wiki, could you explain how (lat:45.5140800; long -73.6111000) is more user friendly than title="45.5140800;-73.6111000" ? I see two things there: 1. changing the problem i.e., intended visible readable text content 2. "45.5140800" and "-73.6111000" as text values is no more human readable and listenable than as "45.5140800;-73.6111000" title value. -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] geo shorthand in anchor
On Wed, 2009-12-30 at 22:30 +, Brian Suda wrote: > On Wed, Dec 30, 2009 at 10:09 PM, Sarven Capadisli wrote: > > AFAIK: > > > > The StatusNet platform as of version 0.9RC1 e.g., > > http://identi.ca/notice/17811123 > > > > Potentially, publicly documented sites at > > http://status.net/wiki/ListOfServers on update. > > --- great, can you add/start a page on the wiki to document these? > that way we can find common formats and any emerging syntaxes. > > -brian > Added to http://microformats.org/wiki/geo-brainstorming#latitude_longitude_shorthand_and_geo_link for now. I left it out of http://microformats.org/wiki/geo-examples-in-wild and http://microformats.org/wiki/geo-examples thinking that only the acknowledged representations should be listed there. Am I right? -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] geo shorthand in anchor
On Wed, 2009-12-30 at 21:54 +, Brian Suda wrote: > On Wed, Dec 30, 2009 at 8:50 PM, Sarven Capadisli wrote: > > Yea, it does. Thanks for brining up the semantics of for @href. > > > > As far as geo links are concerned, I think it does make some sense as a > > URI. > > > > So, the next question is, should parsers pick up the geo data from the > > anchor, ignore, or do whatever they want with it? > > --- the better question is, "are people publishing it this way?" If > collect enough example, then we can make a better determination. > > -brian AFAIK: The StatusNet platform as of version 0.9RC1 e.g., http://identi.ca/notice/17811123 Potentially, publicly documented sites at http://status.net/wiki/ListOfServers on update. http://*.status.net/ as well. -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] geo shorthand in anchor
On Sun, 2009-12-27 at 18:46 +, Brian Suda wrote: > On Sun, Dec 27, 2009 at 5:51 PM, Sarven Capadisli wrote: > > My question is, whether the following is, should, or should not be a > > valid geo representation: > > > > http://www.geonames.org/6077243"; title="45.5140800;-73.6111000" > > class="geo">Montréal, Quebec, Canada > > --- that's a good question. Since the semantics of an "a" element are > for the href, but GEO doesn't make sense as a URI, i would say that it > would default to the visible text, just as if you had: > > Montréal, Quebec, > Canada > > There isn't a compelling argument to take the @title over the node > value, "Montréal, Quebec, Canada" > > does that make sense? > -brian > Yea, it does. Thanks for brining up the semantics of for @href. As far as geo links are concerned, I think it does make some sense as a URI. So, the next question is, should parsers pick up the geo data from the anchor, ignore, or do whatever they want with it? -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] geo shorthand in anchor
http://microformats.org/wiki/geo-brainstorming#latitude_longitude_shorthand mentions: If a "geo" property lacks explicit "latitude" and "longitude" subproperties, then the "geo" property is treated like any other string property (e.g. following rules for parsing , etc.), where that string value has the same literal syntax as specified in RFC 2426 section 3.4.2: single structured value consisting of two float values separated by the SEMI-COLON character (ASCII decimal 59), specifying latitude and longitude, in that order. My question is, whether the following is, should, or should not be a valid geo representation: http://www.geonames.org/6077243"; title="45.5140800;-73.6111000" class="geo">Montréal, Quebec, Canada -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Commercial application using hResume import
On Wed, 2009-09-09 at 11:54 +0100, Glenn Jones wrote: > > Sarven wrote: > > Neat. Quick feedback: > > > I tried it on http://csarven.ca/cv and it seems to pick up only a few > of > > the org vCards. > > The parser is picking up your mark-up. For example I can see that you > have use hcard/org to mark-up educational institution names. > http://ufxtract.com/api/?url=http%3A%2F%2Fcsarven.ca%2Fcv&format=hresume > &output=xml > > It's just the mapping from raw microformat data to our CV structure has > not made the best use of your mark-up. I will update our application. > > > It'd be great if it picked up the personal and contact details of > vcard > > with .uid on the page. > > The hResume spec looks for a hCard using which is marked up with the > class "contact". I could extend the parser to follow the Representative > hCard rules, but I things its better if you mark-up a hCard for hResume. > The "contact" hCard is required and technically a hResume is invalid > without it. But, the CV does have a 'contact': hresume address + hCard though, not necessarily a class="contact". >From what I can tell, the draft spec is not very clear about this. For instance, the field details doesn't mention class="contact" and neither does the Contact example. Representative hCard may be sufficient for hresume contact (updated: http://microformats.org/wiki/index.php?title=hresume-issues&diff=40740&oldid=37958 ) and it might resolve Open Issue 2006-10-19 raised by Steve Ganz http://microformats.org/wiki/hresume-issues > > Skills didn't pick up. > > You need to add rel="tag" to your skill links. This only half the > problem because if you review the http://microformats.org/wiki/rel-tag > page and read the "Tag Spaces" section you will find skills can be very > difficult to define in real world use. This is because the skill is not > the text of the link but the last segment of the URL structure. > > Not correct use > http://www.ubuntu.com/";>Ubuntu > > Correct use - has rel-tag and a tag namespace in the URL structure > href="http://en.wikipedia.org/wiki/Ubuntu/";>Ubuntu > Thanks for the heads-up. Updated. > > Education level didn't pick up. > > The education level is not part of the hResume structure. I could infer > an education level by using the NPL function on the education elements > of the hResume. So far I have resisted mixture explicit structured data > from Microformats with the more implicit data parsed by the NPL > functionality. I am worried what user expectation would be. I was referring to your NLP function. Presenting additional data outside of structured data is probably a plus given that structured data has a higher priority. I'm sure there are different view camps about this but worth to test, at least in this specific case =) > Thanks for the feedback very useful. > > Glenn > Thanks, -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Commercial application using hResume import
On Tue, 2009-09-08 at 11:49 +0100, Glenn Jones wrote: > Hi All > > The company I am part of has just released the first implementation of a > new product called CV Search and Match for the Guardian newspaper group. > It is a next generation CV database for the job board industry. > > http://jobs.guardian.co.uk/profile/ > > The interesting bit for the list is that it can import hResume as a > starting point for creating your online CV. The "Import your CV from > another website" feature can parse hResume data from any public web > page. We have also added NLP (Natural Language Processing) as a fall > back if there is no hResume. The microformat import is done using my > UfXtract parser. > > This is first of many sites we will be adding this type of functionality > to over the next few months. At the moment I believe Linked-in are the > biggest publishers of hResume although I know a lot of individuals also > publish their CV's using the hResume format. > > Please give it a go and give me feedback. You can try it even if you do > not want to be contacted by employers by switching the CV to "hidden" > once you finishing playing or you can delete all your CV data at any > time. Neat. Quick feedback: I tried it on http://csarven.ca/cv and it seems to pick up only a few of the org vCards. It'd be great if it picked up the personal and contact details of vcard with .uid on the page. Skills didn't pick up. Education level didn't pick up. -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Mozilla Jetpack API and representative hCard add-on
On Wed, 2009-06-03 at 12:54 -0400, Sarven Capadisli wrote: > * Probably the simplest solution that I can think of is to insert an @id > on the vCard node (if there isn't one already) on the fly with the > Jetpack script and send over the URI with a fragment identifier to the > transformer. The problem is that the '.vcard .uri.url[rel=me]' href > value might not be the same as the current URI + fragment identifier. > However, if I'm not mistaken '.vcard .uri.url[rel=me]' href value points > to the current URI as a representative hCard, so, it may be okay. Do you > see any issues with that? This will not work for dynamically added @id, because the transformer will not have a knowledge of it; a new GET request after all. -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Mozilla Jetpack API and representative hCard add-on
Hi all, Using the Mozilla Jetpack API [0], I created a simple add-on that looks for a representative hCard on the current Mozilla/Firefox tab and offers a link to download it as a vCard [1]. If you want to test it out, you need to first install the Jetpack API, the Jetpack script, and head over to a page with a representative hCard [2]. The way it works right now is that the script gets a hold of '.vcard .uri.url[rel=me]' href value (If that's not accurate, please let me know), and pass that onto Toby Inkster's representative hCard to vCard transformer [3]. The transformer actually grabs the representative hCard of the input URI, which makes it a little redundant operation, since we could simply pass on the current tab URI to the transformer. Still with me? What I'd really like to do is pass on only the representative hCard to the transformer which outputs the vCard. I realize this is a grey area between what the document can offer and what the parser can do with that document, but, I know the latter is less of a concern. So, I think there are some options which could make this fun extension a bit better, but, I'd love to hear other possibilities. * Passing the hCard object as a data: URI to the hCard to vCard transformer using Brian Suda's X2V [4] (suggested by Tantek Çelik). This however hits the HTTP GET length limit. Are there are any transformers that can do this via HTTP POST? * We can also output a copy of the representative hCard to a temporary file on a server, then point the parser at the temporary file. Could use a pastebin even (suggested by Toby Inkster). A little inconvenient, but, possible. * Probably the simplest solution that I can think of is to insert an @id on the vCard node (if there isn't one already) on the fly with the Jetpack script and send over the URI with a fragment identifier to the transformer. The problem is that the '.vcard .uri.url[rel=me]' href value might not be the same as the current URI + fragment identifier. However, if I'm not mistaken '.vcard .uri.url[rel=me]' href value points to the current URI as a representative hCard, so, it may be okay. Do you see any issues with that? All feedback more than welcome. -Sarven [0] https://jetpack.mozillalabs.com/ [1] http://csarven.ca/labs/jetpack/representative-hcard.php [2] http://identi.ca/csarven http://tantek.com http://brigitteschuster.com http://www.more.ca/my_more/user/JennGruden [3] http://srv.buzzword.org.uk/representative-hcard-to-vcard.cgi?uri= [4] http://suda.co.uk/projects/microformats/hcard/get-contact.php?uri= ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Watching watchlists properly: the lack of an email setting
Alternatively, you could subscribe to the Atom or RSS feed of the page (e.g., http://microformats.org/wiki/index.php?title=Special:RecentChanges&feed=atom ) -Sarven On Thu, 2009-04-23 at 21:19 +0100, André Luís wrote: > Tiago, > > good point. I'd also be interested in getting my watchlist in the mail > (or rss, or something) instead of having to login to check if there > were any changes. > > Ben, can you shed some light on this? Is this off by choice? And if so, why? > > Thanks in advance, > -- > André Luís > > On Thu, Apr 23, 2009 at 5:35 PM, Tiago Rodrigues > wrote: > > I've recently (yesterday !) came into the world of Microformats and > > after looking at some stuff on the wiki, I decided it would be a good > > idea to watch pages for some microformats I'm using which are still on > > a draft phase, and might still be subject to change. > > > > I had to register on the wiki to do this, and I noticed there was no > > field to fill in my email. This means I can't get watchlist alerts on > > my email, and if I want to keep updated I need to come back to the > > microformats wiki and look at my watchlist every now and then, which > > I'll most likely forget about. > > > > Mediawiki supports this functionality since version 1.5, and since the > > Microformats wiki was upgraded last November to version 1.13, this > > funcionality exists, but is deactivated. > > > > Is there a reason for this ? Or didn't anyone think about this before ? > > > > Also, having no e-mail kinda defeats the purpose of having Gravatar, > > since this is based on the email you use to register on a website. > > > > This is also my first post on this (or any microformats related) > > mailing list, so hello everyone ! > > > > > > -- > > Tiago Rodrigues > > http://www.trodrigues.net > > E-Mail / MSN Messenger / Jabber / GTalk: > > tmcrodrigues [at] gmail [dot] com > > Skype: trodrigues.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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Social Graph Explorer and Identify
Way to go! Might want to update Identica's favicon with: http://identi.ca/favicon.ico Noticed a few odd stuff in Identify but as you said it is still new. Might want to see "/sarven-capadisli" come up at http://identi.ca/csarven which points to an nonexistent URI: http://identi.ca/sarven-capadisli BTW, which 'note' is being grabbed for the hCard? And are you concatenating all possibly results in SGE and Identify? -Sarven On Mon, 2009-03-16 at 13:03 +, Glenn Jones wrote: > Hi All > > I built two new demo's for the Microformats panel at SXSW. The aim was > to try and show the power of rel=me. > > Social Graph Explorer > This is a tool which can be used to explorer an individual's combined > web identity across various social network/media sites. It takes a > social network profile URL (i.e. twitter.com/glennjones) and tries to > find out what it can about that individual. Once it has return a > combined web profile you can also drill into some of the public content > that person has published on the web. It makes extensive use of Google's > Social Graph API , microformats, RSS and Atom. > http://lab.madgex.com/socialgraph/socialgraphexplorer.aspx > > Identify - Firefox extension > Identify is a Firefox extension that combines identities across various > social network/media sites and provides you with a profile about an > individual. > http://lab.madgex.com/identify/ > > > Currently Social Graph Explorer is a much more powerful and accurate. It > uses a rule set which includes the hcard-xfn pattern and a extended > version representative hCard idea. Identify uses YQL and needs a little > more work in this area, so you may get false positives. I am going to > keep working on Identify. > > Any feedback is most welcome. > > > Glenn Jones > > > > ___ > 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] Open microblogging and microformats
On Fri, 2009-02-13 at 22:33 +, Toby A Inkster wrote: > Another good microformatty thing to do would be a profile import as > part of the signup. As the first step, ask them for a pre-existing > profile URL (e.g. their profile on Twitter, or their own website), > then parse that looking for hCard and XFN (and for bonus points also > look for FOAF, RDFa, etc). That way, you should be able to pre-fill > many of the sign-up fields, and easily find their existing contacts > who are already registered on identica. > > For people who are already signed up, you could offer a tool to > import an XFN list (again, bonus points for FOAF and RDFa). Profile import using hCard is in my todo. Bringing XFN and FOAF into the picture for importing contacts sounds like an awesome idea! I'll create a ticket for this, thanks. -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Open microblogging and microformats
On Thu, Feb 12, 2009 at 7:35 AM, Glenn Jones wrote: > I have taken some time to go through http://identi.ca and have to say > that it has one of the best implementations of microformats in a social > media site. Although many social media sites now add microformats, they > all tend to have a few problems or miss out bits of semantic content > that could be marked up. Their formal API's often contain data > structures, that have just not been mark-uped with microformats in the > HTML. > > The microformats coverage in identi.ca is so complete I would say you > have achieved a full read-only API that is embedded into your pages. If > you added OAuth support for secured web pages, I could build > applications against your site without asking for passwords or needing a > separate API. > > That would be an great example of the power microformats ! That's really great to hear, thank you! We are working on OAuth right now and we'll have something ready for the next laconica release. All but email is already visible on the site, so you can read them without the need of OAuth. Write with OAuth will follow soon. If you have any specific questions, you can join us in #laconica (Zach Copley can answer OAuth questions better than I can) on IRC freenode or look into http://laconi.ca I hope this helps. -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Open microblogging and microformats
Hi all, A small promotion for open microblogging and microformats here: If you haven't come across http://identi.ca I'd like the take this opportunity to mention a few things that this community might be interested in. Identica uses the http://laconi.ca microblogging software, available under the GNU Affero General Public Licence. You can help improve the code. Our development repository is hosted on gitorious: http://gitorious.org/projects/laconica . See also http://identi.ca/doc/faq Currently, laconica supports the following: * hCard * XFN * hAtom * bunch of rels (tag, license, group, member, prev, next, in-reply-to, home...) e.g., http://identi.ca/csarven There are semweb groups you might be interested in joining: http://identi.ca/group/microformats http://identi.ca/group/semweb http://identi.ca/group/rdfa http://identi.ca/group/foaf If you'd like to chime in with your comments or suggestions, there are a lot of ears. You can reach the laconica community by: * IRC ( irc://irc.freenode.net/%23laconica ) * Mailing list ( http://mail.laconi.ca/mailman/listinfo/laconica-dev ) * Groups ( http://identi.ca/group/laconica or others like !identica ) Looking forward to the awesome tools you guys are going to come up with. -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Twitter implementation issues
On Wed, Feb 11, 2009 at 10:56 AM, Glenn Jones wrote: > The guys at Twitter have done a great job of adding microformats to > their site. Like everyone else in the developer world I love building > twitter mash-ups, (the new hello world) but I like to use microformats > as my API. Unfortunately there are one or two small issue with the > Twitter implementation. So I have fired off a email to their support, > but have no heard back yet. I thought I may be able to reach them > through the list. May be you work for Twitter and known the right person > to forward this to. > > Below I documented some problems and made some suggestions on how they > could be easily fixed. They are just suggestions. Hi Glenn, I work on http://identi.ca the http://laconi.ca microblogging software, available under the GNU Affero General Public Licence and we're all ears for improving in any way we can. You can talk to us either on this list or at http://mail.laconi.ca/mailman/listinfo/laconica-dev > I already have a couple of Twitter integrations demo's for this year's > SXSWi Microformats panel, I would love to increase what I could show. Perhaps you can use http://identi.ca as your demo case as we already have the things you'd like to see. Is there anything we can do to help you out? Currently, we support the following: * hCard * XFN * hAtom * bunch of rels (tag, license, group, member, prev, next, in-reply-to, home...) e.g., http://identi.ca/csarven I'll take this as an opportunity to ask the microformats community for their comments and suggestions to make http://identi.ca more "microformats friendly". Thanks, -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Wiki 2.0 is alive!
On Mon, Nov 17, 2008 at 5:47 AM, Ben Ward <[EMAIL PROTECTED]> wrote: > Hi everyone, > > As promised, the wiki had some downtime this evening as I ran a fairly large > upgrade of MediaWiki and the design of the microformats wiki. > > It's been quite a long time coming, and a lot of work, but I hope people > appreciate the improvement. > > The new features of the wiki are documented on the wiki itself[1], along > with an issues page[2]. You can also get a drive-by idea of what kind of > improvements I've made by visiting the frontpage[3], the hCard page[4] and > the hAtom page[5]. > > Feedback is welcome as always, either here, on the aforementioned issues > page or on the associated blog entry[6]. > > 1. http://microformats.org/wiki/wiki-2 > 2. http://microformats.org/wiki/wiki-2-issues > 3. http://microformats.org/wiki/ > 4. http://microformats.org/wiki/hcard > 5. http://microformats.org/wiki/hatom > 6. http://microformats.org/blog/2008/11/17/wiki/ > > Thanks for your patience with the upgrade. > > Ben This is awesome! Thanks Ben. Off I go click around. -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Incorrect mention of the address element for hAtom entry author in the Wiki
hAtom Entry Author states "an Entry Author element should be encoded in an element" [1]. This is misleading and in most cases an incorrect use of for an Entry Author [2]. I propose we remove this clause from the Wiki. [1] http://microformats.org/wiki/hatom#Entry_Author [2] http://microformats.org/wiki/hcard-faq#Should_I_use_ADDRESS_for_hCards -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: User comment entries
Apologies for some of the obvious typos in my previous email. If it may have caused any confusion, please see the Wiki: http://microformats.org/wiki/hatom-brainstorming#User_comment_entries Thanks, -Sarven On Sat, Oct 4, 2008 at 12:29 AM, Sarven Capadisli <[EMAIL PROTECTED]> wrote: > Hi all, here is what I'm thinking about user comments: > > A user comment (e.g., in blogs, wikis, forms) can be marked as an > hAtom [1] since it has a similar content pattern. A way to > differentiate an hEntry (e.g., a blog post) from another hEntry (e.g., > a user comment) can be done reusing "in-replies-to" [2] from Atom > Threading Extensions [3]. It provides a mechanism to indicate that an > entry is a response to another resource. > > rel="in-repl-to" can indicate that the current hEntry is a reply to > another hEntry and has a reference point @href: > Parent > > hEntries that use rel="in-reply-to" can be considered as a comment > entry in response to a parent entry in the threaded conversation > (e.g., in blogs, wikis, forms). > > hEntries that are chronologically listed can all use rel="in-repl-to" > and refer to the root hEntry (e.g., blog post, form post) > > By reusing in-reply-to , we can solve the microformats representation > for user comments [4], [5], [6]. > > I've put the above into hatom-brainstorming in the Wiki [7]. > > What do you think? > > [1] http://microformats.org/wiki/hatom > [2] http://tools.ietf.org/html/rfc4685#section-3 > [3] http://tools.ietf.org/html/rfc4685 > [4] http://microformats.org/wiki/mfcomment > [5] http://microformats.org/wiki/hcomment > [6] http://microformats.org/wiki/comment-brainstorming > [7] http://microformats.org/wiki/hatom-brainstorming#User_comment_entries > > Sarven Capadisli > http://www.csarven.ca > ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] User comment entries
Hi all, here is what I'm thinking about user comments: A user comment (e.g., in blogs, wikis, forms) can be marked as an hAtom [1] since it has a similar content pattern. A way to differentiate an hEntry (e.g., a blog post) from another hEntry (e.g., a user comment) can be done reusing "in-replies-to" [2] from Atom Threading Extensions [3]. It provides a mechanism to indicate that an entry is a response to another resource. rel="in-repl-to" can indicate that the current hEntry is a reply to another hEntry and has a reference point @href: Parent hEntries that use rel="in-reply-to" can be considered as a comment entry in response to a parent entry in the threaded conversation (e.g., in blogs, wikis, forms). hEntries that are chronologically listed can all use rel="in-repl-to" and refer to the root hEntry (e.g., blog post, form post) By reusing in-reply-to , we can solve the microformats representation for user comments [4], [5], [6]. I've put the above into hatom-brainstorming in the Wiki [7]. What do you think? [1] http://microformats.org/wiki/hatom [2] http://tools.ietf.org/html/rfc4685#section-3 [3] http://tools.ietf.org/html/rfc4685 [4] http://microformats.org/wiki/mfcomment [5] http://microformats.org/wiki/hcomment [6] http://microformats.org/wiki/comment-brainstorming [7] http://microformats.org/wiki/hatom-brainstorming#User_comment_entries Sarven Capadisli http://www.csarven.ca ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] ISO Dates and Durations using Style
On Sat, Sep 27, 2008 at 3:43 PM, Martin McEvoy <[EMAIL PROTECTED]> wrote: > If any style sheet language can be used, why don't microformats create their > own style language eg: > > 4th Jan, 1968 > > or something similar, parsers can just as easily determine values from > @style as they can any other property. Interesting. For HTML 4, AFAIK, the intention of a style sheet language is to provide a way to *present* an existing structure. It is not meant to bring in additional structure or semantics. Having said that, this is not the case in XHTML 1 with XSLT. I may be misinterpreting and so it would be nice to hear what everyone else have to say about this. Creating a style sheet language just for microformats goes out of the way of trying to work within existing standards. If we were to say okay to this, I'm sure there are plenty of ways where we could extend the representation of microformats (which will most likely go against the principles). Placing data that is intended for the machines inside @style is bound to run into the same arguments against @title (even though I don't personally believe the information in @title is intended for machines) -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] ignoring minimal hCards
On Fri, Sep 5, 2008 at 5:20 PM, Karsten Januszewski <[EMAIL PROTECTED]> wrote: > Consider Twitter: my Twitter profile page has 120 hCards on it (representing > everyone who is following me on Twitter), but none of those hCards contain > any real interesting data. > > I understand this is a side effect of the fact that only FN is required in > hCard. What are people's thoughts on sites that minimally adopt Microformats? To some extent. If an hCard contains the url property (arguable one of the most valuable), further information can be obtained about that contact by following up on the resource. Sarven Capadisli http://www.csarven.ca ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Today, Tomorrow, and Someday Problems
On Thu, Sep 4, 2008 at 8:47 PM, Martin McEvoy <[EMAIL PROTECTED]> wrote: >> Why would you want to use RDFa? For the same reason you want to use >> microformats. Because you care about machines understanding what is on your >> page, not just humans. > > Is it not the other way around in the microformats community? I don't think so. Both are essentially saying humans indeed do come first but we also want to help the machines understand a bit of what humans do. I think neither of them cancel out the need for the other. -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] URL and Relative paths
On Wed, Sep 3, 2008 at 9:14 AM, Scott Reynen <[EMAIL PROTECTED]> wrote: > On [Sep 2], at [ Sep 2] 6:45 , Martin McEvoy wrote: > >> I think relative urls on the whole are "bad form" because many authors >> forget to set the base url for their relative paths... > > > There's nothing wrong with that. See: > > http://www.faqs.org/rfcs/rfc1808.html > >> 3.3. Base URL from the Retrieval URL >> >> If no base URL is embedded and the document is not encapsulated within >> some other entity (e.g., the top level of a composite entity), then, if a >> URL was used to retrieve the base document, that URL shall be considered the >> base URL. I was going to respond to this last night with an RFC line as well but figured that it wasn't a direct response to Martin's "bad form" statement. If I understand Martin's statement correctly (Martin, correct me if I'm wrong), he is talking about the general use of relative URLs in absence of the base element e.g., relative URLs from an external resource in an iframe can potentially resolve to unintended URIs if the base element is missing. Surely, a relative URL is resolved to full URI and in and of itself this is not "bad form". Sarven Capadisli http://www.csarven.ca ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats on YouTube
On Sun, Aug 24, 2008 at 7:42 PM, Chris Messina <[EMAIL PROTECTED]> wrote: > I searched around on the wiki and mailing list and didn't see anyone > else reference this, so I thought I'd share that YouTube has added > basic hcard support to its video pages: > > http://www.flickr.com/photos/factoryjoe/2793731119/in/photostream/ > > I've added this to the hcard-examples-in-wild-pending page. Thanks Chris. It was only fairly recent that the YouTube dev team asked this community on how to approach microformats [1]. Nice to see that they have hCard going. [1] http://microformats.org/discuss/mail/microformats-new/2008-July/001643.html Sarven Capadisli http://www.csarven.ca ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] HTML 5 data- attributes
On Wed, Jul 16, 2008 at 10:20 AM, Ben Ward <[EMAIL PROTECTED]> wrote: >> User agents must not derive any implementation behavior from these >> attributes or values. Specifications intended for user agents must not >> define these attributes to have any meaningful values. > > -data prefix attributes are, by design and intention, for use by individual > applications. They are explicitly excluded as a mechanism for microformats > and the like. Indeed. And: "Embedding custom non-visible data" goes rather against marking "visible" data. Brief #whatwg conversation: http://krijnhoetmer.nl/irc-logs/whatwg/20080520#l-70 -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats search engine: virel
On Mon, Jul 7, 2008 at 6:34 PM, Angus McIntyre <[EMAIL PROTECTED]> wrote: > > Christian Heilmann wrote: >> That's got nothing to do with microformats ... > > With due respect, I don't completely accept that. A case could be made > that factors that influence people's adoption of microformats are > legitimate topics for discussion. Uneasiness about the 'spammability' of > addresses published in hCard is a deterrent to full adoption of that > microformat for many users. While these considerations don't belong in the > spec, they can usefully be mentioned in texts about the spec, such as > 'getting started' guides. > >> ... when you really think >> that any obfuscation like bla dot domain is not indexed by spammers then >> you are in for a treat. There is no way to protect emails online without >> hurting usability or accessibility. Don't waste your time with >> JavaScript (de)obfuscation, it is a glass shield or - even closer - a >> pacifier button. > > Again, I'm not in complete agreement with you. My experience - and I have > actually tested this, although not as rigorously or extensively as I'd > like - is that very few spammers seem to be doing much de-obfuscation, and > even trivial obfuscations _currently_ offer a good degree of protection. > However, I don't expect that state of affairs to last, so it's a moot > point. > >> What you put in microformats you should be happy with to be put out >> there to be found, indexed and converted. Obfuscated microformats that >> expect the reader technology to convert it before turning it for example >> into a vcard are just a nuisance for the end user. > > In the Javascript-based approach that I mentioned, the browser takes care > of everything, with no extra work needed by the reader. However, I concede > that that might not extend to screen readers (although choosing a sane, > human-readable representation for the basic form can help here). > Actually, Christian is bang on with "There is no way to protect emails online without hurting usability or accessibility." I've documented a fair number of ways to obfuscate (depends on how you interpret it) email addresses in source and they all have pros and cons, and all are dependent on various factors [1]. >> ... This is about unearthing information we already publish and >> make easier to access and re-use it, which is the opposite of >> obfuscating. > > OK, so there's an implicit challenge here. For users who are unwilling to > expose their email address through hCard, what alternative mechanisms can > microformats support? Many website owners use mail forms instead of > publishing their email addresses. Is there a need for something like a > simple 'rel=contactform' microformat to signal the availability and > location of a mail contact form? I would also stress that this is not a problem that microformats should be solving. The principal in solving something like this is also not solely about "emails" but any data for that matter (e.g., Do you want the "bad" guys to know your fn and street-address?) [1] http://www.csarven.ca/hiding-email-addresses ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and RDFa not as far apart as previously thought
On Wed, Jun 25, 2008 at 5:23 AM, George Brocklehurst <[EMAIL PROTECTED]> wrote: > Is it worth revisiting Tantek's original suggestion of using the object > element to represent dates? [1] > > The idea was to do something like this: > >January 25 > > From what Tantek said on his blog, the main reason for not using objects was > that they were not well supported in Safari. However, Safari's object > support is now much improved: fallbacks are supported and display:inline and > intrinsic sizing will work correctly. Safari 2.0.2, which came out in > November 2005, was the first version to contain these improvements [2]. 1. The purpose of the element is to allow the browser to run an external application for a non-native data type (e.g., Java applet) [1]. 2. Safari 3 is actually handling the corect way. [2] is not the right way to go in this case. [1] http://www.w3.org/TR/REC-html40/struct/objects.html#h-13.3 [2] http://microformats.org/wiki/include-pattern-feedback#Objects_and_Browser_Behavior (see point: Sarven Capadisli 16:34, 23 Jun 2008 (PDT)) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] (in include-pattern) and user-agents
Based on this conversation: http://krijnhoetmer.nl/irc-logs/whatwg/20080617#l-444 will embed (making a separate request) all of the content from the current document, meanwhile pointing to the identifier. The issue here: http://microformats.org/wiki/include-pattern-feedback#Objects_and_Browser_Behavior is actually the proper way is supposed to be handled by the user-agents. (Safari 3/Win, it turns out, is treating the element properly.) I do wonder if is semantically accurate for the use of include-pattern. Part of me is thinking that was originally used partially because it didn't display the current document on non-Safari browsers. http://www.w3.org/TR/html401/struct/objects.html#h-13.3 states: "Most user agents have built-in mechanisms for rendering common data types such as text, GIF images, colors, fonts, and a handful of graphic elements. To render data types they don't support natively, user agents generally run external applications. The OBJECT element allows authors to control whether data should be rendered externally or by some program, specified by the author, that renders the data within the user agent." The key being "to render data types" the user-agents "don't support natively" can be handled with by running an external application. In the case of the include-pattern, we are merely trying to "include" or "refer" to some text/html. The latter is done sufficiently with . Got thoughts? Sarven Capadisli http://www.csarven.ca ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] entry-title on
On Fri, Apr 4, 2008 at 6:23 PM, Scott Reynen <[EMAIL PROTECTED]> wrote:
> It's documented here:
>
> http://microformats.org/wiki/parsing
>
> I just added a link to that from here:
>
> http://microformats.org/wiki/hatom-parsing
Thank you.
> > In the case of should entry-title be the @title value since it
> > is more accurate - also more visible - then the use of @alt? If @title
> > is absent, then perhaps @alt may be used?
> >
>
> I don't think so. @alt is alternative content ("this attribute specifies
> alternate text"), whereas @title is description of that content ("This
> attribute offers advisory information about the element for which it is
> set."), so @alt should be preferred for textual properties (e.g.
> entry-title).
@alt is meant for "alternative text" in cases where can't be
experienced visually. It is otherwise invisible.
@title is meant to be visible alongside the .
entry-title value should be visible.
Sarven Capadisli
http://www.csarven.ca
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] entry-title on
Operator 0.9.1 http://tools.weborganics.co.uk/ http://tools.microformatic.com/help/xhtml/hatom/ all grab the @alt value for entry-title. Is this documented anywhere for hAtom parsing? In the case of should entry-title be the @title value since it is more accurate - also more visible - then the use of @alt? If @title is absent, then perhaps @alt may be used? Sarven Capadisli http://www.csarven.ca ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Minimisation of figure
Figure case: User avatar or photograph of an individual. I think it would be better to use @alt as the legend content [1] since @alt is required for wheres @title is optional. This will also minimise any redundant information (even though essentially for different purposes). This would be the minimal case: As opposed to: Suggesting @alt as the legend text further encourages the authors to use a value for the attribute instead of leaving it empty: Hence, I propose: "If the "legend" class is found on the same element as the "image" class (or the image inferred by the previous rule), then the contents of the title attribute MUST be used as the legend." [1] should be changed from *title* to *alt*. [1] http://microformats.org/wiki/figure#Minimisation -Sarven Capadisli http://www.csarven.ca ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Unjust banning of Andy Mabbett
I must say I was embarrassed to read Manu's response to Andy's ban due to not speaking out about the ban sooner. I felt that there must have been something that the admins knew better then myself about this 'slowing down the process' business. I was nevertheless shocked to hear about the ban simply knowing that Andy has been far more involved in the community then anyone else (as Manu rightfully pointed out). I had no problems following his contributions and I'm glad he took the time to put them forward. Instead of banning someone that pushes the community forward (at least in my view), why not make use of such great resource and work together? If you feel that someone is holding the community back from moving forward due to their reasoning, then present your case - I'm sure the community will settle on the right approach sooner or later. At least it will be documented. Just my two cents. -Sarven On Sat, Mar 8, 2008 at 4:45 PM, Manu Sporny <[EMAIL PROTECTED]> wrote: > I just got back from vacation, otherwise this would have gone out > sooner. It has come to my attention that Andy Mabbett has been banned by > the admins for 18 months[1]. > > This is an unjust punishment, especially considering that he is one of > the largest contributors to our community. Rather than make sweeping > assertions and accusations, I'm going to back this post up with hard > data. Here are the statements that will be addressed: > > - Andy is one of our most prolific contributors, this community will be > harmed by such a long-term ban. > - An 18 month ban does not fit Andy's behavior - it is an unjust > punishment. > - Andy was tried as guilty, without complete documentation. > - Andy pushes the limits in this community, and because of him, we know > what is and is not acceptable in this community. > - Andy says what some of the rest of us are thinking, and he shouldn't > be banned for such an extreme length of time for voicing his opinion. > > Andy is one of our most prolific contributors > - > > Maybe most of you are unaware of Andy's contributions to this community. > I took the time to write a script to download and analyze the entire > history on Microformats.org's mailing lists (the script is attached to > this e-mail). Here are the top contributors to the microformats-discuss > mailing list: > > andy mabbett - 1133 posts - 9.68% of contributions >ryan king - 885 posts - 7.56% of contributions > tantek celik - 833 posts - 7.11% of contributions > scott reynen - 504 posts - 4.30% of contributions > brian suda - 467 posts - 3.99% of contributions > david janes - 432 posts - 3.69% of contributions >chris messina - 388 posts - 3.31% of contributions >charles krempeaux - 233 posts - 1.99% of contributions >mike schinkel - 193 posts - 1.65% of contributions > dr. ernie prabhakar - 188 posts - 1.61% of contributions > danny ayers - 171 posts - 1.46% of contributions > kevin marks - 145 posts - 1.24% of contributions > ciaran mcnulty - 135 posts - 1.15% of contributions > frances berriman - 134 posts - 1.14% of contributions > ben ward - 126 posts - 1.08% of contributions >bruce d'arcus - 120 posts - 1.02% of contributions > paul wilkins - 119 posts - 1.02% of contributions > dimitri glazkov - 110 posts - 0.94% of contributions >benjamin west - 107 posts - 0.91% of contributions > > Here are the top-10 contributors to the microformats-new mailing list: > > manu sporny - 298 posts - 19.13% of contributions >martin mcevoy - 238 posts - 15.28% of contributions > andy mabbett - 182 posts - 11.68% of contributions > scott reynen - 148 posts - 9.50% of contributions > brian suda - 62 posts - 3.98% of contributions > tantek celik - 37 posts - 2.37% of contributions > david janes - 36 posts - 2.31% of contributions > guillaume lebleu - 27 posts - 1.73% of contributions > frances berriman - 26 posts - 1.67% of contributions > julian stahnke - 20 posts - 1.28% of contributions > > It is quite evident from this data that Andy has produced more than > anyone else in this community, even assuming that 10% of the threads > that he starts result in a ban on his account. I know of no other > community that would treat one of their primary contributors in this manner. > > An 18 month ban doesn't fit Andy's behavior > --- > > Banning somebody for 18 months is quite a serious amount of time, and > while the admins might not have come to the decision lightly, I do > question whether the punishment is justified. If you look at the > documented rules that were added/changed due to Andy[2], you will note > that a whopping 13 of the 17 are EDITORIAL rules. The other 4 are > behavioral rules
[uf-discuss] Fictional or intangible entities in hCard
Can hCard be used for fictional or intangible entities? Is this addressed anywhere? Examples: * Purple unicorn * Heaven Main Lobby * Hypercube * Dream character -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] hKit and include-pattern scope
Isn't the importation of data from external resources using hKit face similar issues as in include-pattern? re: http://microformats.org/wiki?title=include-pattern-faq&diff=0&oldid=25623 -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] A further possible solution to the "abbr" accessibility issue
On 2/8/08, Andy Mabbett <[EMAIL PROTECTED]> wrote: > In message <[EMAIL PROTECTED]>, Andy Mabbett > <[EMAIL PROTECTED]> writes > > >Early in December, I made the following suggestion, but in a separate, > >and unclearly-titled thread. > > > >I'm reposting it here, in a new thread, in the hope that it will > >warrant discussion: > > [prefix changed to "data"] > > >> title="data:20070912T16:03:00+01:00"> > > 4.03pm > > > > A further advantage of this method has just occurred to me; it could use > plain-language *and* machine values in one title, thus: > > title="we start at three minutes > past four - data: 2007-09-12T16:03:00+01:00"> > 4.03pm > > > and we could even exempt parentheses: > > title="we start at three minutes > past 4 (data: 2007-09-12T16:03:00+01:00)"> > 4.03pm > > > -- > Andy Mabbett I wonder if this will be heavy for the parsers when both "plain-language *and* machine values" are mixed i.e., knowing the scope of the regex to differentiate between the two. -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard: url and tel
I suppose I should have posted this in the mailing list: http://rbach.priv.at/Microformats/IRC/2007-12-06#T192503 -Sarven On 1/7/08, Katrina <[EMAIL PROTECTED]> wrote: > Guillaume Lebleu wrote: > > Andy Mabbett wrote: > >> > >> When did you last see a listing of, say, Pizza restaurants that labelled > >> each telephone number as "work"? > >> > >> When did you last see a listing of, say, Pizza restaurants that included > >> the managers' home numbers? > >> > >> > > In that same vein, we could ask: when did you last see a phone number > > not being a work number when both a person's formatted name and > > organization name were present? > > > > So, to avoid the meta discussion and go back to Kat's specific problem > > (she wants to specify a phone as work but without the content containing > > "work" or any of its abbreviations), maybe something that would work > > would be to have an implied 'work' tel type when a fn and an org that > > are both present and a tel type is not present. I believe we could have > > an implied 'voice' type in this case as well. > > > > Sorry in advance if this idea has already been proposed/discussed. > > > > Awesome and Brilliant. > > Thanks Guillaume and Tantek! :)) > > Kat > > ___ > 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] That pesky abbrevation tag (yet again)
As far as I know, the examples are focused more on the "type"s that are being used instead of semantic markup. I wrote this bit a while ago, perhaps it can be used: http://microformats.org/wiki/adr-examples#Use_of_dl_element I agree examples should be as semantic as possible, however there are many instances where the formats are not bound to any particular element(s) as far as semantics are concerned. For instance, hCard information can be presented in or or tags. Therefore, it may be more appropriate to suggest that semantic markup should be used in context of the document. -Sarven On Jan 5, 2008 9:31 AM, Jim O'Donnell <[EMAIL PROTECTED]> wrote: > Hello, > > There are couple of markup examples on the hcard examples page which > don't make sense semantically. The URL is > http://microformats.org/wiki/hcard-examples#3.2.1_ADR_Type_Definition > where you can see > > US > home address, for > mail and > shipments: > 123 Main Street > Any Town, CA span>, > 91921-1234 > > > and immediately below it > Please use the following address label for > > local delivery > to my home > of mail > and packages: > > Mr.John Q. Public, Esq. > Mail Drop: TNE QB > 123 Main Street > Any Town, CA 91921-1234 > U.S.A. > > > > None of the tags are being used to mark up abbreviations, > except maybe for 'US" where the expansion should be 'United States', > not 'dom'. > > Is there a way of setting out these examples using semantic HTML? I'm > worried that people, particularly those new to microfomats, will see > that microformats.org supports semantic HTML and thus infer that > examples, like these, on the wiki are written in semantic markup. > These, quite clearly, are not. > > Cheers > Jim > > Jim O'Donnell > [EMAIL PROTECTED] > http://eatyourgreens.org.uk > http://flickr.com/photos/eatyourgreens > > > > ___ > 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] Using an external resource for the include-pattern
re: http://microformats.org/wiki/include-pattern-faq#Q:_Does_include-pattern_support_for_data_outside_of_the_current_page.3F http://microformats.org/wiki/include-pattern#scope I presume the "ease of implementation" is referring to a *parser* grabbing the data from another resource. As far as marking up a document, I don't see how the "vast majority of use cases" should dictate this and it is certainly trivial to provide a relative/absolute URL in the href (e.g. href="http://www.csarven.ca#hcard";) of the document. Can the parsers perhaps store cookies on the client-side and minimize the HTTP requests? I'm not well versed in FOAF but perhaps this is related and I do wonder how it approaches this. I would appreciate it if anyone could point me to the past logs on this stuff. Thanks. -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Precise Expansion Patterns
On Dec 16, 2007 2:16 PM, Benjamin Hawkes-Lewis <[EMAIL PROTECTED]> wrote: > Martin McEvoy wrote: > > On Sun, 2007-12-16 at 18:01 +, Benjamin Hawkes-Lewis wrote: > >> 1. Search engines currently "ignore" TITLE on non-linking A. (Does > >> anyone has any clear evidence to confirm this? Does that evidence > >> hold > >> for all major engines, or only for Google? I can't find anything > >> solid.) > > > > this may help: > > go here http://www.webconfs.com/search-engine-spider-simulator.php > > copy and paste this url > > http://weborganics.co.uk/files/test.html > > > > the test consists of four anchor texts two with href attributes two > > without > > > > It isnt the definitive answer but I would say pretty accurate ;) > > That's a cute tool, but I certainly wouldn't rely on a search engine > simulator to be an accurate guide to the details of how real search > engines like Google and Yahoo! Search index and weight content. > > -- > Benjamin Hawkes-Lewis > > ___ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > This is one of the reasons not to rely on what some of the agents are doing with the documents. Not only is it not reliable (because they all take a guess) but also there is no guarantee how the information will be extracted/perceived in the future with the actual search engines. As I mentioned before, the formats should steer clear from what these agents may be doing and instead focus on deriving solutions that is sound within the document. Jeremy Keith wrote: > If a design pattern is going to *mandate* that authors must use a > particular element, then the semantic meaning of that element needs > to be pretty solid. I totally agree with this. -Sarven ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Precise Expansion Patterns
This is to address "SEO" and anchors () in documents.
Fortunately, good SEO is more complex then boiling down well-ranking
in SERPs into how the anchors are set in a document.
Regarding: http://microformats.org/wiki/anti-patterns#empty_hyperlinks
point A) if there is no href attribute and value set then the current
document is not pointing to any resource, therefore there is no impact
on PR as there is no weight to distribute between documents.
point B) Google or any other search engine will not simply ban a Web
site from the left-field if there are no obvious indicators ("bad
intentions") to be delisted from SERPs. Needless to say, getting
banned is not a quick automated action and "spamming" goes much
further then that.
Moreover this is like suggesting using URL fragments (internal link
anchors) in href is bad for SEO.
In addition to all this, I do not think that microformats should be
concerned with the SEO practices as there are many guidelines out
there and which method works well for one site today on a particular
engine may not necessarily work tomorrow. Therefore, I strongly think
that we move away from these sort of practices.
I've written about good SEO practices (read: good Web development
practices) if anyone would like to give it a read:
http://www.csarven.ca/internal-seo-guidelines
By mentioning all this I am not suggesting the usage of empty anchors
(no href attribute/value).
-Sarven
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
