Re: Modular Browsers (was RE: freebase parallax: user interface for browsing graphs of data)

Hello,

( replies inlined )

On Wed, Aug 20, 2008 at 9:19 PM, Kingsley Idehen <kidehen@openlinksw.com> wrote:
> Aldo Bucchi wrote:
>>
>> HI,
>>
>> Scanning the thread on Parallax I see some terms reoccurring:
>>
>> Outgoing Connections.
>> Lenses.
>> Lists.
>> Facets.
>> Free text search.
>> IFP to IRI resolution.
>> Find documents that contain IRIs
>> etc...
>>
>> They are all implemented in different ways but tend to share semantics
>> across different browsers and services.
>> How far are we from defining a modular framework so we can mix and
>> math these as atomic interaction pieces?
>>
>> Both services and probably UI parts.
>>
>> Of course, RDF and HTTP can be used to describe them and deliver the
>> descriptions and, in the case of widgets, some OOTB implementations.
>> XForms, Dojo widgets, SWFs?
>>
>> I have done something similar but much simpler in a Flex platform ( I
>> serve Flex modules, described in RDF and referenced by Fresnel vocabs,
>> but only for presentation ).
>> And then on a functional side I have several services that do
>> different things, and I can hot swap them.
>> For example, the free text search service is a (S)WS.
>> Faceter service idem.
>>
>> I guess we still need to see some more diversity to derive a taxonomy
>> and start working on the framework.
>> But it is nice to keep this in sight.
>>
>> The recurring topics.
>>
>> Best,
>> A
>>
>>
>>
>
> Aldo,
>
> Really nice to see you are looking at things holistically.

I showed up with a narrow interface, I know ;)

>
> As you can see, we are veering gradually towards recognizing that the "Web",
> courtesy of HTTP,  gives us a really interesting infrasructure for the
> time-tested MVC pattern (I've been trying to bring attention to this aspect
> of the Web for a while now).
>
> If you look at ODE (closely) you will notice it's an MVC vessel. We have
> components for Data Access (RDFiztion Cartridges), components for UI
> (xslt+css templates and fresnel+xslt+css templates), and components for
> actions (*Cartridges not released yet*).

Ah... I remember telling Daniel Lewis something was missing from his
UPnP diagram: a way to modify the Model.
aka: a Controller / Actions.

You are right, technically an agent like ODE ( assuming you can hook
in actions ) is all that you need to allow users to interact with
linked data.

Let's say that this sort of solution can cover 80% of user interaction
cases ( launching simple actions and direct manipulation of resources
), and operates on top of 80% of data ( anything that can be published
as linked data/SPARQL and fits within the expressiveness of RDF's
abstract model ).
Not a bad MVC structure at all!

So, how do you plan on hooking up the actions to the "shell", is this
in the cartridges?
How will they surface. Context menu?

>
> We've tried to focus on the foundation infrastructure that uses HTTP for the
> messaging across M-V-C so that you get:
> M<--http->V<---http--->C
>
> Unfortunately, our focus on the M&C doesn't permeate. Instead, we find all
> focus coming at us from the "V" part where we've released minimal templates
> with hope that 3rd parties will eventually focus on Display Cartridges (via
> Fresnel, XSLT+SPARQL, xml+xslt+css, etc..).

Well. The M part is the data, isn't it? ( so it is permeating, people
are publishing data ).
Unless you mean building some higher functionality services ( on top
of SPARQL and RDF ) such as faceters, free text search, IFP
resolution, etc. But in that case it is also moving forward, although
not with a standardized interface.
This could be thought of as higher level Data Access components.

The C part... that's another story.
As I pointed out before, you need to define the way and an environment
to hook in the actions. What is the "shell"?

For example, you could provide a JS API for ODE where developers could
hook up methods using Adenine like signatures ( which, if I remember
correctly, use rdf:type hinting ) and then surface them on the context
menu.
Or perhaps a server side registry of actions is more suitable.

Many options here. I am curious about the Action Cartridges.

Best solution overall should be agent independent ( and here we go
down the SWS road once again ).


>
> btw - David Schwabe [1] also alluded to the architectural modularity that I
> am fundamentally trying to bring to broader attention in this evolving
>  conversation re.  Linked oriented Web applications.
>
> The ultimate goal is to deliver a set of options that enable Web Users to
> Explore the Web coherently and productively (imho).

And that will eventually be ( dynamically ) assembled to deliver the
functionality that today is present in walled garden applications.

>
> Humans can only do so much, and likewise Machines, put both together and we
> fashion a recipe for real "collective intelligence" (beyond  the buzzword).
>  We desperately need to tap into "collective intelligence"en route to
> solving many of the real problems facing the world today.
>
> The Web should make seeing and connecting the dots easier, but this is down
> to the MVC combo as opposed to any single component of the pattern  :-)

Aha, and I think in this case the V and C part of the triad will be
much more in flux. It's the transport ( HTTP ) and the big M ( GGG )
that keeps everything together.

Best,
A

>
>
> Links:
>
> 1. http://lists.w3.org/Archives/Public/public-lod/2008Aug/att-0106/00-part
>
> --
>
>
> Regards,
>
> Kingsley Idehen       Weblog: http://www.openlinksw.com/blog/~kidehen
> President & CEO OpenLink Software     Web: http://www.openlinksw.com
>
>
>
>
>



-- 
:::: Aldo Bucchi ::::
+56 9 7623 8653
skype:aldo.bucchi
http://aldobucchi.com/

Received on Thursday, 21 August 2008 05:50:39 UTC