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

Aldo Bucchi wrote:
> 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?
>   
Everything lives in a REST or SOAP accessible Cartridge. ODE just talks 
REST or SOAP .

For instance, ODE uses REST calls to the Sponger Service when RDFizing, 
but it can just as well use Triplr. We've just put out a new ODE release 
with an improved "Preferences" dialog that makes the mixing and matching 
of Renderers and RDFizers clearer.

Re. Display Cartridges (Fresnel Templates) the same would apply, but in 
this case we just deal with the URIs of the templates. Ditto in the case 
of "Actions".

URIs and REST are all that we need fundamentally, which is just about 
leveraging what the Web has always offered.
>   
>> 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 ).
>   

Yes.
> 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.
>
>   
Correct, with Linked Data at the base. This is why I always refere to 
"Linked Data" as the foundation layer of the Semantic Web innovation 
continuum.

> 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"?
>   
ODE is an inner shell / enclave  example, but in reality the Web is the 
outer shell (as long as you honor links and link dereferencing). What is 
missing is a vocabulary for actions.

Example: if you combined GoodRelations Ontology and Web Services part of 
SIOC (the extended modules part)  you get a Linked Data Space that not 
only describes a service vendor, but also one that formally describes 
how to consummate a transaction with said vendor, with granularity at 
the service level (so two services with different signatures from a 
single vendor are discernable).
> 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.
>   
ODE will just have an interface for registering and configuring Actions. 
All it will need are the URIs for the Linked Data Spaces that describe 
the actions, and then from that present the configuration options to the 
user.
> 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 ).
>   
I don't know how to do agent specific stuff; everything we do is 
inherently open and standards based :-)
>
>   
>> 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.
>   

Amen!

Kingsley
> 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
>>
>>
>>
>>
>>
>>     
>
>
>
>   


-- 


Regards,

Kingsley Idehen	      Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO 
OpenLink Software     Web: http://www.openlinksw.com

Received on Thursday, 21 August 2008 13:46:15 UTC