Re: [uf-discuss] Training events in hResume
On 12/02/07, Pat Ramsey [EMAIL PROTECTED] wrote: Training being a learning experience, I would think marking it up as education is appropriate. But work is (or perhaps should be) a 'learning experience' too. It's not quite the same thing, but most application forms I've filled in have had separate sections for Education and Training. A quick google for some examples: 1 - http://www.chichester.gov.uk/your_council/council_jobs/copy_of_job_appln_form1.cfm (link to Word doc on page) - Has an 'EDUCATION PROFESSIONAL QUALIFICATIONS' section, separate boxes for schooling, professional qualifications and 'other relevant training' but all under the same heading. 2 - http://www.tendringdc.gov.uk/NR/rdonlyres/E8AE5F2D-4F09-46F7-8044-9A45A924CDCE/0/ApplicationForm130306.pdf - seperate sections for Education and Professional Qualifications 3 - http://www.unison.org.uk/acrobat/B1491.pdf - separate sections for Education and Training, though the distinction is that anything which leads to a qualification is Education, and everything else is Training. This is perhaps a more useful practical distinction than the slightly nebulous concepts I had in mind. 4 - http://www.scope.org.uk/downloads/jobs/jobapp_may05.doc - similar to 3, things with an exam are Education, other things are Training. 5 - http://www.rhul.ac.uk/personnel/application.pdf - similar to 1, all in one section but sperate boxes for School, Further/Higher Education, Formal Qualifications and Other Training 6 - http://www.broxtowe.gov.uk/application_form_april_2006.pdf - Education and Training all in the same box/section. On the basis of the above examples, I would suggest that a distinction between education and training could be useful as clearly employers sometimes see them as distinct concepts. Rob ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Tutorial on AHAH (such a cool technology!)
On 2/12/07, Benjamin West [EMAIL PROTECTED] wrote:
Roger,
Neat stuff. I thought it was pretty good, but take some issue with the
following:
a href=javascript:ahah('Waldorf-Astoria-Photo.html','Photo');photo/a
The best practice is to wire the event up, and to use a button when
the element is not truly a link.
Something more like:
button onclick=ahah('Waldorf-Astoria-Photo.html','Photo');photo/button
or even better:
button id=photo_changer type=button photo/button
script type=text/javascript
// must be done either after onload fires or after the element appears
in the DOM...
// find the element.
photoButton = document.getElementById('photo_changer');
// wire up the event.
photoButton.onclick = function () {
ahah('Waldorf-Astoria-Photo.html','Photo');
};
/script
-Ben
Just one thing, button isn't a valid HTML tag. You'd be better off
using span (unless you're working with the XML DOM of course).
A.
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Tutorial on AHAH (such a cool technology!)
On 2/13/07 4:30 AM, Ara Pehlivanian [EMAIL PROTECTED] wrote:
On 2/12/07, Benjamin West [EMAIL PROTECTED] wrote:
Roger,
Neat stuff. I thought it was pretty good, but take some issue with the
following:
a href=javascript:ahah('Waldorf-Astoria-Photo.html','Photo');photo/a
The best practice is to wire the event up, and to use a button when
the element is not truly a link.
Something more like:
button
onclick=ahah('Waldorf-Astoria-Photo.html','Photo');photo/button
or even better:
button id=photo_changer type=button photo/button
script type=text/javascript
// must be done either after onload fires or after the element appears
in the DOM...
// find the element.
photoButton = document.getElementById('photo_changer');
// wire up the event.
photoButton.onclick = function () {
ahah('Waldorf-Astoria-Photo.html','Photo');
};
/script
-Ben
Just one thing, button isn't a valid HTML tag. You'd be better off
using span (unless you're working with the XML DOM of course).
button is a valid HTML4 tag.
http://www.w3.org/TR/html401/interact/forms.html#h-17.5
Tantek
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Tutorial on AHAH (such a cool technology!)
On 2/13/07, Tantek Çelik [EMAIL PROTECTED] wrote: button is a valid HTML4 tag. http://www.w3.org/TR/html401/interact/forms.html#h-17.5 Tantek Ouch. Having been schooled, Ara crawls ashamedly under a rock to lick his wounds. A. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Tutorial on AHAH (such a cool technology!)
On 2/13/07, Ara Pehlivanian [EMAIL PROTECTED] wrote:
On 2/12/07, Benjamin West [EMAIL PROTECTED] wrote:
Roger,
Neat stuff. I thought it was pretty good, but take some issue with the
following:
a href=javascript:ahah('Waldorf-Astoria-Photo.html','Photo');photo/a
The best practice is to wire the event up, and to use a button when
the element is not truly a link.
How is this not a link?
You can link to a template that takes the data as a parameter:
a href=hotels.php?h=waldorf id=photophoto/a
Then you can use event handling to assign the ahah() function to the
link and hijack the standard behaviour. You could even re-use the
script, add another parameter and get the data back from the same
template in two formats.
This example does that (except for the templating part):
http://beginningjavascript.com/Chapter8/exampleXHR.html
This one even does the templating:
http://beginningjavascript.com/Chapter10/examplePHPXHRgallery.php
This will also make search engines index the detail page. Don't make
things more complicated than they are. Modern scripting allows you to
easily enhance real semantic HTML without having to rely on markup
that only makes sense when scripting is enabled.
cheers
Chris
--
Chris Heilmann
Book: http://www.beginningjavascript.com
Blog: http://www.wait-till-i.com
Writing: http://icant.co.uk/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Microformats and Football
Dear friends, This is my first post to the list, so please forgive me if this is inappropriate. I´m trying to find information about microformats in sports, more specifically football (soccer for the americans). I´m involved in a project that will expose lots of data such as match results, scouts, player information and the like, and could not help but think about using microformats to expose this data. Any suggestions or ideas? Yours thankfully, Danilo Medeiros -Mensagem original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em nome de [EMAIL PROTECTED] Enviada em: terça-feira, 13 de fevereiro de 2007 09:33 Para: microformats-discuss@microformats.org Assunto: microformats-discuss Digest, Vol 21, Issue 28 Send microformats-discuss mailing list submissions to microformats-discuss@microformats.org To subscribe or unsubscribe via the World Wide Web, visit http://microformats.org/mailman/listinfo/microformats-discuss or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of microformats-discuss digest... Today's Topics: 1. Re: SOURCE+URL to indicate authoritative hCard (was UID+URL vs. VIA) (Brian Suda) 2. Re: [advocacy] Contacting Blogger (was Re: [uf-discuss] Rel-tag issues...) (James Craig) 3. RE: Training events in hResume (Steve Ganz) 4. Re: [advocacy] Contacting Blogger (was Re: [uf-discuss] Rel-tag issues...) (Ben Buchanan) 5. Re: SOURCE+URL to indicate authoritative hCard (was UID+URL vs. VIA) (Ryan King) 6. Re: SOURCE+URL to indicate authoritative hCard (was UID+URL vs. VIA) (Scott Reynen) 7. Re: Tutorial on AHAH (such a cool technology!) (Benjamin West) 8. Re: Training events in hResume (Rob Crowther) 9. Re: Tutorial on AHAH (such a cool technology!) (Ara Pehlivanian) -- Message: 1 Date: Mon, 12 Feb 2007 20:49:34 + From: Brian Suda [EMAIL PROTECTED] Subject: Re: [uf-discuss] SOURCE+URL to indicate authoritative hCard (wasUID+URL vs. VIA) To: Microformats Discuss microformats-discuss@microformats.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 2/12/07, Scott Reynen [EMAIL PROTECTED] wrote: On Feb 12, 2007, at 1:05 PM, Ryan King wrote: Has anyone looked at using the SOURCE property from vCard to indicate a more authoritative hCard? It seems to be much closer to what we're talking about than UID. The value is already defined as URI. SOURCE is already used by X2V to indicate the URL at which the current hCard is available. I don't think we'd be able to override that at this point. SOURCE is just the 'source' of where the the hcard came from. 2.1.4 SOURCE Type If the SOURCE type is present, then its value provides information how to find the source for the vCard. -brian -- brian suda http://suda.co.uk -- Message: 2 Date: Mon, 12 Feb 2007 13:25:10 -0800 From: James Craig [EMAIL PROTECTED] Subject: Re: [advocacy] Contacting Blogger (was Re: [uf-discuss] Rel-tag issues...) To: Microformats Discuss microformats-discuss@microformats.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Scott Reynen wrote: This may not solve 100% of issues, but I think Blogger could make over 90% of plain-old web hosts work with the current rel-tag spec by simply uploading tagname/index.html instead of tagname.html and then point links to tagname/ (which resolves to index.html on most plain-old web hosts). The simplest solution is usually the best, eh? Good idea. *slaps forehead* For the record though, I still think there should be markup-only fallback, such as putting the tagName in a title attribute. either a rel=tag href=/search/tag/fooAll uses of FOO/a or a rel=tag title=foo href=/search?tag=fooAll uses of FOO/a -- Message: 3 Date: Mon, 12 Feb 2007 13:53:01 -0800 From: Steve Ganz [EMAIL PROTECTED] Subject: RE: [uf-discuss] Training events in hResume To: 'Microformats Discuss' microformats-discuss@microformats.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII On Sunday, February 11, 2007 6:49 PM Rob Crowther wrote Today I've been working on completing the hResume markup on my CV [1]. I have a section devoted to training courses I've been on and other lectures/presentations I've attended. Can anyone advise, would this be better marked up as 'education', or just plain hCal or perhaps even just use rel-tag, like it's a skill? It seems to me that education is really school and university rather than attending training courses or lectures, but I could be
Re: [uf-discuss] Microformats and Football
On 13/02/07, Danilo Medeiros [EMAIL PROTECTED] wrote: Dear friends, This is my first post to the list, so please forgive me if this is inappropriate. Hi Danilo, welcome to the -discuss list. :) I´m trying to find information about microformats in sports, more specifically football (soccer for the americans). I´m involved in a project that will expose lots of data such as match results, scouts, player information and the like, and could not help but think about using microformats to expose this data. Any suggestions or ideas? Well - the first good step you can take is to gather some information - the kind of think you'd like to publish, then think about what existing microformats will fit with this data. Just off the top of my head, you might think about combining hCard and hReview to describe a player and their abilities (or maybe even hResume for their sporting careers). Then you've got hCalendar for marking up sporting events... So yeah - using microformats to expose this data is probably very suitable and there is likely to be a good foundation already in existance to build something more accurate on to start with. F -- Frances Berriman http://fberriman.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Training events in hResume
Good points. My experience or my perspective must differ from others. I can see how some training events could fall under education, while others are more clearly considered training. Being who I am, training to me is a learning experience. Even on the job training is what I consider kinesthetic and visual learning (as opposed to auditory). There does seem to be a formalized training classification, the question is differentiation. Cheers! Pat On 2/13/07, Rob Crowther [EMAIL PROTECTED] wrote: On 12/02/07, Pat Ramsey [EMAIL PROTECTED] wrote: Training being a learning experience, I would think marking it up as education is appropriate. But work is (or perhaps should be) a 'learning experience' too. It's not quite the same thing, but most application forms I've filled in have had separate sections for Education and Training. -- Pat Ramsey [EMAIL PROTECTED] http://www.southwestern.edu/~ramseyp ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] SOURCE+URL to indicate authoritative hCard (was UID+URL vs. VIA)
On Feb 13, 2007, at 7:32 AM, Scott Reynen wrote: SOURCE in vCard is essentially the same as self in Atom (AFAICT). I think SOURCE is actually closer to VIA in Atom, as the source of the information provided in the containing element, which is why I suggested it. As I understood the arguments between UID+URL and VIA (and I may well have missed some key points), UID+URL is good because it's already in vCard, but bad because not all UIDs point to more authoritative hCards. And VIA is good because the source of information is always more authoritative than the derivative, but bad because it's not already in vCard. So SOURCE+URL seems good because the source of information is always more authoritative than the derivative, and also good because it's already in vCard. This makes a lot of sense to me: when X2V converts an hCard into a vCard, it uses the hCard's location in order to specify a place where the vCard (now offline), can look to update its information. Manually setting SOURCE could changed this behavior. Instead of telling a the vCard-consuming app to check back for more information, it tells it a new location to check back to instead. Because it's already been defined as a semantic equivalent, I'd still like to see @rel=via indicate SOURCE (in much the same way as @rel=tag indicates CATEGORY). The behavior could work as follows: 1. If the hCard contains no links with @rel=via, you're done--set SOURCE to be the URL of the current hCard. 2. If hCard contains a link with @rel=via, download the resource. 3. If the new resource contains one hCard, go to 1. I would also suggest that hCard support only a single source URL. -- Ryan http://RyanCannon.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Football
On 13/02/07, Frances Berriman [EMAIL PROTECTED] wrote: Just off the top of my head, you might think about combining hCard and hReview to describe a player and their abilities (or maybe even hResume for their sporting careers). Both could also apply to teams. Also hCalendar could describe trophies/honours won. The only thing really missing is a way of describing scores. A seperate score for each team, associated with the game itself (which is perhaps hCalendar). Could this be generic enough to support more than just football - eg. Cricket, scores by innings, results like won by an innings and 53 runs or Baseball where the box scores might be required. Or should it be a seperate 'score microformat' for each sport which can then be slotted into a consistent framework? Rob ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Football
On 13/02/07, Rob Crowther [EMAIL PROTECTED] wrote: On 13/02/07, Frances Berriman [EMAIL PROTECTED] wrote: Just off the top of my head, you might think about combining hCard and hReview to describe a player and their abilities (or maybe even hResume for their sporting careers). Both could also apply to teams. Also hCalendar could describe trophies/honours won. The only thing really missing is a way of describing scores. A seperate score for each team, associated with the game itself (which is perhaps hCalendar). Could this be generic enough to support more than just football - eg. Cricket, scores by innings, results like won by an innings and 53 runs or Baseball where the box scores might be required. Or should it be a seperate 'score microformat' for each sport which can then be slotted into a consistent framework? H.. good question. I think score is certainly a beyond the scope of an existing format that I can think of. So, everything else relating to sports aside (I think existing formats cover most aspects), this would be the only part that might need rethinking. I must admit, I'm not a sports fan so my domain knowledge is slight, so I would benefit from seeing a nice range of examples of sporting scores and what the important values are in relation to each other first before ruling out all the existing formats though! -- Frances Berriman http://fberriman.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Football
This looks like a new microformat proposal, which we should start moving to the microformats-new list: http://microformats.org/mailman/listinfo/microformats-new/ Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Training events in hResume
On Feb 13, 2007, at 3:23 AM, Rob Crowther wrote: On 12/02/07, Pat Ramsey [EMAIL PROTECTED] wrote: Training being a learning experience, I would think marking it up as education is appropriate. But work is (or perhaps should be) a 'learning experience' too. It's not quite the same thing, but most application forms I've filled in have had separate sections for Education and Training. A quick google for some examples: 1 - http://www.chichester.gov.uk/your_council/council_jobs/ copy_of_job_appln_form1.cfm (link to Word doc on page) - Has an 'EDUCATION PROFESSIONAL QUALIFICATIONS' section, separate boxes for schooling, professional qualifications and 'other relevant training' but all under the same heading. 2 - http://www.tendringdc.gov.uk/NR/rdonlyres/ E8AE5F2D-4F09-46F7-8044-9A45A924CDCE/0/ApplicationForm130306.pdf - seperate sections for Education and Professional Qualifications 3 - http://www.unison.org.uk/acrobat/B1491.pdf - separate sections for Education and Training, though the distinction is that anything which leads to a qualification is Education, and everything else is Training. This is perhaps a more useful practical distinction than the slightly nebulous concepts I had in mind. 4 - http://www.scope.org.uk/downloads/jobs/jobapp_may05.doc - similar to 3, things with an exam are Education, other things are Training. 5 - http://www.rhul.ac.uk/personnel/application.pdf - similar to 1, all in one section but sperate boxes for School, Further/Higher Education, Formal Qualifications and Other Training 6 - http://www.broxtowe.gov.uk/application_form_april_2006.pdf - Education and Training all in the same box/section. On the basis of the above examples, I would suggest that a distinction between education and training could be useful as clearly employers sometimes see them as distinct concepts. Sometimes is not enough. We're trying to work with the 80 side of the 80/20. I have nothing against improving hResume here, but we shouldn't add features that only a minority of people would use. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] VIA or VIA SELF to indicate authoritative hCard[was:UID URL to indicate (relatively) more authoritativehCard(Was:Vote on this: rel=me self to indicate anauthoritative hCard)]
On Feb 10, 2007, at 3:09 AM, Joe Andrieu wrote: Ryan King wrote: First off, I'm not saying we should constrain UID to be a URL, but in the case that it *is* a URL, we can apply these semantics. And if the uid is not an url, then authors can't assert authority, correct? I'm not even considering authority for now. We need to just deal with related hCards first. Secondly, UID is supposed to be a globally unique identifier, so something like a student id wouldn't qualify. Now if you take those two points together, plus the fact that URLs have a build-in system for distributed, uniform allocation, I think UIDs *should* be URLs. I can't imagine using anything else besides a URL in any useful way. Sure. I understand why uids *should* be urls. But it is not required. Limiting authority to publishers who agree with the spec authors' shouldness is unkind. If uids had to be urls, your argument would be much more compelling. Once again, we should solve the simpler problem of related hCards before we worry about which of a set of related hCards is the most authoritative. Also, I don't see what's unkind about building features that leverage a SHOULD in a spec. Forcing publishers to synchronize uids with urls may make for a more elegant standard, but it doesn't meet the test of humans first, machines second. Seems to me that authors should be able to indicate the source/reference/authoritative hCard without having to use the source url as their uid. I understand that in many cases we'd like to refer to entities that don't have a stable URL. I'm not sure this is the right place to introduce another universal identification scheme. Ryan, I didn't suggest that we introduce new universal identification scheme. I'm sorry if I misunderstood you, but it seemed like you were trying to deal with the problem of referring to hCards without a stable URL by introducing a new scheme. I am saying that we should use some terms from Atom in hCard to that publishers who have their own uid scheme can still assert authority in hCard. I understand, but unless we can first demonstrate that there's nothing in hCard that can help us, there's no reason to look outside it, even to something as well specified as Atom. Forcing the religion of uids should be urls on the rest of the world is not why we are here. I'm not sure why you call it religion. URLs are useful for very practical reasons– it's easy for many people to produce them in such a way that they won't clash and they have the advantage of being dereferencable. Remember, UID signifies the entity that the hCard represents and we're already observed and documented that, in practice, people use URLs to signify other people and companies. This is encoded in XFN and works well in practice. Making it easy for authors to connect their web content and web apps with the semantic web is. If someone else likes uids that aren't urls, and the spec supports that, then why should we keep them from establishing authoritative hCards? Every specification reflects opinions of its editors as to the best way to do things. I think the best UIDs are URLs. If you don't want to make UIDs that aren't URLs, then you'll have to find another way to refer to people and organizations on the web. Before solving the problem of 'canonical' or 'authoritative' hCards, we should solve the problem of 'hcards representing the same person'. Before you can have trust you need identity. Actually, I think authoritative is a simpler, special case of two hCards representing the same person. Trying to solve the general problem of multiple hCards representing the same person is a mess. Consider: school and work directories conference bios online papers and articles and blog comments public records like DMV and the courts youtube, flickr, yahoo, and google accounts In contrast, the if we can simply assert two claims, we have a useful relationship that I have already seen much use for: 1. This (refering) hCard is a stub or abbreviated version of this other source hCard. 2. This (authoritative) hCard is itself the most authoritative reference for this hCard. I don't get your point. Your arguement here assumes that we can figure out when two hCards refer to each other as related, which is the simpler problem I'd like to solve. I think we might be partially agreeing here in a way that isn't very clear. I'm saying that a general way to define relationships between hCards is a harder problem that (a) a specific relationship between two hCards and (b) a unique relationship between an hCard and itself (that is, the assertion that this hCard is itself authoritative). The difference is that we're defining two different kinds of relationships. I want to define the relationship that two hCards represent the same entity, whereas you want to define something more specific. I have another objection to your
Re: [uf-discuss] VIA or VIA SELF to indicate authoritative hCard[was:UID URL to indicate (relatively) more authoritativehCard(Was:Vote on this: rel=me self to indicate anauthoritative hCard)]
On Feb 12, 2007, at 6:36 AM, Ryan Cannon wrote: On Feb 12, 2007, at 8:16 AM, David Janes wrote: a globally unique identifier corresponding to the individual or resource associated with the vCard. (from http://www.ietf.org/rfc/rfc2426.txt) Is RK's UID http://theryanking.com/blog/contact/#vcard or http:// theryanking.com? Each hCard in that chain contains a *different* UID. That's not a globally unique identifier. The *object identifier* of the hCard and the *source document* for the hCard are two semantically different things, and need two different constructs. Actually, it is a globally unique identifier. I'm the only person in the world represented by http://theryanking.com, http:// theryanking.com/contact/ and http://theryanking.com/contact/#vcard. Any hCard that includes these as UIDs represent me. Though each of those represent only me, I obviously have many different URLs on the web that could be treated as my UID. This makes things messy, for sure, but it's how people work on the web already. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] VIA or VIA SELF to indicate authoritative hCard[was:UID URL to indicate (relatively) more authoritativehCard(Was:Vote on this: rel=me self to indicate anauthoritative hCard)]
On Feb 11, 2007, at 6:16 PM, Ryan Cannon wrote: On Feb 10, 2007, at 2:56 PM, Joe Andrieu wrote: Forcing the religion of uids should be urls on the rest of the world is not why we are here. Making it easy for authors to connect their web content and web apps with the semantic web is. If someone else likes uids that aren't urls, and the spec supports that, then why should we keep them from establishing authoritative hCards? ... How is via+via self more constraining? You can do everything you can with uid+url, but you don't have to use URLs for your UIDs. +1 UID+URL *is* more constraining. Like rel-tag, you're forcing a lot of assumptions about the documents *surrounding* these URLs--links have to point somewhere after all. My UID, if you will, is http://ryancannon.com/. I've established it across many different sites as the definitive link for me. By forcing UID+URL to be used to establish an hCard's source, you're also forcing my most robust hCard must exist at that URL. No, we're not. Once again, we're just talking about related-ness, not authority. Also, I don't see why authoritativeness has to also mean completeness. Wouldn't authority be applied on a field-by-field basis? However, when I redesign my home page, if I want to move my contact information to ryancannon.com/contact my UID shouldn't change--it's still just the domain. However, with URL+UID, I'm screwed. With @rel=via, I can still have the option to point to my full hCard. No, you're not screwed. All you have to do is put a minimal hcard on your home page with UID+URL=ryancannon.com/contact. That's it. Also, Ryan, you have yet to address the fact that URL+UID changes the parsing rules of the hCard--not that I believe it is currently ideal. Is it responsible for the community to change the rules of a deployed specification willy-nilly? While the implementation in X2V may be trivial, it may not be in other applications in the wild-- it's also not a good precedence to set for uFs in general. For backwards-compatibility alone, @rel=via seems to me an optimal solution. Yes, this would mean a change in how UIDs are parsed, however the only UID I can find in the wild are URLs. A change wouldn't break anything. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Football
Thank you so much Francis. Sorry about the mess, it's been a while since I've used mail lists :-) One thing that I would like to understand better is how to use or maybe extend an existing microformat. One example: you've mentioned it would be interesting to use hcard for player information. I find the hcard microformat closely tied to the semantic concept of contacts rather than persons, if you will. When I think about what information should be presented about a player it is clear to me that there is no need for the majority of the fields that are part of the specification (e.g. telephone numbers, addresses, postal code, email, aim screennames, etc), while there are other data that must be included (e.g. number of goals, date of birth and death, etc). Should or could I just extend the format by creating new fields and subtypes? I wonder what would the elegant solution be. Cheers ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Football
On 13/02/07, Danilo Medeiros [EMAIL PROTECTED] wrote: ... interesting to use hcard for player information. I find the hcard microformat closely tied to the semantic concept of contacts rather than persons, if you will. When I think about what information should be presented about a player it is clear to me that there is no need for the majority of the fields that are part of the specification ... Should or could I just extend the format by creating new fields and subtypes? I wonder what would the elegant solution be. Well, have a think about what those extra fields are first - they might be in hCard already, but under used. It's true that hCard is geared up to be a fully fledged contact card, but the minimal, only required field, is only ever fn, so it's really quite light if you choose it to be. -- Frances Berriman http://fberriman.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] VIA or VIA SELF to indicate authoritative hCard[was:UID URL to indicate (relatively) more authoritativehCard(Was:Vote on this: rel=me self to indicate anauthoritative hCard)]
On Feb 13, 2007, at 12:32 PM, Ryan King wrote: And if the uid is not an url, then authors can't assert authority, correct? I'm not even considering authority for now. We need to just deal with related hCards first. I'm no longer clear on what you're proposing, Ryan. I thought you were proposing UID+URL as an alternative to VIA, as a way to declare authority through identification rather than through origin. But if you're not considering declaring authority at all, then how does this solve our original problem? On Jan 23, 2007, at 12:22 PM, David Janes wrote: Wouldn't it be great if there was a well defined way of getting from _an_ instance of a hCard to the _best_ (or canonical) hCard for that person. Merely indicating that two hCards are related doesn't tell us which one is best or most authoritative. I see the one explicit relationship as simpler. I'm not understanding what you think is simpler about a general relatedness. Because the explicit relationship isn't helpful. As someone writing a consuming application, I don't care that an author thinks their hCard is definitive for a given entity, just tell me which ones are related and I'll figure out the right data. I think the explicit relationship of authority is central to solving David's problem, a very common practical problem for hCard publishers. Self-declared authority is not helpful, but one hCard declaring another as more authoritative is exactly what we need. There are multiple ways to declare that authority. Origin is one basis of authority, and the VIA and SOURCE suggestions make use of this kind of authority. Identification could be considered another basis of authority, and I earlier thought that's what you were trying to do with UID+URL, but if you just want to know that a bunch of hCards are related and figure out for yourself which one is best, I don't see how that solves David's problem. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Football
I´m trying to find information about microformats in sports, more specifically football (soccer for the americans). I´m involved in a project that will expose lots of data such as match results, scouts, player information and the like, and could not help but think about using microformats to expose this data. Any suggestions or ideas? Personally I think sports scores are a bit too complex for any existing microformat. So I can see a case for a sports results microformat... the problem would be how to make it flexible enough! Each sport reports scores differently, reflecting the way the game is played. eg. Rugby League is generally just reported as a final score, while Aussie Rules football is reported with a progressive total from each of the quarters for goals, behinds and the total points. If a uf was to report AFL as just the final score, fans would not be happy as that's not the data that's considered part of results info. Then you get regional differences even with the same sport, eg. in Australia cricket scores are shown (wickets)/(runs) but elsewhere (runs)/(wickets), so you can't just say 3/7 since it's ambiguous (not counting the fact that some team is having a seriously bad day). All that aside, I think there is definitely some scope for a uf which has a way of capturing: - code/sport eg. Rugby League - teams or players involved - name of series/event, eg. NRL Premiership or World Cup - round of game (ie. the game's place in a series) - date of the game - result (simple who won) - score, which would need the greatest amount of sub-types. possibly the uf should just define an outline, allowing different sports to be marked up according to standard items and self-defined stats. eg. the uf could define how many segments in the game, 2 for halves, 4 for quarters etc. But stuff like tries, tackles, hit-ups, metres gained, etc should go into a definition list that the uf just reads as stats and presents dt/dd combinations. Then there's the different but related item, the all-important ladder. Again, every sport is a bit different; but results ladders do basically come down to a table of team names, rank, competition points, then often an extra stat like points for/points against to rank teams with equal competition points. I do think a uf would be a good idea for moving this information around! Sports results are often syndicated but it's a constant state of reinventing the wheel. It'd also be great if definitive sources could be defined. For example, for the NRL* the official results published at nrl.com.au are pretty much definitive; so it would be great for that information to be discoverable. Just some thoughts anyway. Although it's tongue-in-cheek, have you seen http://www.stuffandnonsense.co.uk/archives/hcup_microformat.html ? :) cheers, Ben [*] Go Broncos! -- --- http://www.200ok.com.au/ --- The future has arrived; it's just not --- evenly distributed. - William Gibson ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Training events in hResume
On 13/02/07, Ryan King [EMAIL PROTECTED] wrote: Sometimes is not enough. We're trying to work with the 80 side of the 80/20. I have nothing against improving hResume here, but we shouldn't add features that only a minority of people would use. Well 83.3% of my examples had some sort of distinction between education at school, qualifications and other types of learning. I realise I wasn't presenting exhaustive research (or even CVs for that matter - but it was information required by organisations doing recruiting), can you suggest how I should go about estimating what percentage of people would find it useful? Rob ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Tutorial on AHAH (such a cool technology!)
Benjamin West wrote:
a href=javascript:ahah('Waldorf-Astoria-
Photo.html','Photo');photo/a
The best practice is to wire the event up, and to use a button
when
the element is not truly a link.
How is this not a link?
You can link to a template that takes the data as a parameter:
a href=hotels.php?h=waldorf id=photophoto/a
The difference, of course, is the first example doesn't have a URI.
Your example does have a URI. If clicking on an anchor element won't
ever take you to a new page (because there is no URI), don't use the
anchor element!
I disagree. You should be practicing accessible, progressive
enhancement. The first example does have a URI, it's the relative
path to Waldorf-Astoria-Photo.html and should be set up to work from
a spider, script disabled browser, or even a right-click to open
link in new tab. Your practice of wiring javascript to a button is
effectively hijacking the user's browser will do nothing except
ensure the content is inaccessible to all but a few targeted user
agents.
a href=Waldorf-Astoria-Photo.html class=ahah-photophoto/a
Works as a regular link and–once the right event handlers are
assigned–will work as a JS-enhanced interface.
James
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Football
Hi there Ben, g'day! I must say I agree with nearly everything you've just said. I was thinking along the same lines, and trying to figure out ways to incorporate current microformats into play (no pun intended). As Frances has gently put, it would be possible to incorporate a lot from the hcard format for players - and maybe complement that with some other data. Maybe the generalization is the way to go, even if it´s not usually the easiest. I am just wondering whether we would be able to keep it micro, as there are so many specific characteristics for each game. That aside, I have to say that your idea looks very promising! I would add some other info: - home/away - venue info - attendance - referee info and maybe a field (or associated hreview item) for a description of the game, maybe a dl for highlights. I´m still finding my way around, so any ideas on next steps would be appreciated. And concerning hcup and Malarkey, that´s just amazing! Actually I have contacted him to ask whether he had any serious work on sports, I thought it was genious! He was the one who brought me here. Thanks a lot, Ben, I miss Oz! Thanks a lot once again Frances. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Tutorial on AHAH (such a cool technology!)
I disagree. You should be practicing accessible, progressive
enhancement.
Agreed, so I don't think we're in disagreement. This was the reason
for my comment.
The first example does have a URI, it's the relative
path to Waldorf-Astoria-Photo.html and should be set up to work from
a spider, script disabled browser, or even a right-click to open
link in new tab.
I'm not sure if people are missing it or what... so here it is again:
---
href=javascript:ahah('Waldorf-Astoria-Photo.html','Photo');
This is a link only browsers with javascript can possibly understand.
My point was that if you don't intend to send the user somewhere, you
shouldn't use an anchor.
Your practice of wiring javascript to a button is
effectively hijacking the user's browser will do nothing except
ensure the content is inaccessible to all but a few targeted user
agents.
Perhaps. Or my suggestion reinforces the concept of using a button
when you don't intend to send your visitors to another page, instead
of a link.
a href=Waldorf-Astoria-Photo.html class=ahah-photophoto/a
I agree this is a better suggestion in this case /if/ the intent is to
provide a fallback to take the user to a new page: something not
possible in the original example. However, the intent to not send the
user to another page isn't something you can fix with progressive
enhancement.
Works as a regular link and–once the right event handlers are
assigned–will work as a JS-enhanced interface.
James
Thanks for pointing out the better solution.
Ben West
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Using the include pattern to indicate the location of more complete hCards
While reading through the mess about authoritative/more complete hCards, I wondered if using/extending the existing include micropattern would be a smart move. @data looks to already be a URI (#j is the URI given in the example on the include-pattern page). Thoughts? -Colin ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
