[9]                             home                             [11]

 

Wednesday, April 12, 2006

Anticipatory Web discussionà [home]

Anticipatory Web Challenge Problem à [link]

SOA CoP wiki

 

 

Community Centric Service Methodology Glass Bead Games

 

 

 

 

Communication from Reto

 

Good morning,

 

> Paul stated:

> Has anyone at DERI or elsewhere addressed the relationships between REST and triple space?

 

 

The primary idea of Dieter Fensel for the concept of Triple Space Computing was highly motivated by the work of Roy Fielding. The principle is clearly to have a Web service communication and coordination layer/middleware that has a close relationship to the fundamental reasons for REST.

 

We did however never extensively work out comparisons (yet) between the REST architectural style and the Triple Space Computing architecture. We are however highly inspired by the WWW architecture and technologies and thus by REST.

 

We aim however at an infrastructure that alters (and hopefully improves) the basic publish and read style of the Web.

 

I recently also posted a short presentation about the current efforts of the TSC project on the project website http://tsc.deri.at/pub.html

 

I hope I can help a bit. Please get back to me and may be concretizes your question. In what respect you care about the relationship of REST and TSC? What aspects would interest you more?

 

> Paul stated:

 

> The persistent publish and read feature of the RDF triple can be used to

> define a system of finite state machines with interfaces (between

> namespaces) where iterative processes (such as orchestration and discovery)

> are occurring.

>

> The triple space is then a set of finite state machines completely defined

> by RDF triples and having a tight referential linkage to URI and through the

> URI to a unique ID for resources.

>

> If the world were fully deterministic and process exchanges fixed, then we

> would have the end of the story of how to create a web of information that

> was fully interoperable.

>

> comment?

 

As Brahmanda pointed out there are a set of unclear issues also to me.

 

              * what do you expect to be the interfaces of FSM?

              * do you expect the interfaces to interlink triple graphs of different

                namespaces?

 

In general I have however the feeling that my goal would be something very similar to what you just stated.

 

We currently very much favor the idea of J.J Carroll and are hence referencing Named Graphs (thus having an information set of RDF triples and a corresponding URI as data model). Hence I could imagine that one state corresponds to one Named Graph (in its simplest form) and that thus through a mechanism of interlinking graphs (URI and rdfs:seeAlso-like linkage) it would be possible to model workflows of linked RDF graphs; i.e., in a way the definition of a FSM.

 

 

Do you agree with this idea to some extent?

 

In consequence, by deterministically knowing the graphs that will be published, read and taken it would be easily possible to provide interoperation (i.e. coordination) of services through the use of Triple Spaces and Named Graphs. That would however also require the a priori knowledge of all graph names of a defined FSM - deterministic graph names though.

 

Hope this helps to continue the discussion.

 

 

 

Thank you,

 

Reto

 

--

dipl.ing.EPFL

Reto Krummenacher, Project Assistant

 

Digital Enterprise Research Institute (DERI)

University of Innsbruck