[uf-rest] RESTifying RAILs

[Tantek Ç elik]

On 11/4/05 2:24 AM, "Danny Ayers" <danny.ayers at gmail.com> wrote:

> On 11/4/05, Dr. Ernie Prabhakar <drernie at opendarwin.org> wrote:
>> Hi all,
>> 
>> A big welcome to new member David Hanssonn, who is probably best
>> known to you for an obscure little app framework he wrote in Ruby. :-)
> 
> Bravo!
> 
> Ernie, your points sound reasonable, but I'd come at the
> Rails+microformats question from a different angle. Drifting off list
> topic a little, sorry, but you know hobby horses, couple of cents
> worth anyhow...
> 
> I believe the one thing above all that Rails could do to make
> microformat-oriented apps easier and more useful, would be to support
> an RDF store backend (in addition to, or as an alternative to the SQL
> storage).

Danny, I hate to be the skeptic here, but where's the need?

One thing that a lot of new technologies like microformats, and Rails have
demonstrated is that you can get tons of things done quickly, and not ever
worry / care about learning RDF.  I think there's something to be said for
keeping it simple / minimal, and if RDF hasn't been needed so far, then why
not just ignore it for now?


> The primary justification is that data from any microformat could be
> manipulated uniformly in a single, consistent model.

That can be done without RDF.  Again, not necessary.


> For example, say you wanted your app to support both XFN and hCard.
> These both have a person as their main entity of interest, yet their
> syntax and general structure is slightly different.

Not different.  Orthogonal.  And they actually overlay quite well.

XFN leverages the behavioral pattern exhibited by millions of bloggers that
people are URLs (no matter how many SemWeb theoreticians dance on heads of
pins and argue against it).

hCard can map names of people to the URLs that represent them.

Thus it is trivial to simply combine the two.


> Mapped across to
> SQL, it would be hard to avoid having one table for the XFN kind of
> person and another table for the hCard kind of person.

Not at all.  They both could simply use URL as the index.  Done.

Oh in fact, Mark Pilgrim has already done this.  It's trivial.


> With RDF, the
> integration of the two kinds of data into a common structure  is
> pretty much a non-brainer.

With all due respect, nothing with RDF that I have ever seen or seen
explained has ever been a non-brainer in practice.

And in this case the common structure is URL.


> A secondary benefit is that the data could also be exposed RESTfully
> directly from the store

Again, RDF is unnecessary for that.  As Ernie's exploration of microformats
and REST has revealed, you can do that directly and simply, without having
to transform the data into "RDF-space" and back out.


Tantek