Re: [uf-discuss] How's my hReview?
In message [EMAIL PROTECTED], Brian Suda [EMAIL PROTECTED] writes It is not a valid review yet, you are missing a few things. [...] B) create an outer div container. You have a class=photo which is another hReview property - assuming you are actually intending that to be part of the hReview, that needs to be nested inside the class=item as well. div class=hreview div class=item I suppose div class=hreview item isn't allowed? There is no RATING, which is OK that is optional, but IMHO that is kinda the point of a review. That's debatable. Have a look at a decent newspaper's book or theatre reviews. finnaly, the reviewer hCard is also incorrect: p id=creditspan class=reviewer vcard fnAndy Mabbett/spanbr span class=dtreviewed title=200603March 2006/span/p you need to nest the class=fn inside the class=vcard p id=credit class=reviewer vcardspan class=fnAndy Mabbett/spanbr span class=dtreviewed title=200603March 2006/span/p Yuk. How is the latter semantically better than the former? It's just bloat. i hope this helps. Indeed, thank you. If you make those changes let us know and we can take another pass at it and see if there are any other errors. Done, see: http://www.westmidlandbirdclub.com/reviews/WarksBirding2005.htm Mind you, it occurs to me that, while our visitors might make use of hCard and hCalendar items, to add contacts and events to their address book or diary programmes, hReview is of less use, to them. -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] OpenSearch
Currently I use an hAtom+XOXO mix for search results on my pages, but I have found that hAtom works sufficently for most -- I just wasn't sure if this was a 'proper' use of it... but I figure it probably is since you can have RSS for search too... -- Singpolyma On 8/30/06, David Janes [EMAIL PROTECTED] wrote: This looks very possible. In particular, (1) according the article, Yahoo only returns its results in HTML, so we know HTML is good (2) one could add an extra field to the OpenSearch XML (a description file about how your results are returned) indicating that the file is hAtom (3) parties not understanding hAtom can just display HTML (4) parties wating to understand hAtom can do it themselves or use a webservice When I was at MashupCamp in January (Feb?) there was a guy from A9/OpenSearch very interested in mashup type applications and developer feedback so there's a door open for us. I'll also note that his WordPress integration problem will probably go away if we did this, as an independent XML-feed result will not have to be returned; Regards, etc... David http://blogmatrix.blogmatrix.com On 8/30/06, Scott Reynen [EMAIL PROTECTED] wrote: On Aug 29, 2006, at 10:23 PM, Ted Drake wrote: It's slightly off topic, but I thought I'd share my latest post about how we added the OpenSearch protocol to the Yahoo! Tech site. This open protocol lets you define how your web site's search engine works and then activates the personal search box in IE7 and Firefox 2. It also helps the aggregating search engines, such as A9. http://www.last-child.com/add-opensearch-to-your-web-site/ Sorry if it is too off-topic. I'm not sure this is off-topic at all. I think OpenSearch solves a problem by extending RSS that microformats could solve by extending HTML, possibly hAtom specifically. The problem is identifying search results for reuse in aggregation, reformatting, etc. The use cases are obvious as there are plenty of applications that already reuse this type of data and could benefit from a standard format for already published search results (A9, OS X Sherlock, etc.), there's certainly no shortage of search results on the web to use as real- world examples from the general web searches to very narrow-focus searches, and between hAtom and OpenSearch, I suspect most of the work is already done. hSearch? ` Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- - Stephen Paul Weber, Amateur Writer http://www.awriterz.org MSN/GTalk/Jabber: [EMAIL PROTECTED] ICQ/AIM: 103332966 NSA: [EMAIL PROTECTED] BLOG: http://singpolyma-tech.blogspot.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] geo microformat - specification and usage
Hi, i'm investigating the use of geo on one of my sites, and i have two open questions with regards to this: 1) i didn't find what reference system the geo microformat should use. Although i suppose it is WGS84, neither the original vCard specs nor the microformats explicitely mention this. Since differences between various reference systems can be quite significant (up to a few hundred meters), i think it is important to specify this. 2) Are there any search engines which look at the geo microformat? The most popular search engine for that purpose seems to be geourl.org - however, they only index ICBM and geo.position style meta tags. thanks, Alex ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] hJob
Hi all, Given recent moves in the job listing by bloggers, I think 'hJob' and syndication of job data might be a nice near-term topic for discussion. Thoughts? Links to alternate proposals? Don Park ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] OpenSearch
On Aug 30, 2006, at 9:36 AM, David Janes wrote: The reason I think that (2) is needed is: (a) profiles are not manditory, so we can't depend on their presence (b) the search-results consumer, knowing that there is hAtom search results, may want not to read the URL at all (prefering a proxy to do it) (c) there is and will continue to be pages that have HTML but not hAtom So are you proposing an extension to OpenSearch to support hAtom; or that a MIME type is established for hAtom? //Ed ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] OpenSearch
On Aug 30, 2006, at 9:52 AM, David Janes wrote: I'm not sure how to be clearer: my first message in this thread suggests in point (2) add a single-field extension to OpenSearch XML; my second message says adding a MIME type is not the solution [1]. OK, so an extension to OpenSearch since OpenSearch currently uses MIME types to distinguish the type of a response. IMHO this is undesirable since it essentially makes opensearch treat microformats (hAtom) as a special case. But maybe I've got something wrong here with my understanding of OpenSearch. I just pinged people over on opensearch-discuss [1] to take a look at this thread so maybe more light is available. //Ed [1] http://opensearch.org/pipermail/discuss/2006-August/57.html ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] How's my hReview?
On 8/30/06, Andy Mabbett [EMAIL PROTECTED] wrote: finnaly, the reviewer hCard is also incorrect: p id=creditspan class=reviewer vcard fnAndy Mabbett/spanbr span class=dtreviewed title=200603March 2006/span/p you need to nest the class=fn inside the class=vcard p id=credit class=reviewer vcardspan class=fnAndy Mabbett/spanbr span class=dtreviewed title=200603March 2006/span/p Yuk. How is the latter semantically better than the former? It's just bloat. Is your name really Andy Mabbett March 2006? - David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] OpenSearch
On Aug 29, 2006, at 11:28 PM, David Janes wrote: (2) one could add an extra field to the OpenSearch XML (a description file about how your results are returned) indicating that the file is hAtom There are two problems here, and I think we should avoid approaching both at once. Just as a blog description was tabled until after hAtom, I think a search results description should be tabled until after there are microformat search results to be described. How exactly is Yahoo indicating which HTML is search results? That's not part of the OpenSearch standard as I'm reading it, and I don't see anything equivalent to OpenSearch's RSS and Atom syntaxes in Yahoo's HTML. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] OpenSearch
more light: http://wiki.unto.net/OpenSearch_and_microformats //Ed ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hJob
On Aug 30, 2006, at 8:21 AM, Don Park wrote: Given recent moves in the job listing by bloggers, I think 'hJob' and syndication of job data might be a nice near-term topic for discussion. Thoughts? Links to alternate proposals? http://microformats.org/wiki/job-listing-examples http://microformats.org/wiki/job-listing-brainstorming I started working on this when I first joined this list, but I didn't really know what I was doing and no one else seemed very interested, so I didn't get very far. I think there are probably sufficient examples collected, but if you think there should be more, add them. The next step seems to be determining the implied schema by looking at which properties meet the 80% threshold. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hJob
I was going to suggest the same thing, so it's good to see this work already underway. My post is a bit dramatic, but what's important about the current research on this is that it could be used by either applicant *or* job provider. http://factoryjoe.com/blog/2006/08/30/jobs-jobs-and-more-jobs/ Just as I can post my own hResume, being able to post jobs descriptions that I think I'd be good at is an equally important design goal for this mF. I also think that it's design, perhaps a slight break with convention, should creatively tackle the issue of helping folks get work that they love to do. That's the beauty of distribution and decentralization. You no longer have to fit into someone else's job description, you can write one for the work that you want to do! Chris On 8/30/06, Scott Reynen [EMAIL PROTECTED] wrote: On Aug 30, 2006, at 8:21 AM, Don Park wrote: Given recent moves in the job listing by bloggers, I think 'hJob' and syndication of job data might be a nice near-term topic for discussion. Thoughts? Links to alternate proposals? http://microformats.org/wiki/job-listing-examples http://microformats.org/wiki/job-listing-brainstorming I started working on this when I first joined this list, but I didn't really know what I was doing and no one else seemed very interested, so I didn't get very far. I think there are probably sufficient examples collected, but if you think there should be more, add them. The next step seems to be determining the implied schema by looking at which properties meet the 80% threshold. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- Chris Messina Agent Provocateur, Citizen Agency Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] OpenSearch
I'm not sure if I understand the theory behind the twiki of OpenSearch and Microformats. Are you suggesting I modify the opensearch.xml file to include microformat values, so that when A9 and other search engines gather the content, they can insert the microformat into their results? A9 does not support HTML search pages at this time. I tried to register our OpenSearch with them and the response was that they only accept RSS and atom at this time. I haven't looked at hAtom yet. If I can add some microformatting to our search results, I'd be happy to try it. This is a sample product result from the search result page. Where would the OpenSearch/hAtom microformats be added? div class=product id=prod8 div class=prodTitle h4a href=/pr/apple-ipod-shuffle-512mb-mp3-player/1991675140 Apple iPod shuffle 512MB MP3 Player/a/h4 div class=ytcompareProductCheck label class=compareLabel for=a1991675140Select this product to be compared with others/labelinput class=ytcompProdCheckBox name=id id=a1991675140 value=1991675140 type=checkbox /div /div div class=ytImgThumbContainera href=/pr/apple-ipod-shuffle-512mb-mp3-player/1991675140 class=ytprodThumbLinkimg class=prodThumb src=http://f3c.yahoofs.com/shopping/mcid2_17104/simg_t_tcatalog_l_t19916751 401105478782jpg85?rm_Dy10zfXDq alt=/a/div div class=ytRatingsContainer ul class=ytratingsul li class=overall stars8 span title=Yahoo! Users gave this product 4.19 out of 5 stars for overall quality4.19/5 /spanb class=ytuserRatings559img src=/images/userratings.jpg alt=this product has user ratings/b /li li class=ytSpecInstalled Memory: 512 MB/li li class=ytSpecAudio Format: AAC, AIFF, MP3, WAV/li li class=ytSpecSystem Compatibility: Mac, PC/li /ul/div divul class=priceInfo li class=ytPrice span class=priceLow$66.49/span - span class=priceHigh$74.05/span in 6 stores/li li class=pricebuttona href=/pp/1991675140 class=ytbtncomppricesCompare Prices/a/li /ul /div Thanks for your help, I'd love to extend the OpenSearch and Microformatting as much as possible. Ted -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Edward Summers Sent: Wednesday, August 30, 2006 7:22 AM To: Microformats Discuss Subject: Re: [uf-discuss] OpenSearch more light: http://wiki.unto.net/OpenSearch_and_microformats //Ed ___ 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] hJob
On Aug 30, 2006, at 10:33 AM, Chris Messina wrote: Just as I can post my own hResume, being able to post jobs descriptions that I think I'd be good at is an equally important design goal for this mF. I also think that it's design, perhaps a slight break with convention, should creatively tackle the issue of helping folks get work that they love to do. Isn't such a break with convention explicitly an anti-goal of microformats? I hope marking up job listings in a standard format will lead to better tools for job seekers, but to whatever extent descriptions of desired jobs and descriptions of existing jobs differ, I think we should be focused on what people are currently publishing on the web, which I expect is almost entirely descriptions of /existing and available/ jobs. If I'm missing descriptions of desired jobs on the current web, I hope someone will add appropriate examples to the wiki, but we shouldn't be building a microformat around hypothetical publishing. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation: next steps?
Bruce, thanks for clearing that up.
On 8/29/06, Bruce D'Arcus [EMAIL PROTECTED] wrote:
Mike,
On 8/29/06, Michael McCracken [EMAIL PROTECTED] wrote:
Do you just mean the ability to mark up a relation between two citation items?
For instance, if BibTeX had a convention of things like this:
@inbook{chapterkey,
title=chapter 1,
cites=articlekey,article2key,...,
partof=bookkey}
[... snip ...]
Would you consider that relational? That kind of thing fulfills what I
think you want, but I'd like to know if you're talking about something
else too.
Yes, I'd frankly forgotten about macros, but they achieve the same
thing I am after.
I think you might actually be thinking of crossref here, not bibtex macros.
Macros are just string substitution - they do this:
@string{acm = Association for Computing Machinery}
@misc{k, title=t, publisher= acm}
(note the lack of quotes around acm)
while crossref allows (single) inheritance of fields from one item to another:
@book{k1, editor= foo, title = book}
@inbook{k2, author=bar, chaptertitle = chapter, crossref=k1}
then the chapter item 'k2' is typset with title=book and chaptertitle=chapter.
I was more referring to the standard BibTeX fields, where you end up
with stuff like:
journal=ABC Journal
...or:
book=Book Title
This is what I object to as a basis for hCite. It effectively means
that whenever you need to support a new kind of resource, you need to
invent a new field name to describe the same thing: a related title.
OK, I understand. And I agree it's a bad thing - I am expecting the
microformat to deal with this by nesting items, but in a slightly
different way from what either you or Brian just mentioned. Here is
what I was expecting:
div class=hcite
span class=titleChapter Title/span
div class=hcite container
span class=titleBook Title/span
/div
/div
I like this option because we aren't requiring a type, we don't need
to define enumerated lists of properties, and it's still clear what
the association is.
We could try the following for the optional type element:
div class=hcite
span class=typeBook Chapter/span
span class=titleChapter Title/span
div class=hcite container
span class=titleBook Title/span
/div
/div
And although it looks a little awkward, it works. I'm not sure this is
the best way to do it, but I do think that types should be available,
but optional.
As for what happens if the type isn't in there in this case, I suspect
that most citation formatting solutions would still generate something
reasonable from this data because it is clear it is something
contained by something, and there's a decent chance of finding a good
default for that.
BTW, I used title here because 'fn' just seems awkward for a title,
but I'm not very concerned about it.
ISTR that you've also described BibTeX's model as flat because author
names in BibTeX are somewhat underspecified, but since a citation
microformat will use hCard, that's not an issue here, right?
Right. I think hCard is nice improvement on the BibTeX contributor
representation.
In terms of modular I am referring to the fact that there is very
little that is specific to citation metadata. Properties like title,
subject, format, etc. can be used to describe a whole range of content
beyond citations.
It therefore seems to be more sensible -- both generally, as well as
WRT to microformat practice -- to isolate the general pieces and give
them a name (like, for example, hDC), and end up with an hCite format
that mostly borrows from those more general formats (hDC, hCard, and
maybe hCal).
But this is less of a concern for me. It wouldn't be the end of the
world for others to borrow from hCite.
I agree, it seems like microformat practice would have us borrow as
much as possible from elsewhere. I think modular is a pretty
overloaded term, and I was thinking in terms of software modularity,
which didn't make a lot of sense.
I'm not convinced that a formalized Dublin Core microformat class set
is necessary for a good citation microformat, and I do think it'd be a
distraction to getting the main goal completed.
I'd like to see a citation microformat use hCard for people,
certainly. The more rich information we get about people from a
citation, the better.
As for using hCalendar, I think that would be great to mark up
conferences, meetings, etc, in citations, but I don't think a citation
microformat should *require* it. According to the hcard-authoring wiki
page, a minimal hCalendar requires a summary, start date and end date
or duration. I almost never see end dates or durations being published
for citations in current practice, and I think requiring a valid
hCalendar would make it harder for publishers to adopt the citation
microformat.
-mike
--
Michael McCracken
UCSD CSE PhD Candidate
research: http://www.cse.ucsd.edu/~mmccrack/
misc: http://michael-mccracken.net/wp/
___
microformats-discuss mailing list
Re: [uf-discuss] How's my hReview?
On Aug 30, 2006, at 12:36 AM, Andy Mabbett wrote: I suppose div class=hreview item isn't allowed? http://microformats.org/wiki/hcard-faq#nesting-properties -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: hJob
I agree with both of you; and I'm also a big supporter of codifying existing practices. At the same time, and this may be anathema to the discussion, but the design of a data format inherently reveals the underlying politics and biases of the designers. I'm only suggesting that we make sure that any work done on hJob be bilateral in nature -- that it codifies job publishing practices, while at the same time, as you said, not close doors. A question, perhaps: could we design hJob such that it could form a dovetail joint of sorts with hResume? That is, with any given hResume or hJob could I find a corresponding set of values that might match the original query as expressed in either format? Chris On 8/30/06, Don Park [EMAIL PROTECTED] wrote: Thanks for the links Scott. Good stuff. Chris, I have to agree with Scott re your 'slight break with convention' suggestion. Like you, I have thought about reusing hJob for query/criteria but I think the idea adds non-trivial constraints without offering sufficient immediate term rewards. However, I think a general effort should be made by this group to investigate general conventions for reusing existing microformats for query/criteria specification so that we don't close doors unknowningly or unnecessarily when we design new microformats. - Don -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Reynen Sent: Wednesday, August 30, 2006 9:52 AM To: Microformats Discuss Subject: Re: [uf-discuss] hJob On Aug 30, 2006, at 10:33 AM, Chris Messina wrote: Just as I can post my own hResume, being able to post jobs descriptions that I think I'd be good at is an equally important design goal for this mF. I also think that it's design, perhaps a slight break with convention, should creatively tackle the issue of helping folks get work that they love to do. Isn't such a break with convention explicitly an anti-goal of microformats? I hope marking up job listings in a standard format will lead to better tools for job seekers, but to whatever extent descriptions of desired jobs and descriptions of existing jobs differ, I think we should be focused on what people are currently publishing on the web, which I expect is almost entirely descriptions of /existing and available/ jobs. If I'm missing descriptions of desired jobs on the current web, I hope someone will add appropriate examples to the wiki, but we shouldn't be building a microformat around hypothetical publishing. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- Chris Messina Agent Provocateur, Citizen Agency Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Re: hJob
A question, perhaps: could we design hJob such that it could form a dovetail joint of sorts with hResume? That is, with any given hResume or hJob could I find a corresponding set of values that might match the original query as expressed in either format? Perhaps. :-) I tend to favor emergent designs that allow practitioners to extend/abuse as needed as adoption spreads. If the need is clearly present, I am for supporting it by design. If not, I am for going just far enough to ensure such use cases are not impossible. Anyhow, let's get our roster of interested parties filled first before we start arguing. ;-p - Don -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Messina Sent: Wednesday, August 30, 2006 11:02 AM To: Microformats Discuss Subject: [uf-discuss] Re: hJob I agree with both of you; and I'm also a big supporter of codifying existing practices. At the same time, and this may be anathema to the discussion, but the design of a data format inherently reveals the underlying politics and biases of the designers. I'm only suggesting that we make sure that any work done on hJob be bilateral in nature -- that it codifies job publishing practices, while at the same time, as you said, not close doors. A question, perhaps: could we design hJob such that it could form a dovetail joint of sorts with hResume? That is, with any given hResume or hJob could I find a corresponding set of values that might match the original query as expressed in either format? Chris On 8/30/06, Don Park [EMAIL PROTECTED] wrote: Thanks for the links Scott. Good stuff. Chris, I have to agree with Scott re your 'slight break with convention' suggestion. Like you, I have thought about reusing hJob for query/criteria but I think the idea adds non-trivial constraints without offering sufficient immediate term rewards. However, I think a general effort should be made by this group to investigate general conventions for reusing existing microformats for query/criteria specification so that we don't close doors unknowningly or unnecessarily when we design new microformats. - Don -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Reynen Sent: Wednesday, August 30, 2006 9:52 AM To: Microformats Discuss Subject: Re: [uf-discuss] hJob On Aug 30, 2006, at 10:33 AM, Chris Messina wrote: Just as I can post my own hResume, being able to post jobs descriptions that I think I'd be good at is an equally important design goal for this mF. I also think that it's design, perhaps a slight break with convention, should creatively tackle the issue of helping folks get work that they love to do. Isn't such a break with convention explicitly an anti-goal of microformats? I hope marking up job listings in a standard format will lead to better tools for job seekers, but to whatever extent descriptions of desired jobs and descriptions of existing jobs differ, I think we should be focused on what people are currently publishing on the web, which I expect is almost entirely descriptions of /existing and available/ jobs. If I'm missing descriptions of desired jobs on the current web, I hope someone will add appropriate examples to the wiki, but we shouldn't be building a microformat around hypothetical publishing. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- Chris Messina Agent Provocateur, Citizen Agency Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation: next steps?
On 8/30/06, Michael McCracken [EMAIL PROTECTED] wrote: [... snip ...] I'm not convinced that a formalized Dublin Core microformat class set is necessary for a good citation microformat, and I do think it'd be a distraction to getting the main goal completed. A reasonable argument; I have no problem with that. As for using hCalendar, I think that would be great to mark up conferences, meetings, etc, in citations, but I don't think a citation microformat should *require* it. According to the hcard-authoring wiki page, a minimal hCalendar requires a summary, start date and end date or duration. I almost never see end dates or durations being published for citations in current practice, and I think requiring a valid hCalendar would make it harder for publishers to adopt the citation microformat. Maybe the duration requirement can be dropped? In any case, conferences and hearings and such have titles, dates (usually contiguous start/end but soemtimes not), and usually sponsors. Bruce ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] vcard fn for name in A. B. Smith format
On 30 Aug 2006, at 13:29, Graham Higgins wrote: On 29 Aug 2006, at 15:42, Brian S wrote: you shouldn't make assumptions about what the 'A.' and 'B.' mean... i did in my example (otherwise it would have been a pretty boring reply). There is a service which attempts at guessing the N structure.[1] It isn't perfect, but does fairly well. [1] - http://tools.microformatic.com/help/xhtml/best-guess/ Sorry, I'm having a little difficulty reading between the lines, is this another troll along the lines of the first one? Because, http://tools.microformatic.com/query/xhtml/best-guess/Rt+Hon+Lord +Ashdown+KBE is parsed as: span class=n span class=given-nameRt/span span class=additional-nameHon/span span class=additional-nameLord/span span class=additional-nameAshdown/span span class=family-nameKBE/span /span It's tempting to respond with a facetious: bong thank you for playing, next contestant please. But if I did that, I suspect that I'd be missing some subtle point. Are you perhaps prompting us to conjecture that a successful parse is impossible without a rich set of semantics? You're right in that best-guess isn't currently picking up multiple honourary prefixes and suffixes. As soon as I see any real quantity of real-life names of such a pattern come through the service, then yes, I'll add that support. At the moment it seems so edge-case that it's not worth the effort. Additionally, the list of prefixes and suffixes I'm matching against isn't fully comprehensive. I clearly don't have KBE in the list. I shall add it. Ultimately, best-guess is attempting to do just that - make the best guess it can with the information available. It's never going to be perfect, it'll probably never work well for non-western names, but it should always return something that can be used as a *valid* value for 'fn', even if that value isn't 100% accurate. However, the rate of accuracy is pretty good, so it's up to you to weigh up whether to use its guesses, process all your names by hand or omit hCards entirely for your individual set of data. drew ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] OpenSearch
On Aug 30, 2006, at 10:43 AM, Ted Drake wrote: This is a sample product result from the search result page. Where would the OpenSearch/hAtom microformats be added? For the results section, you'd just be adding hAtom to the results, which someone more involved with hAtom would probably explain better than I. But to make an HTML version of OpenSearch, you'd also need to identify that those hAtom entries are search results part of a larger set. A quick one-to-one mapping of OpenSearch to HTML looks something like this: pResults span class=start-index21/span to 30 of span class=total-results423/span, span class=per-page10/ span per page./p input type=text class=search-terms value=New York History / That's taken from the example here: http://opensearch.a9.com/spec/1.1/response/#rss That's a slightly different format of information that can be inferred, but is not explicitly published on Yahoo! Tech. For example, I can see there are ten results per page, but that's not stated anywhere. And I can assume that page one starts at an index of 1, and page 2 at an index of 11, but that's also not published currently. The total results and search terms are already published, so they would just need class names to match the OpenSearch properties. And the difference between Yahoo's HTML and the OpenSearch properties (e.g. page vs. index, stated per-page vs. unstated) would need to be worked out through collecting more examples and seeing which is more representative of the implied schema for search results across the web. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] hCard vs. vcf
I am looking for some ammunition on making the case for using hCard over a standard .vcf file exported from Outlook for a static contact listing that will likely not change anytime in the future. -- jeremy flint www.jeremyflint.com www.kineticcom.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard vs. vcf
Once you have the page marked-up you can easily convert it to ANY format, not just vCards. You can also submit the page to sources like kicthen.technorati.com and aggregate the data. It can more-easily be mashed-up with other data. -brian Jeremy Flint wrote: Well, we ended up not using a standard address output on the actual page. I had moved it all to a seperate page and just passed that to technorati. Then got the why not just use this vcf file line. - jeremy On 8/30/06, Ryan King [EMAIL PROTECTED] wrote: On Aug 30, 2006, at 1:17 PM, Jeremy Flint wrote: I am looking for some ammunition on making the case for using hCard over a standard .vcf file exported from Outlook for a static contact listing that will likely not change anytime in the future. You're gonna do an HTML version of the information anyway, right? Do it with hCard, then say look we get vcard for free (http:// feeds.technorati.com/contacts/your url) -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation: next steps?
On 8/30/06 11:29 AM, Bruce D'Arcus [EMAIL PROTECTED] wrote: As for using hCalendar, I think that would be great to mark up conferences, meetings, etc, in citations, but I don't think a citation microformat should *require* it. According to the hcard-authoring wiki page, a minimal hCalendar requires a summary, start date and end date or duration. I almost never see end dates or durations being published for citations in current practice, and I think requiring a valid hCalendar would make it harder for publishers to adopt the citation microformat. Maybe the duration requirement can be dropped? This seems both reasonable, and reflective of existing practice in event listings (and even hCalendar usage in the wild). Many hCalendar events in the wild that I have seen (anecdotal) lack dtend/duration. Most seem to have summary, dtstart, url. Would it be useful to come up with implied durations for this case? In any case, conferences and hearings and such have titles, dates (usually contiguous start/end but soemtimes not), and usually sponsors. Yes. I think this could make a lot of sense, plus it affords the opportunity (and natural tendency?) to link to a page which more thoroughly describes the conference/hearing, more and more of which actually do have their own event pages if not whole sites. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hJob
Le 30 août 06 à 22:21, Don Park a écrit : Given recent moves in the job listing by bloggers, I think 'hJob' and syndication of job data might be a nice near-term topic for discussion. Thoughts? Links to alternate proposals? For inspiration http://vocab.org/bio/0.1/ http://simile.mit.edu/timeline/ http://www.la-grange.net/2006/07/hiring-timeline/ (draft - not finished) -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool *** ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation: next steps?
On Aug 30, 2006, at 12:42 PM, Michael McCracken wrote: I'm not convinced that a formalized Dublin Core microformat class set is necessary for a good citation microformat, and I do think it'd be a distraction to getting the main goal completed. A modular system with hDC broken out does seem a little complex. I'm happy to borrow from hCite, and I'd hope that hCite would be designed to have pieces reused. I say that because I'm interested in using hCite to describe works of art. From my point of view, class names based on DC's very general terms seem like a good choice, class names based on a medium specific citation format like BibTeX seem less good. For example, BibTeX's author field implies the medium of the cited work (if it has an author, it must be text). This makes it difficult to reuse terminology: what if I'm talking about something that had a painter, not an author? Using a more general term, like DC's creator get's the same work done, and is more easily reused: it can be applied to text, paintings, websites, and so on. It would be great, then, if hCite were to be a superset of DC, using more medium specific terms from something like BibTeX only when no adequate alternative existed in DC. This way we sidestep the distraction of creating a DC format, but get the benefit of generic terms in the larger microformats class name pool. Thanks, Tim ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation: next steps?
On 8/30/06, Bruce D'Arcus [EMAIL PROTECTED] wrote: On 8/30/06, Timothy Gambell [EMAIL PROTECTED] wrote: For example, BibTeX's author field implies the medium of the cited work (if it has an author, it must be text). This makes it difficult to reuse terminology: what if I'm talking about something that had a painter, not an author? Using a more general term, like DC's creator get's the same work done, and is more easily reused: it can be applied to text, paintings, websites, and so on. I agree. I'd use creator and then also add author, editor and translator, since those three are widely used in citations, and it's important at least to distinguish the latter two (non-creator) roles from creator/author. In fact, I'd be fine with dropping author altogether; it's not strictly necessary. Yes, I think 'creator' covers 'author' and 'painter' (and 'vocalist', 'sculptor', 'singer', etc) perfectly well, and seems like this might be a useful tradeoff between being able to describe a variety of things without an explosion of class names and actually following the current practices on the web. Current practice seems to overwhelmingly use 'author' - every example we have uses 'author' except for the Oxford U. Press (USA), using 'byline'. So we may need more examples :) I think that given that tradeoff, the set of 'creator', 'editor', and 'translator' are reasonable 80% (probably 90%) choices. We need something like 'editor', and IMO, DC's 'contributor' is way too vague to be useful in comparison. Furthermore, I think none of those should be required, since I commonly see things with no author/editor/etc... Thanks, -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
