@prefix rdf: . @prefix rdfs: . @prefix rss: . @prefix foaf: . @prefix dc: . @prefix wot: . @prefix sy: . @prefix admin: . @prefix content: . @prefix xfn: . @prefix h: . a foaf:PersonalProfileDocument ; foaf:maker ; foaf:primaryTopic ; wot:assurance . xfn:me , , , , , , , , , , , ; a foaf:Person ; foaf:depiction ; foaf:family_name "Beckett" ; foaf:givenname "David" ; foaf:homepage ; foaf:img ; foaf:interest , , , , , ; foaf:knows [ a foaf:Person ; foaf:mbox_sha1sum "1ba3bffdd13a136d38b77542f2e26fd1dc0042f2" ; foaf:name "Edd Dumbill" ], [ a foaf:Person ; foaf:mbox_sha1sum "461179310021b2185ad7f67f14e5d4deb2107c47" ; foaf:name "Morten Frederiksen" ; foaf:nick "mortenf" ], [ a foaf:Person ; foaf:mbox_sha1sum "4829af19130151de1c4def299d73d33f33dee0fb", "828414515d398b42268a6c2ed879dc505369223a" ; foaf:name "Jo Walsh" ; foaf:nick "zool" ], [ a foaf:Person ; foaf:name "Damian Steer" ; foaf:nick "shellac" ], [ a foaf:Person ; rdfs:seeAlso ; foaf:mbox_sha1sum "94b6eb0c835f928c5ed565dc3ed1a355ac1b41e5" ; foaf:name "Dan Connolly" ; foaf:nick "DanC" ; foaf:workplaceHomepage ], [ a foaf:Person ; foaf:homepage ; foaf:mbox_sha1sum "867ac51a36819bbc36620c41edecdc1372fb75dc", "94df76ca20cae1675798195abcada6e52f9391c8" ; foaf:name "Jan Grant" ; foaf:nick "jang" ; foaf:workplaceHomepage ], [ a foaf:Person ; foaf:homepage ; foaf:mbox_sha1sum "fd1c7fa497930b8b24e3998927fcebe63509ef20" ; foaf:name "Eric Miller" ; foaf:nick "em", "emiller" ; foaf:workplaceHomepage ], [ a foaf:Person ; rdfs:seeAlso ; foaf:homepage ; foaf:mbox_sha1sum "ca9f1895e1aab74bea68585fd626ed248042f825" ; foaf:name "Phil McCarthy" ], [ a foaf:Person ; rdfs:seeAlso ; foaf:homepage ; foaf:mbox_sha1sum "965c47c5a70db7407210cef6e4e6f5374a525c5c" ; foaf:name "Tim Berners-Lee" ], [ a foaf:Person ; rdfs:seeAlso ; foaf:mbox_sha1sum "241021fb0e6289f92815fc210f9e9137262c252e", "362ce75324396f0aa2d3e5f1246f40bf3bb44401", "f46850eab07e26c850847d88390530afcfee0711" ; foaf:name "Dan Brickley" ; foaf:nick "danbri" ], [ a foaf:Person ; rdfs:seeAlso ; foaf:mbox_sha1sum "289d4d44325d0b0218edc856c8c3904fa3fd2875" ; foaf:name "Libby Miller" ; foaf:nick "libby" ], [ a foaf:Person ; foaf:mbox_sha1sum "600dd27ff619633eabea90206bf14a6a4a88d7db" ; foaf:name "Matt Biddulph" ], [ a foaf:Person ; foaf:homepage ; foaf:mbox_sha1sum "f49a6854842c5fa76dc0edb8e82f8fe04fd56bc9" ; foaf:name "Bijan Parsia" ], [ a foaf:Person ; foaf:homepage ; foaf:mbox_sha1sum "8de055c01fb32148bd71121a55edfa91cfc61cfa" ; foaf:name "Jim Hendler" ], [ a foaf:Person ; foaf:mbox_sha1sum "c66b1cf8ee172f06b7b41f9e6257623ba14eab5f" ; foaf:name "Sean B. Palmer" ; foaf:nick "sbp" ; foaf:weblog ], [ a foaf:Person ; foaf:mbox_sha1sum "be972c7a602683f7cf3c7a1fd0949c565debe4d3" ; foaf:name "Norm Walsh" ; foaf:nick "ndw" ; foaf:weblog ] ; foaf:made , ; foaf:mbox_sha1sum "970987f991961f2553a1bf2574166fa29befbccb" ; foaf:name "Dave Beckett" ; foaf:title "Mr" ; foaf:weblog ; foaf:workplaceHomePage . dc:title "Dave Beckett -- Journalblog" ; a foaf:Document ; rdfs:seeAlso . rss:title "Dave Beckett -- Journablog" ; a rss:channel . dc:description "Picture of Dave in 2005" ; dc:format "image/png" ; dc:title "Dave Beckett" ; a foaf:Image . dc:title "Miscoranda" ; a foaf:Document . dc:title "norman.walsh.name" ; a foaf:Document . rss:title "RDF Resource Guide" ; a rss:channel ; rdfs:seeAlso . dc:title "Semantic Weblogs" ; a foaf:Document ; rdfs:seeAlso . rss:title "Semantic Weblogs" ; a rss:channel . dc:title "Dublin Core Metadata Initiative" . dc:title "Resource Description Framework (RDF)" . dc:title "RDF Site Summary (RSS 1.0)" . dc:title "Metadata" . dc:title "Semantic Web" . dc:date "2008-07-06T19:51:25Z" ; rss:description "RDF and free software hacking" ; rss:items [ rdf:_1 ; rdf:_10 ; rdf:_2 ; rdf:_3 ; rdf:_4 ; rdf:_5 ; rdf:_6 ; rdf:_7 ; rdf:_8 ; rdf:_9 ; a rdf:Seq ] ; rss:link "http://journal.dajobe.org/journal" ; sy:updateBase "2000-01-01T12:00+00:00" ; sy:updateFrequency "1" ; sy:updatePeriod "hourly" ; rss:title "Dave Beckett - Journalblog » comment" ; admin:generatorAgent ; a rss:channel . dc:creator "Dave Beckett" ; dc:date "2008-07-06T19:51:25Z" ; dc:subject "comment", "raptor", "rasqal", "rdf", "redland" ; rss:description """Yesterday I released updates for three of the four Redland packages: Rasqal RDF Query Library (rasqal) 0.9.16 Redland RDF API Library (redland) 1.0.8 Redland RDF Language bindings (redland-bindings) 1.0.8.1 This is a major release due to an ABI/API change in Rasqal that is needed for the future. It only makes sense to upgrade ...""" ; rss:link "http://journal.dajobe.org/journal/posts/2008/07/06/redland-rdf-libraries-108-released/" ; content:encoded """

Yesterday I released updates for three of the four Redland packages:

This is a major release due to an ABI/API change in Rasqal that is needed for the future. It only makes sense to upgrade all of these at the same time since they form a dependency chain. So rather than three announcements, I made one and shipped Fedora Cora 7 RPMs and Debian deb binaries too.

I also released a new version of the fourth package: Raptor RDF Parser and Serializer Library (raptor) 1.4.18 a few weeks ago with new RDFa parser and atom-triples serializer, but that’s independent (details below). Yesterday I added FC7 RPMs.

The individual package release notes are as follows:

Rasqal RDF Query Library 0.9.16

WARNING: ABI AND API CHANGED in this release. Rasqal 0.9.16 is incompatible with 0.9.15.

  • Added a rasqal_world object used for all constructor functions
  • Removed deprecated functions and macros
  • Fixed some memory leaks and made some low-memory resilience fixes
  • Query result sets can be read/written from sparql XML results format
  • Improved error syntax error reporting

See the Rasqal 0.9.16 Release Notes for the full details of the changes.

Redland RDF Library 1.0.8
  • Updated to use Rasqal 0.9.16 (from 0.9.15)
  • Updated to use Raptor 1.4.18 (from 1.4.16)
  • Added a ‘trees’ indexed in-memory storage
  • Improvements to low-memory and other failures of resource allocation
  • API additions and changes to concepts, parser and serializer classes.
  • Fixed Issue 0000256

NOTE: The next release of redland will NOT include raptor and rasqal in the tarball, they will be separate download dependencies.

See the Redland 1.0.8 Release Notes for the full details of the changes.

Redland RDF Language Bindings Version 1.0.8.1
  • Synchronise with Redland 1.0.8
  • Configuration now prefers pkg-config which helps OSX linking
  • Minor fixes to perl, python and ruby bindings.

See the Redland Bindings 1.0.8.1 Release Notes for the full details of the changes.

Raptor RDF Parser and Serializer Library 1.4.18
  • Added an RDFa parser using an embedded version of librdfa by Manu Sporny of Digital Bazaar.
  • Added an Atom 1.0 (RFC 4287) serializer with several output parameters.
  • Improved RSS 1.0 serializer functionality and resilience.
  • Added new API methods for qname, serializer, sequence and XML writer classes.
  • Many other fixes and resilience improvements.
  • Fixed reported issues: 0000186 and 0000255.

See the Raptor 1.4.18 Release Notes for the full details of the changes.

""" ; rss:title "Redland RDF Libraries 1.0.8 released" ; a rss:item . dc:creator "Dave Beckett" ; dc:date "2008-06-28T23:54:31Z" ; dc:subject "comment", "flickr", "raptor", "rdf", "redland" ; rss:description "In January 2007 I started playing with the Flickr API - the HTTP-based web service that lets you manipulate Flickr. At that point I was using it to play with machine tags and to see how the most popular Web Service API worked, especially in the area of authentication. ..." ; rss:link "http://journal.dajobe.org/journal/posts/2008/06/28/the-flickcurl-story/" ; content:encoded """

In January 2007 I started playing with the Flickr API – the HTTP-based web service that lets you manipulate Flickr. At that point I was using it to play with machine tags and to see how the most popular Web Service API worked, especially in the area of authentication. This was in the days before OAuth if you can remember that far back.

I started with a test program in C that called libcurl and did some of the signing and parameter marshaling of the flickr.photos.getInfo call which is where all the juicy metadata about photos is. I started thinking about ways to map photo metadata into RDF for manipulating and querying; there is an existing Perl Flickr RDF mapping but it didn’t contain everything. This state of sources was useful; it contained a small library with the one API method plus a command-line utility to call it. Since I was using libCurl to call Flickr, I named it Flickcurl. Also CFlickr was taken! (Flickcurl also uses libxml but flickcurlibxml is just nuts).

Apart from playing with photo metadata I also had some personal reasons to make something new. I wanted a lighter weight and less formal project than the way I had been building the Redland RDF Libraries. More of it compiles, ship it model and less of the unit tests, test cases and continual make check, worrying about portability approach. Maybe more fun would be a way to put it. I’m happiest as a free software / open source software tool-builder and at this point in 2007 I was spending a lot of time at work doing non-coding things such as designing specifications and doing technical leadership and the chance to work on some different code now and then was appealing to counterpoint the work stuff.

Redland is a set of libraries that have been growing since mid-2000 with more and more features as the semantic web technology stack grows so at any point in time there is no clear end state. For this project I wanted a clear goal to reach so I could be clearly done at some point. This is possible with the Flickr API since there are at any time a finite number of API calls (something like 100) so progress can be measured… although Flickr did add API calls while I was working on it. The result was I made a Flickcurl API coverage page with embedded API changelog (automatically generated from source code comments).

Flickcurl 0.1 was “released” 2007-01-21 although I didn’t announce it to anyone at that point. It was more of a tarball than an actual release.

One more thing I wanted to do was to experiment with different ways to tell people about software, compared to the ways I as using with Redland which was mostly email based but also via SourceForge and Freshmeat. So for Flickcurl I tried a bunch of different ways:

That was kind of fun, and I also followed a similar light weight process with Triplr but that’s another story. I think caring less worked out fine; people did use it and submit patches. Right now I still use the Flickr mailing list, API group, and freshmeat project.

As the library headed towards 100% of the API and beyond it did get a bit more formal and I imported what I think are the best practices from the Redland libraries:

  • objects in C design
  • always refactoring the source code: refactoring is not just for dynamic languages
  • source code docu-comments generating an HTML API reference via gtk-doc
  • folding in portability fixes
  • make it work with optional libraries for extra functionality (Raptor in this case, to allow serialising to other RDF syntaxes)
  • built in portable ANSI C
  • taking care about memory leaks with valgrind
  • comes with a utility program able to exercise the entire API (called flickcurl)
  • Debian packages (created by somebody else, yay!)
  • manual pages for the command line utilities

The general aim was to get 100% of the Flickr API done by the end of 2007 and I actually reached it for Flickcurl 1.0 on 2008-01-12 which was pretty close.

So right now the library has gone beyond 1.0; the latest release is Flickcurl 1.4 which was released last Tuesday 24th June (see release notes) which primarily added video support but I also updated the photo metadata mapping to RDF by adding a serializer class for abstracting the photo-to-triples process.

The RDF triple mappings is something that has always been there but not part of the core library. It could be optionally used inside Raptor to automatically read Flickr photo URIs as RDF data sources. I doubt it’ll ever be presented inside a public web service like Triplr since it would require passing in Flickr API authentication tokens and user credentials.

The RDF triples mapping I’ve made for the Flickr photo metadata has mixture of vocabularies which are in 3 buckets:

  1. Existing Vocabularies: well known RDF schemas (class and properties) that have been developed over many years by multiple people and organisations, sometimes with a lot of formality.
  2. Flickr-specific Vocabularies: vocabularies I made up mostly for Flickr video and places API terms.
  3. Machine Tag Vocabularies: I made them up using machinetags.org/ns URIs as a root for the namespaces associated with the vocabularies. The terms in the vocabularies come from how people used machine tags on Flickr and are not always defined.

This is a range of what might be called semantic web heavy to light although there is absolutely nothing wrong with mixing things up if you are not worried about inference. This is OK! I should probably put some html/schema documents at the vocabularies and get the redirects and all that # and / business sorted so that the linked data works out properly but what I have now is just a start and I’d be interested to see what people think. There are more details of the vocabularies and terms I’m using in the Flickcurl 1.4 release notes although I should probably add vocabulary information to the documentation too.

That’s all for now but I’ll expand some more in another post about the Flickr API itself and my experience with it and impressions of it as a both a software developer and HTTP Web Service designer.

""" ; rss:title "The Flickcurl Story" ; a rss:item . dc:creator "Dave Beckett" ; dc:date "2008-04-06T03:24:54Z" ; dc:subject "comment", "raptor", "rdf", "xml" ; rss:description """Last week I released version 1.4.17 of my Raptor C library (release notes) but in the 38 releases over the 7 years or so since I started building it, there's more to see than just triples. I/O stream API Abstracts from specifics of I/O so that you can read/from write to any ...""" ; rss:link "http://journal.dajobe.org/journal/posts/2008/04/05/raptor-web-library-1417/" ; content:encoded """

Last week I released version 1.4.17 of my Raptor C library (release notes) but in the 38 releases over the 7 years or so since I started building it, there’s more to see than just triples.

I/O stream API
Abstracts from specifics of I/O so that you can read/from write to any of a string/memory buffer, a file, a C FILE* or any custom user data structure. Similar to C++ idea of stream. This allows lazy evaluation of I/O and using language-specific I/O routines such as PerlIO (potentially, not yet!). The read abstraction is new in 1.4.17.
Sequence API
For small lists of data items that can grow at either end. This allow small lists, stacks and queues to be made when needed, and iterated over. Do not use for large lists! (Something else is coming along to handle this soon.)
Stringbuffer API
Provides a growing string class, similar to Java’s StringBuffer, which can be added to many times and then the result obtained (with no further changes allowed). This is handy for constructing formatted output, queries using parameters and values which is hard in C without entering the world of char buf[big enough]. The stringbuffer API tries hard to minimise copying.
Unicode API
For a small part of Unicode that is used near XML; UTF-8 encoding and decoding and Normal Form C validation. Nearby it provides XML 1.0 and 1.1 name-checking/validation functions.
URI API
Construction of URIs, resolving of relative URIs and turning absolute URIs into relative. It handles the RFC3986 URI spec updates.
Web fetch API
Retrieving of content from a URI in chunks of bytes. It works by calling curl, libxml or BSD libfetch underneath. It also handles redirections and adjusting any base URIs for 30x responses, returning content type headers early so that content negotiation can be done and customisation of the requests to send appropriate User-Agent and Cache-Control headers (latter, new in 1.4.17)
XML with Namespaces Streaming (SAX2) Reader API (newly public in 1.4.17).
Streaming reading of large XML documents over either libxml2 or expat (build time choice with configure). Expat out of the box does not support namespaces and XML QNames, so Raptor adds those and hides various library differences and some bugs. The XML API also provides full XML Base (xml:base) support.
XML Writer API
Write XML elements as Canonical XML output.

Some of the above are large pieces of work and some are small, but they are all solid and many have been used for multiple years in production. These turned out to be handy datatype classes for web programming and I needed them since RDF is built with web technology.

The bonus is that all of the above is used to provide the signature features of Raptor: RDF Parsing – turning syntax into triples and RDF Serializing – turning triples into syntax. Raptor now parses 7 syntaxes (GRDDL, N-Triples, RDF/XML, RSSes, Atom, TRiG, Turtle) and serializes to 10 (Atom 1.0, GraphViz DOT, JSON * 2, N-Triples, RDF-XML * 3, RSS 1.0, Turtle). The JSON outputs are new for 1.4.17

So although Raptor deals with all the RDF syntax details, it does a lot more. But I’m not changing the name!

""" ; rss:title "Raptor Web Library 1.4.17" ; a rss:item . dc:creator "Dave Beckett" ; dc:date "2008-03-14T02:43:36Z" ; dc:subject "comment" ; rss:description "Yahoo! Search announced today in their blog post that they will soon support in the Search Monkey project the use of semantic web technologies such as RDFa with standard vocabularies such as FOAF and Dublin Core. It also will do a lot of other cool stuff that you can ..." ; rss:link "http://journal.dajobe.org/journal/posts/2008/03/13/yahoo-search-reading-the-semantic-web/" ; content:encoded """

Yahoo! Search announced today in their blog post that they will soon support in the Search Monkey project the use of semantic web technologies such as RDFa with standard vocabularies such as FOAF and Dublin Core. It also will do a lot of other cool stuff that you can read about above.

It was nice to see that several other people noticed this. (Techmeme frozen page – #1 story)

I didn’t work on this project and don’t work in the search division, but continue to build with Semantic Web technologies in another more internal-facing part of Yahoo! But it is exciting to see that there are more public applications getting out, such as this and research projects like microsearch by Peter Mika.

""" ; rss:title "Yahoo! Search reading the semantic web" ; a rss:item . dc:creator "Dave Beckett" ; dc:date "2008-02-11T05:30:22Z" ; dc:subject "comment" ; rss:description """Happy 10th Birthday XML. It's clear you are going to be around for some time. People know your good points and bad and have got the kinks worked out using you in production, in diversity and at scale. Take care not to be distracted in the next 10 years by sexy ...""" ; rss:link "http://journal.dajobe.org/journal/posts/2008/02/10/birthdays-xml-is-10-and-rdfxml-is-9/" ; content:encoded """

Happy 10th Birthday XML.

It’s clear you are going to be around for some time. People know your good points and bad and have got the kinks worked out using you in production, in diversity and at scale.

Take care not to be distracted in the next 10 years by sexy new text formats that overlap in some features, but don’t replace you for many uses. I’m talking about you, JSON.

In the RDF world, RDF/XML is the syntax people love to hate, or just love/hate. It is 1 year younger than you, so maybe in February 2009 we’ll have something to celebrate about that. Yeah, it might happen :)

I recently made a new textual RDF syntax sibling Turtle with TimBL whose official birthday was last month, although it’s actual birth was January 2004 in Bristol, or earlier if you look into it’s ancestry. In 6 (10?) more years it’ll be something we can properly rely on, like XML is today.

Dave

P.S. For more memories, check out Tim, Eve and Norm who were involved in XML from very early on when I was just an observer.

""" ; rss:title "Birthdays – XML is 10 and RDF/XML is 9" ; a rss:item . dc:creator "Dave Beckett" ; dc:date "2007-08-14T02:05:37Z" ; dc:subject "comment", "rdf", "yahoo" ; rss:description """It's been nearly 2 years since I joined Yahoo! and the the semantic web-based technology I helped develop has been deployed in production for some time. It has been encouraging to see the ideas get more accepted since today I noticed that in a hotjobs search for rdf yahoo near Sunnyvale there 5 jobs open - not ...""" ; rss:link "http://journal.dajobe.org/journal/posts/2007/08/13/semantic-web-yahoo-part-deux/" ; content:encoded """

It’s been nearly 2 years since I joined Yahoo! and the the semantic web-based technology I helped develop has been deployed in production for some time. It has been encouraging to see the ideas get more accepted since today I noticed that in a hotjobs search for rdf yahoo near Sunnyvale there 5 jobs open – not in my group, but in Yahoo! Local.

Our group in Sunnyvale is continuing to look for HTTP and web caching experts, designers and coders for building REST-based web services. Right here and now we have interesting, large scale, rich data problems and are applying semweb techniques to them. Contact me if any of this sounds exciting to you.

Semantic Web Yahoo – Part one

""" ; rss:title "Semantic Web Yahoo – Part Deux" ; a rss:item . dc:creator "Dave Beckett" ; dc:date "2007-08-04T06:59:25Z" ; dc:subject "comment" ; rss:description """In January 2007 just for fun I started writing a C API to Flickr using the Flickr web services called Flickcurl. The name was because it was originally built using Flickr via libCurl to do the HTTP work ... although right now it contains more use of libxml than of libcurl. I started this for a ...""" ; rss:link "http://journal.dajobe.org/journal/posts/2007/08/03/flickcurl-c-api-to-flickr/" ; content:encoded """

In January 2007 just for fun I started writing a C API to Flickr using the Flickr web services called Flickcurl. The name was because it was originally built using Flickr via libCurl to do the HTTP work … although right now it contains more use of libxml than of libcurl.

I started this for a bunch of reasons, including to learn more about “web 2.0″ web APIs, see how RESTy the Flickr API really is (Answer: not much, it’s very much an RPC model) and the issues with developing a Web API. It’s clear this is an evolved and evolving one since now and then I discover undocumented returned attributes in the XML and cases where it is not clear why attributes were used instead of elements. It’s very suited towards dynamic scripting languages where it is easy to pass around dictionaries / hashes / associative arrays of parameters that can grow. So in some sense, making something feel like a natural API in a static language like C is rather going against the grain and rather slow work.

There are, however, things available to help. There are method reflection APIs so I wrote a code generating program that can nicely automate writing many of the simpler calls that return no value or just a single one. I also used a lot of similar patterns so that parsing tags xml is quite similar to parsing comments xml. The XML is primarily read via XPath and a little DOM.

One other nice thing about this is that this a piece of work with a fixed size, albeit growing slowly. The Flickr API currently has 104 calls – depending on how you measure them – so it’s easy to check progress, and that’s how I’ve been doing it. I built tools to read the docu-comments (javadoc, gnome-doc, kernel-doc style) and mark the Flickcurl coverage release by release.

The news today is that I have reached the half way point: 50% of the APi with the release of Flickcurl 0.11 at least until they add something more! I have also done most of what I think are the trickier parts – the uploading, searching and getting info about photos. The remaining API parts are more regular, so I feel like I’m coding downhill now.

Now there’s something else it does – and this won’t be a surprise to most given my interests. Flickcurl generates RDF descriptions from Flickr photos with a flickrdf utility, including reading Machine Tags. The namespaces are either well known ones, or invented by me, pointing at the machinetags.org wiki – you can create your own definition.

flickrdf uses Raptor to do nicer serializing when it is available. So this means I can turn jellyfish into Turtles. W00t! (*)

$ ./flickrdf -o turtle http://www.flickr.com/photos/dajobe/196308964/
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/#> .
@prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<http://www.flickr.com/photos/dajobe/196308964/>
    dc:creator [
        a foaf:Person;
        foaf:maker <http://www.flickr.com/photos/dajobe/196308964/>;
        foaf:name \"Dave Beckett\";
        foaf:nick \"dajobe\"
    ];
    dc:dateSubmitted \"2006-07-23T18:16:13Z\"^^xsd:dateTime;
    dc:rights <http://creativecommons.org/licenses/by-nc-sa/2.0/>;
    dc:modified \"2007-02-25T07:45:46Z\"^^xsd:dateTime;
    dc:issued \"2006-07-23T18:16:13Z\"^^xsd:dateTime;
    dc:created \"2006-07-23T05:28:50Z\"^^xsd:dateTime;
    geo:lat \"36.620487\";
    geo:long \"-121.904468\";
    dc:title \"Jellyfish at Monterey Aquarium\";
    dc:subject \"jellyfish\" .

After that bad joke (and it could have been worse if I had a picture of a Turtle) here’s what you need to know. Get it at flickcurl-0.11.tar.gz (md5sum eea351e4d35e8d1c63b124cd8ee257ba, sha1sum d220f6371c0c5334c824a51ba848d9358d73e533) or the latest in the Flickcurl Subversion It’s licensed under the GPL2 / LGPL2 / Apache 2.0 or any newer versions of any of them.

Note: I work for Yahoo! and although Flickr is part of Yahoo! this project is my own personal work.

(*) Actually I’m slightly cheating with this example, there’s a couple of bug fixes in SVN after the release which are needed to get this output.

""" ; rss:title "Flickcurl – C API to Flickr" ; a rss:item . dc:creator "Dave Beckett" ; dc:date "2007-07-21T03:39:04Z" ; dc:subject "comment" ; rss:description """I am heading to Portland next week for the O'Reilly Open Source Conference 2007 which I've been to only once before. This year's conference has around 15 parallel tracks, which makes it pretty huge to follow. I'm hoping to get learn lots of new things, be inspired with ideas, meet some great people, and ...""" ; rss:link "http://journal.dajobe.org/journal/posts/2007/07/20/heading-to-oscon/" ; content:encoded """

I am heading to Portland next week for the O’Reilly Open Source Conference 2007 which I’ve been to only once before. This year’s conference has around 15 parallel tracks, which makes it pretty huge to follow. I’m hoping to get learn lots of new things, be inspired with ideas, meet some great people, and who knows, maybe hire some to work with me ;)

""" ; rss:title "Heading to OSCON" ; a rss:item . dc:creator "Dave Beckett" ; dc:date "2007-03-25T23:49:09Z" ; dc:subject "comment" ; rss:description """I've made a new thing: Triplr for GETting semwebby data. Go check it out. It's unrelated to the other older new thing not previously mentioned in a blog post: Flickcurl which is the C library I made for the Flickr API (about 25% complete) although I did steal the cute name from the utility which turns a ...""" ; rss:link "http://journal.dajobe.org/journal/posts/2007/03/25/triplr-stuff-in-triples-out/" ; content:encoded """

I’ve made a new thing: Triplr for GETting semwebby data. Go check it out.

It’s unrelated to the other older new thing not previously mentioned in a blog post: Flickcurl which is the C library I made for the Flickr API (about 25% complete) although I did steal the cute name from the utility which turns a Flickr photo’s description into triples, with the help of the new machine tags support. My conversion could be improved, I had to invent some namespaces.

""" ; rss:title "Triplr – stuff in, triples out" ; a rss:item . dc:creator "Dave Beckett" ; dc:date "2007-03-18T03:30:28Z" ; dc:subject "comment" ; rss:description "I often been puzzled why people write \"The Semantic Web is AI\" and \"The Semantic Web is a top-down design\" and \"The Semantic Web is Ontologies\". As far as I'm concerned, all of those are bogus. I think I've worked out why they write this - they aren't ..." ; rss:link "http://journal.dajobe.org/journal/posts/2007/03/17/semantic-web-is-webby-data/" ; content:encoded """

I often been puzzled why people write “The Semantic Web is AI” and “The Semantic Web is a top-down design” and “The Semantic Web is Ontologies”. As far as I’m concerned, all of those are bogus. I think I’ve worked out why they write this – they aren’t talking to anyone actually working directly on the technologies.

The semantic web is: a webby way to link data. That is all.

Everything beyond that is entirely optional fluff: data vs metadata, syntaxes, ontologies, query languages, rules, logic, …

This is my “lowercase” semantic web and the basis of what I have in running production code right now.

I’ll probably use that as my theme when I speak about A Little Semantics Can Go a Long Way on the panel at the Semantic Technology Conference in San Jose in May. ( I’ll also be at WWW2007 in Banff, Canada and XTech 2007 in Paris. )

""" ; rss:title "semantic web is webby data" ; a rss:item .