There are also efforts to make it possible to browser hcard-based
Address Books on Bonjour networks (see Bonsoir --
http://www.tuaw.com/2006/08/28/bonsoir/). If you want any
browsability, as was said, it makes it so much easier to be able to
style hcards on a network than to convert vcf to hcard t
As far as services/crawling go, I would suggest AWSP (Alexa Web Search
Platform). Alexa opens their crawl data for other to sift through so
you don't have to do the crawling. If you are concerned about your
resources' preparedness, consider using Amazon's S3 (simple storage
service) for storage.
On Aug 30, 2006, at 11:21 PM, Timothy Gambell wrote:
Yeah, the semantic markup situation is pretty messy in the museum
world, too. There are some credible efforts to come to some
consensus about how we describe works of art, but I'm not going to
hold my breath.
No kidding. Recently I'v
On Aug 30, 2006, at 7:45 PM, Bruce D'Arcus wrote:
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.
Bruce,
The more I think
On Aug 30, 2006, at 8:29 PM, Michael McCracken wrote:
Is the situation of semantic markup just as bad in the art world as it
seems to be in my area?
Mike,
Yeah, the semantic markup situation is pretty messy in the museum
world, too. There are some credible efforts to come to some consensus
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 a
On 8/30/06, Timothy Gambell <[EMAIL PROTECTED]> wrote:
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 com
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 m
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 li
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/tim
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 h
In message <[EMAIL PROTECTED]>, Drew
McLellan <[EMAIL PROTECTED]> writes
>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
Your site may not be seeing a representation
In message <[EMAIL PROTECTED]>, Alex Mayrhofer <[EMAIL PROTECTED]>
writes
>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.
AIUI, they'r
On 30 Aug 2006, at 19:45, Drew McLellan wrote:
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.
Done.
http://tools.microformatic.com/query/xhtml/best-guess/Rt+Hon+Lord
+Ashdown+KBE
drew.
___
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 stan
For the dtreviewed you have:
March 2006
You probably need to switch that to an 'abbr' element so that the data
is being extracted from the title.
March 2006
-brian
Andy Mabbett wrote:
> In message
> <[EMAIL PROTECTED]>, Brian
> Suda <[EMAIL PROTECTED]> writes
>
>
>> It is not a valid review
I hope y'all have seen this, but this is what I'm referring to when I
talk about dove-tails joints...
Niall Kennedy has posted his resume in Atom:
http://www.niallkennedy.com/blog/archives/2006/01/atom-resume-podcast.html
http://www.niallkennedy.com/about/resume.atom
It's not clear whether he u
On Aug 30, 2006, at 3:10 PM, Don Park wrote:
My initial impression of hListing is that it's too
general for the job (sorry) which reduces some benefits of defining
hJob as
a profile of hListing. But I'll withhold my opinion until work on hJob
proceeds in earnest.
I broke the job listing pag
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
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 informati
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
__
Kevin,
Thanks for the link. My initial impression of hListing is that it's too
general for the job (sorry) which reduces some benefits of defining hJob as
a profile of hListing. But I'll withhold my opinion until work on hJob
proceeds in earnest.
- Don
-Original Message-
From: [EMAIL PRO
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 expl
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 struc
On Aug 30, 2006, at 7:33 AM, Scott Reynen 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://micro
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
>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 des
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
On Aug 30, 2006, at 12:36 AM, Andy Mabbett wrote:
I suppose
isn't allowed?
http://microformats.org/wiki/hcard-faq#nesting-properties
-ryan
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/
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 t
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
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
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
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/
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://microf
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
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 blo
On 8/30/06, Andy Mabbett <[EMAIL PROTECTED]> wrote:
>finnaly, the reviewer hCard is also incorrect:
>Andy Mabbett
>March 2006
>
>you need to nest the class="fn" inside the class="vcard"
>Andy Mabbett
>March 2006
Yuk. How is the latter semantically better than the former? It's just
bloat.
Is yo
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 OpenSe
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].
Regards, etc...
[1] and in fact, since suddenly this is somehow being pinned on me, insane.
On
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
There's no explicit MIME type for hAtom markedup html, excepting of
course "text/html", and of course a html document may be marked up
with several different microformats (othoganally or composited), so a
new MIME type probably isn't the solution.
The reason I think that (2) is needed is:
(a) pr
On Aug 30, 2006, at 12:28 AM, David Janes 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) ind
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-
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. S
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 P
XOXO is definately the way to go. In fact, you suggestion of parseing
'OL XHTML' is exactly what XOXO is! If you use for the XOXO list
(instead of ), then order definately has semantic meaning, most
parsers return elements in order either way. No fear of polluting the
XOXO 'world' -- XOXO bein
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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 structu
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
49 matches
Mail list logo
