Links and titles, that’s all
Because sometimes, the only way to clear out a dangerous number of tabs is just to take a linkdump:
- The National Map Seamless Data Distribution System
- Do Blogs Spam Google Results? – Microdoc News
- Simon Willison: Learn to search!
- LaughingMeme – Googlespamming
- BillSaysThis – Scrape my jus, baby!
- Antipixel | Philosophies of Life
- doron’s blaahg: Googlize your Mozilla
- Quixotic Pixels: Tutorial for Creating a Photoblog
- DrikoLand – Favorite Mozilla/Firebird Extensions
- RDFWeb and Friend of a Friend (FOAF): Missing isn’t broken: data validation and freedom on the Semantic Web
- RDFWeb and Friend of a Friend (FOAF): Pages about people
- 7-Zip
- Feedsterize Yourself or “Your New Feedster Buttons Have Arrived”
- RSS Explorer – Internet Explorer RSS Helper Toolbar
- XML.com: RDF: Ready for Prime Time
- James Gosling: Phase relationships in the standardization process
- gemal.dk – Blogupdates sidebar
- Firebird WebBar
- RSS Magic for .Net – Silverband Software
- RSS.NET
Ah, I feel much better now. This “link and a half-hidden snark” stuff is kinda fun. For me, that is.
Re the ”how would you write a parser for this” comments on RDF/FOAF stuff, for 99.9% of developers, the answer is: you don’t. Just download someone else’s RDF parser. There’s a good number of RDF parsers around already, eg. RDF::Core for Perl users in CPAN, RAP for PHP (new version out today, http://lists.w3.org/Archives/Public/www-rdf-interest/2003Aug/0008.html), Redland/Raptor for C + various other language bindings, ARP/Jena or Sesame for Java heads, Drive for C#, rdflib for Python, plus others in XSLT, Prolog, Ruby etc.
RDF’s XML syntax does look daunting if you come to it as an application developer thinking ”how the f*** am I supposed to code to _that_ using SAX/DOM/XSLT”, since there are various ways any given RDF graph can be written down as XML.
The answer is to do the lazy thing; use an off-the-shelf RDF parser, and code to the RDF abstraction instead of to its XML representation.
Edd Dumbill’s piece at http://usefulinc.co,m/edd/blog/2003/7/25#00:36 discusses this, and Ian Davis’ FOAF/PHP tutorial gives some nice examples…
http://www.semanticplanet.com/2003/05/parsingFOAFWithPHP.html
Basically an RDF parser gives you a library that takes an
RDF/XML doc as an argument, and returns to you a list of the triples which correspond to the RDF graph structure it encodes.
I actually, um, misspoke: I didn’t mean a parser so much as an app that would do anything other than just present a query interface for people who already knew what triples they were looking for. That’s where I start having trouble with the expressiveness of RDF: as a (sometime) developer, I want there to be exactly one way to say something, not a million nuanced ways. Once I figure out that A knows B, I want to know that A’s name is X, not that a name-ish thing for A might be in any of a dozen things that I know about (foaf:nick, etc.), any of an infinite number of things that I can discover by reading schemas are subclassing one of the dozen things I know about, or any of an infinite number of things which, while roughly equivalent, aren’t subclassing something that I knew about at the time I wrote my app.
Since you can write FOAF any way that pleases you, what pleases you will probably be what works with an app that you want to use. Say there are two big FOAF explorers, and one wants to find names in foaf:name, and the other wants to find names in foaf:givenname and foaf:surname. Will people who like FOAFNavigator then only use foaf:name, and put badges on their pages saying ”Best viewed in FOAFNavigator”?
But thanks for the link to RAP – I think I looked at a really early version, but from the sound of things it’s come a long way.
Oh OK, that’s a much more reasonable and interesting question!
You’re right, we should make efforts to avoid needless fragmentation of the data. There are a bunch of issues here. I’ll try write something better on this on rdfweb.org once the new FOAF spec’s out, but in meantime…
one trick that most FOAF aggregators do, is allow for
different markup to be used to identify people, yet have it all be folded together (’smushed”). So one file might mention you and id you by your homepage, another by your mailbox, a 3rd by your icqChatID, but this can all be folded together so long as somewhere we know that a single person has those properties. The naming properties are probably the most urgent thing to get improved in FOAF. Basically foaf:name is our guarantee of interop, which most everyone uses, the given/family/etc stuff needs fixing, and should be more clearly flagged as optional and overly western. The foaf:nick thing is interesting too, it turns out to be very popular in Japanese FOAF files(*), at
least amongst people currently into FOAF there, because they’re not into the idea of associating their real names with their weblogs etc. See comments in http://rdfweb.org/pipermail/rdfweb-dev/2003-June/011290.html
There are some basics we can expect in most FOAF files, and which the new spec will call out more clearly. But there is a lot that is optional (in fact it all is — you don’t need to say anything). This corresponds to the freedoms people enjoy in their homepages… a homepage might mention the school you went to, some stuff you wrote, some info about your friends, where you work, which political parties you support, what you look like, etc. Or it might not. I don’t think there is much beyond foaf:Person and foaf:name which we can expect to be universally present in a FOAF person description. And the Japanese case shows that even name might be optional. So to a certain extent it is up to us as developers to have tools and APIs to make this freedom (and associated flexibility, uncertainty…) easier to code with. At the engineering end, for eg., this is suggesting that RDF query languages need certain features (optionals), and that databases will need certain facilities to help canonicalise ’wild’ Web data into somewhat more manageable forms. So, not just the basic RDF parsers I mentioned earlier, but also ’smushing’ together of differently-identified nodes, as well as handling of things like inverse properties (’depicts’ versus ’depiction’)…
So yes, there’s definitely an issue here regarding how we write apps that deal with hetrogenous data. But don’t shoot the messenger (or carrier); FOAF (and RDF) are just a platform to allow people to say what they like. We can encourage certain basic descriptions to be widely used, but ultimately that’ll be driven by tools and trends rather than any attempt to dictate it formally in the spec. So you’re quite right to point to ’best practice’ agreements amongst aggregators. If we get our act together and collectively make it interesting and worthwhile to have foaf:name and foaf:Person used, people will deploy those properties… And if all the tools use different bits of FOAF without sufficient overlap, it’ll demotivate everyone.
I’m trying to ship a draft of the new spec tommorrow or monday, which will hopefully address some of these concerns, indicating some basic common-core properties and conventions which most FOAF files and tools will use…
(*)see http://antipop.zapto.org/wiki/?The%20%27friend%20of%20a%20friend%27%20project%20-%20FOAF
some good geeky links…
…at phil ringnalda dot com.