Re: Behind the times

On Tue, 19 Oct 2004 08:00:52 +0100, Julian Bond
<julian_bond-/Fkc1E/MbsFWk0Htik3J/[email protected]> wrote:

Hi Julian,

> Take this one instance of <dc:subject> used for categories. How many
> feeds use it? How many aggregators read it and display it? Is any
> attempt made to standardise the category labels (after del.icio.us maybe
> this isn't necessary)? Can I turn the base URL and the category and turn
> it back into a URL for just that category? Even though
> http://blogs.guardian.co.uk/news/archives/cat_uk_news.html is a
> logically constructed URL, I don't see it in the RDF.
> 
> My preference would be for
> http://blogs.guardian.co.uk/news/index.rdf
> http://blogs.guardian.co.uk/news/cat_uk_news/index.rdf
> 
> You could still put in all the dc terms, but that would make it possible
> for existing aggregators to take single categories.

I reckon there are at least a dozen issues here ;-) 

The amount of support for non-'core' data in existing aggregators is
one thing. Most of the desktop tools are built around a simple model
derived from an XML view of the syntax, in fact he same model as for
RSS 2.0. Support for extensions like dc:subject will have to be
written from scratch each time, whereas if the app uses the RDF model
internally then there's at least a common baseline of interpretation
above XML that can be used.

Standardising categories is a hard problem, as everyone has their own
system. There is work ongoing in places like SKOS for mapping between
such taxonomies, though as you suggest things like deli.cio.us offer a
cheap and cheerful alternative.

Using categories terms from dc:subject as parts of URIs for getting
feeds according to category would probably be very brittle as it's
crossing between two very different mechanisms (though having said
that I think DMOZ would support a similar approach).

Another problem with the cat/URI mapping is that you're effectively
forced to use hierarchical categorization schemes. This is also wired
into a lot of the aggregators I've seen.  Ok, so items can appear in
multiple places in a tree but it doesn't exactly lend itself to
convenient sorting, ordering or search. Tagging and general graph-
rather than tree-organized stuctures offer a way forward. You can
still project convenient tree-based navigation from an underlying
graph structure.

I agree with most of Tony and MrDemeanour's (heh) comments on the
issue of simple vs. RDF, but I'm not sure the ephemeral/static split
is a useful one - ephemeral material can be recorded, dynamic feeds
can be generated describing static material.

One approach to getting per-category display of feeds would be to push
the data through a simple RDF setup that split the items off into
separate feeds according to appropriate queries. You could do this
with an XML-only solution, but again you can be more systematic with
your handling of extensions if you have RDF support, you don't have to
build entirely from scratch every time.

I'd be tempted to call the aggregation tools around at the moment '1st
generation' - a lot are built around a combination of simplest thing
that could work and/or copying the approach of other implementations.
Well actually, I'd go further - syndication is still in the Stone Age.
In part this is understandable as /easy/ RDF tools are a relatively
new phenomenon, and perhaps more significantly developer familiarity
with the technologies  has only recently spread to the extent that its
seen as simply another toolkit, like XML.

The initial hump needed to start using RDF used to be big, now it's
relatively insignificant - the docs are available and friendly
toolkits are available for every language.

The second hump in aggregator development, that is for using
extensions is as big as ever with 'simple'-oriented tools. With an RDF
approach much of the support is available out of the box. The 'simple'
approach only stays simple when you set your sights low.

Traditionally anti-RDF arguments in this space have been based around
the perceived complexity of an RDF solution compared to a simple XML
one. These arguments aren't quite as convincing as maybe they once
were, especially when I can now point to the core implementation of an
RDF-based aggregator in 20 or so lines of code [1]. I've not played
with this yet, but I suspect filtering on dc:subject will take an
additional 3 or 4 lines.

Cheers,
Danny.

[1] http://www.semanticplanet.com/2004/10/announcingSemanticPlanetsRDFLibAndCarp.html


-- 

http://dannyayers.com


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/