Re: [uf-discuss] Optimus — microformats parser
Hi Dmitry,
That looks like a very useful and powerful tool. Thanks!
In testing JSON-P output, I'm getting the error "d.getTimeZoneOffset
is not a function". Here is the fragment of JSON which is causing
the issue:
"published": (function(){var d = new Date(2007, 8, 18, 1, 11, 28,
0);d.setMinutes(d.getMinutes() + (d.getTimeZoneOffset() - (-0)));
return d;})()
I'm using Firefox 2.0.0.6.
Besides that, this thing is great! Thanks again,
-- Jim R. Wilson (jimbojw)
On 9/18/07, Dmitry Baranovskiy <[EMAIL PROTECTED]> wrote:
> Hello everyone,
> Inspired by Brian's X2V[1] and Drew's presentation "Can Your Website
> be Your API?"[2] I wrote µf parser that transforms any microformatted
> web page to XML or JSON. It could be used as an API to any web site
> with microformats. I hope now we could see some µf based mashups.
>
> Characteristics at glance:
> Supported formats: hCalendar, hCard, hAtom, hResume, hReview,
> xFolkentry, adr, geo, xfn, votelinks, rel-nofollow, rel-tag,
> rel-license
> Output formats: XML, JSON, JSON-P
> URL:http://microformatique.com/optimus/
> Query parameters: uri — URI of the resource
> format — output format ("xml" or "json",
> default is "xml") [optional]
> function — name of call back function for
> JSON [optional]
> filter — space separated names of microformats
> (default is "vevent vcard
> hfeed hresume hreview
> xfolkentry adr geo xfn
> votelinks rel-nofollow rel-tag
> rel-license") [optional]
> Examples:
> http://microformatique.com/optimus/?uri=http://ma.gnolia.com/people/drewm/tags/microformats
> http://microformatique.com/optimus/?uri=http://corkd.com/wine/view/1122&format=json
> http://microformatique.com/optimus/?uri=http://johnfallsopp.com&format=json&function=Back
>
>
> I happy to hear any feedback, good (on-list) or bad (off-list) :)
>
> 1. http://suda.co.uk/projects/X2V/
> 2. http://allinthehead.com/retro/301/can-your-website-be-your-api
>
> --
> Best regards,
> Dmitry Baranovskiy
> http://dmitry.baranovskiy.com
>
> ___
> 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] Optimus — microformats parse r
I've fixed it. Little mistype. Correct is getTimezoneOffset. Small “z”. Thank you for feedback. On 19/09/2007, at 3:30 PM, Jim Wilson wrote: In testing JSON-P output, I'm getting the error "d.getTimeZoneOffset is not a function". ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Optimus — microformats parser
Hello everyone,
Inspired by Brian's X2V[1] and Drew's presentation "Can Your Website
be Your API?"[2] I wrote µf parser that transforms any microformatted
web page to XML or JSON. It could be used as an API to any web site
with microformats. I hope now we could see some µf based mashups.
Characteristics at glance:
Supported formats: hCalendar, hCard, hAtom, hResume, hReview,
xFolkentry, adr, geo, xfn, votelinks, rel-nofollow, rel-tag,
rel-license
Output formats: XML, JSON, JSON-P
URL:http://microformatique.com/optimus/
Query parameters: uri — URI of the resource
format — output format ("xml" or "json",
default is "xml") [optional]
function — name of call back function for JSON
[optional]
filter — space separated names of microformats
(default is "vevent vcard hfeed
hresume hreview
xfolkentry adr geo xfn
votelinks rel-nofollow rel-tag
rel-license") [optional]
Examples:
http://microformatique.com/optimus/?uri=http://ma.gnolia.com/people/drewm/tags/microformats
http://microformatique.com/optimus/?uri=http://corkd.com/wine/view/1122&format=json
http://microformatique.com/optimus/?uri=http://johnfallsopp.com&format=json&function=Back
I happy to hear any feedback, good (on-list) or bad (off-list) :)
1. http://suda.co.uk/projects/X2V/
2. http://allinthehead.com/retro/301/can-your-website-be-your-api
--
Best regards,
Dmitry Baranovskiy
http://dmitry.baranovskiy.com
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Storing Microformats
On 9/18/07, ken <[EMAIL PROTECTED]> wrote: > > The problem with *not* storing the original markup is that, if there are > changes in the "standards" (which it seems there certainly will be), you > won't know which of your data need to be changed. > If there are changes in standards/conventions, then you'd probably want to re-scan the originals in any case. Caching the originals may or may not be a good optimization strategy, but the basic idea is that the semantic content is what's important. If I were doing an experiment along these lines (as opposed to, say, writing a whole-Internet scale production system) I'd either: a) Have some fun and check out an RDF data store. Flexible, fun, and lots of relatively unproven (and therefore interesting) technology. b) Be super corporate about it and come up with a relational schema that matched the _semantics_ (not the markup) of each microformat, then publish the schema to the group for others to use. Kinda brittle in the face of standards changes, but it should be clear how to proceed and people would probably find the research useful. (a) is one fairly likely future, (b) is clearly the present, and it all sounds like an enjoyable way to spend some free time. If you're doing a real, live, highly scalable production system, then never mind the above, you've got a whole different set of problems :-) -cks -- Christopher St. John http://artofsystems.blogspot.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Storing Microformats
On 9/17/07, Tom Morris <[EMAIL PROTECTED]> wrote: > On 9/17/07, Paul Kinlan <[EMAIL PROTECTED]> wrote: > > One of the other ideas that I am toying with is a Microformat spider, > > that crawls the web looking for microformats, storing them and then > > allowing them to be searched. My question is: How are people storing > > the data present in microformats so that they can be searched and > > maintained and consumed in applications etc? > > > > Another possible approach is to use an RDF triple store. You can then > use the GRDDL transformation standard to extract RDF data out of > microformats (they exist for a fair few microformats), then store that > data in a triple store. +1 IMHO RDF makes a lot of sense here! ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Correct way to use the "key" property of hCard
On 9/18/07, Philip Tellis <[EMAIL PROTECTED]> wrote: > What do others think? Is this possibly a case where hCard needs to > deviate slightly from the vCard specification while still staying > reasonably close to the spec? --- probably the best next step, is to see how consuming applications handle this. In the vCard spec PHOTO can be a URL, but no desktop application i know honors that URL. How do PIMs like Outlook handle KEYs? can they reference by URL or do they need the binary data, or do they do anything at all? There is a wiki page which lists issues with various PIM applications, please document anything there. http://microformats.org/wiki/vcard-implementations -brian -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Correct way to use the "key" property of hCard
On 9/18/07, Philip Tellis <[EMAIL PROTECTED]> wrote: > What do others think? Is this possibly a case where hCard needs to > deviate slightly from the vCard specification while still staying > reasonably close to the spec? Possibly some sort of usage of OBJECT would be appropriate? My public key id is http://pgpkeys.mit.edu:11371/pks/lookup?op=vindex&search=0x1F140E17";>1F14 0E17 Maybe with an appropriate @rel? -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Correct way to use the "key" property of hCard
On 18/09/2007, Scott Reynen <[EMAIL PROTECTED]> wrote: > value formatting is already established [1]. I don't think you can > merely reference a URL which contains the key; as I read the spec, > you'd need to include the key itself in the vCard, so you'll need to > do the same in the hCard. This may be a good place to use , So there are two reasons I don't like putting the whole key into the hCard. The first is because of the page weight. It doesn't make sense to have such a large chunk of text stored in a document but never displayed to the user. No user would ever read and make sense of the full text of a public key, because that information is specifically targetted at machines. The key ID is a human readable view of a PGP key, so it makes sense to only make that available for humans to read. Secondly, is the problem of revoking keys. If, for any reason, one needs to revoke a key and create a new one, having the full text of your key all over the place becomes a management nightmare. You'd have to go and update all locations. Providing a link, however, means that anyone clicking on the link can see at once that the key has been revoked, and the same page could possibly be updated to redirect readers to a new key. Yes, you'd still have the headache of updating the key ID in all pages that reference it, but you don't have the problem of pages holding the full text of a revoked key. What do others think? Is this possibly a case where hCard needs to deviate slightly from the vCard specification while still staying reasonably close to the spec? Philip ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Storing Microformats
The problem with *not* storing the original markup is that, if there are changes in the "standards" (which it seems there certainly will be), you won't know which of your data need to be changed. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
