Raw

Speaking on the phone to my brother, I told him about the Listy Thing I've been working on, he pointed me to workflowy. It's an outline/list todo thing that already does a big chunk of what I had in mind for Listy Thing (quite funny they've also got a 'y' on the end). The UI is awesome, which on the one hand is inspiring in demonstrating feasibility, on the other scary, showing how far I have to go.

It is basically what I'm after, only I want something backed by RDF so that more data can be associated with nodes (especially nodes which correspond to Web resources), the data can be reused, and many alternate views are possible.

I'm still a little stuck on the fundamental question of how best to represent lists, I guess I just have to try things out. Had some good suggestions on the G+ page - there's even an Ordered List Ontology.

The issue's a bit conflicted, because on the one hand useful ordering is generally tied to some particular property (e.g. dc:date) so the list structure can be generated on demand (via SPARQL or whatever), no additional ordering is needed in the data. But then as far as user experience is concerned, as a list is being put together the order can be totally arbitrary - i.e. there is an order, only we're not quite sure what it is yet. This might suggest using rdf:List as a general purpose mechanism.

I think I'll try some kind of low-cost property (with a numeric value). So a property, which after all is just another kind of resource, gets minted when the list is created in the UI. Ideally I suppose it'd be a bnode but a quasi-disposable URI will do. Dunno, give it an rdfs:label on the fly and associate it with user/date of creation?

I use the namespace http://purl.org/stuff# for "disposable" classes and properties (feel free to follow suit). They're Cool URIs in the sense that they'll always resolve (although I must add RDF docs to that URI), disposable in the sense that they appear in instance data but won't have any more definition.

I posted the other day a note-to-self re. Listy Thing, though I haven't done any coding on that since I have been puzzling over one particular bit, which boils down to : how best to represent lists in RDF. Ok, there's rdfs:List and Wikipedia has quite a good definition of list, but that's not really the end of the story, there are a few practical considerations.

The conceptual model I want is just the usual thing of a finite ordered sequence of things, for sorting out my own lists: shopping, project resources and todo, bookmarks, list of people (friends & circles) etc. etc. The items in these lists will generally be either text or links (which fits nicely with RDF literals and resources)...or other lists. Ok, that just jumped into graph-land. Also the lists/items may also be lots of other things as well - like a todo list might contain tasks (yeah, got an unfinished vocab for that as well). An item may be multiple lists and so on. But the practical model I'm after is pretty much a direct reflection of HTML lists:

,
and
• to allow easy rendering/manipulation in the browser.

  One of my favourite typed-item lists of all time is (appropriately enough) Enrico Franconi's Description Logics Course. I want to be able to put things like that together really easily and - the why RDF? part - reuse the data easily.

  I've played with very similar stuff before with something I called XOW, XHTML Outlines for W6, where W6 was a simple vocab for adding just a bit of semantics to resources (addressing the questions who, why, what, when, where, how - I think it was Libby set me going down this path). Beh, loads of link rot around there, must fix - basically you could make lists of typed items in the browser, the result could be sent through XSLT to produce RDF.

  I've come at it afresh from the motivation of wanting to sort out my own lists, sod any wider problems. The tools are much better this time around, but the modelling thing is stil a quandary.

  With a bit of googling I've found some good scripts to get started and have been noodling on the HTML side - drag and drop reordering of lists, with in-place editing. Current home: live here, in github here (note - dev branch of seki). It's not far off what I reckon I need.

  Now there's the fun bit of expressing this material as pure data to stick it in a store and access via SPARQL (1.1). First pass at least I'll probably use XSLT in lots of places, the transformations should be pretty straightforward, but the SPARQL side is a bit tricky. Andy Seaborne has done a great post about lists with SPARQL Update, and as I'm using his Fuseki for storage it stands a good chance of working (heh).

  But I want to be able to muck around with these things a lot, so I'm wondering whether it might be advantageous to also 1. overlay some old-fashioned RDF container stuff on the lists as well (i.e. rdf:Seq) and even 2. simple ordinal property values, something like :

  :contains [ a :listitem; :value ; :inlist :position "43" ] .

  Dunno, may this might help with matching quirks like those Andy mentions, "the empty list isn't any RDF triples, so looking for lists isn't just looking for rdf:rest properties", (rdf:nil keeps running away!) and with SPARQL 1.1 property paths, list elements do not necessarily come out in order.

  Funnily enough, lists in RDF seem to attract a lot of caveats - there's the old stuff about how 'weak' containers are, the lovely line in the RDFS spec: "Just as a hen house may have the property that it is made of wood, that does not mean that all the hens it contains are made of wood, a property of a container is not necessarily a property of all of its members.". In the same spec, the delightful: "RDFS does not require that there be only one first element of a list-like structure, or even that a list-like structure have a first element.". But if it walks like a duck and quacks like a duck then it's made of wood, hence a witch.

  Suggestions very welcome, here's a G+ Page , see if that works for comments.

  PS. also related is the Linked Data API stuff re. lists, see e.g. listvalued_props

Spent this morning having another go at sorting out my lists and links. The aim is to keep them in a triplestore (probably Seki/Fuseki/TDB/Jena) and to be able to add, organise & edit them in a browser. I'd better leave this, have a nap then get on with something else now. So to help me remember where I'm at:

• Rearrange & in-place edit (with jQuery) worked on test page, doesn't yet work on real data (crashes browser!)
• Editory thing - four-pane CSS seems ok, CKEditor looks good for rich content, need to play (not tried with above yet, not sure about cross-list D&D)

• Did a dump of links from Chrome, ran through Tidy, XSLT (xsltproc) to ul/li and split into separate lists - basically working ok

tidy-default bookmarks_1_6_12.html > bookmarks.xml

xsltproc lib/bookmarks-split2lists.xsl bookmarks.xml

for file in *; do mv "$file" "${file}.html"; done

• Vocab - no idea for textual list items, Annotea has http://www.w3.org/2002/01/bookmark#Bookmark, also Tag Ontology

PS. got some dump-from-del.icio.us code tagliatelle. Need to try AndyS's rdf:List with SPARQL 1.1 Update stuff.

I occasionally visit Dave Winer's blog, as he has been known to have good ideas. One of these from a few years ago, that he's talking about again, was 'Reading Lists', whereby (in principle) you can subscribe to a list of feeds. When the list changes, your aggregator (in principle) can subscribe/unsubscribe to the individual feeds in the list, showing the contents of the listed feeds probably grouped together in some fashion. Neat idea, but it doesn't really seem to have caught on.

There are two de facto standards for expressing lists of feeds: OPML and RDF ("foafrolls"). The former is probably better supported in desktop aggregators, the latter maybe more visible in the online Planet aggregators (including Planet RDF, though that uses chumpologica/Redland rather than PlanetPlanet). OPML is Dave Winer's 'outline processor' markup language, for lists of feeds it has typed links. The RDF version uses the FOAF, DC and RSS 1.0 vocabs (very typed links). Away from the feed list application, the OPML format is usable in Dave Winer's outliner, and any RDF tool can make sense of the RDF (naturally :) but I reckon it does rather lend itself to FOAFishness - feeds are associated with a foaf:Person (and/or foaf:Agent) with a foaf:weblog etc. (I dunno, the domain is right on top of SIOC too, maybe some info using those terms could be added to the feedlists..?).

For any kind of Information/Knowledge Manager kind of tool (Personal or otherwise) built with RDF, it seems quite natural to periodically refresh data (not only feeds but pretty much anything in the domain of interest - FOAF Profiles probably being ubiquitous), so Reading Lists would sit comfortably alongside other features.

But in the 'simple' world of RSS, subscribing to feedlists is something of a complication. For instance, in the good Mr. Winer's latest incarnation, he's got aggregated pages (e.g. daveriver.scripting.com) not unlike those of the Planets, with an autodiscovery link in the HTML pointing to the feedlist:

<link rel="alternate" type="application/rss+xml" title="OPML" href="index.opml" />

OPML is RSS? I don't think even the Universal Feed Parser is that liberal. The kludge does get Firefox to show the target as a subscribable link, but then that's still not much good if the tools don't know what to do with it. But it seems to me there's a much simpler approach - use RSS. To get myself some markup to show I just bookmarked this blog's feed with del.icio.us and had a look at the feed that produced, and it contains (trimmed) this:

<item>
<title>Danny Ayers : Raw Blog (feed)</title>
<link>http://dannyayers.com/index.rdf</link>
</item>

Now a current aggregator would see that and probably just display it as a HTML-style titled link. But if the aggregator bothered to do a HTTP HEAD, it'd see:

Content-Type: application/rdf+xml

To a (non-RDF savvy) aggregator that means an RSS 1.0 feed. So, aggregator dude, subscribe to it. Atom <link> elements have a (mime) type attribute, so there the HEAD wouldn't even be necessary.

While most feeds are a changing, fixed-length FILO queue of entries, there's nothing to stop them being a variable length list.

In other words, the simplest RSS feed list is an RSS feed. Even if the aggregator needs a little help in recognising a feed list, it's got to be easier than understanding an entirely different format (published with an inappropriate media type).

Ok, so personally I'd go straight down the RDF route, it's a heck of a lot more flexible. But an RSS-format Reading List does seem like low-hanging fruit for non-RDF tools.

Anyhow, if anyone's building an aggregator (they're a great little starter app when learning a new language), consider Reading Lists as a feature.