Re: Today's equivalent of CBD+URIQA? (was: Re: Schism in the Semantic Web community.)

2009/1/27 Manos Batsis <manos_lists@geekologue.com>

>
>
> Danny Ayers wrote:
>
>> i.e. maximally exploiting HTTP
>>
>
>
> Ah, nailed. It's too bad I have fallen behind regarding the state of the
> art, but the most horizontally useful idea I've ever stumbled upon re semweb
> was CBD [1] plus URIQA [2]. Essentially CBD defined graph limits (what we do
> with, e.g., lazy collection loading in the object-relational world). URIQA
> was a fitting HTTP extension anyone could implement to acquire/exchange/CRUD
> those graphs.
>
> So, what is today's equivalent of those two?



I'd love to hear Patrick Stickler's retrospective opinion on these, I
remember him forcefully (and pretty convincingly) arguing the case.

But I suspect now we have named graphs in the picture, along with SPARQL
(and proposed update protocols), and the TAG finding on httpRange-14, it has
become a non-question.

What still bothers me somewhat is there is a danger of reinventing the silo
mentality for data, rather than exposing directly addressable resources,
using the link whether encoded in RDF/XML or whatever. We now have a much
better understanding of how follow-your-nose through URIs can allow enormous
scalability, and to some extent how this material can be exploited locally
through inference and/or Web 2.0-inspired modes of visualization.

In other words, although we can expose big data on the Web through mapping
techniques from traditional DBs or more cleverly through OWL(2), we may be
losing sight of the succesful bits of the Web as it stands. I say this with
the caveat that I honestly don't know for sure, and these kind of issues
have a tendency to sort themselves out in the massively distributed
environment.

Cheers,
Danny.


>
>
>
> [1] http://www.w3.org/Submission/CBD/
> [2] http://sw.nokia.com/uriqa/URIQA.html
>
> Cheers,
>
> Manos
>



-- 
http://danny.ayers.name