Aldo Bucchi wrote:
Hello,
( replies inlined )
On Wed, Aug 20, 2008 at 9:19 PM, Kingsley Idehen <[EMAIL PROTECTED]> 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
