Re: Modularization [Was - Re: LDP interfaces in Java (based on Jena and JAX-RS)]

hello reza.

thanks a lot for being so active! it's great to see that things are
picking up in the group, so far we haven't seen a whole lot of activity,
so having these kinds of discussions now is exactly the kind of thing we
should have during the starting phase of the group.

On 2012-08-06 23:12 , "Reza B'Far (Oracle)" <reza.bfar@oracle.com> wrote:
>1. Merging Kingsley's latest email bits "We are basically trying to work
>out a loosely coupled architecture for data object identification,
>representation, and access via:  1. URIs 2. Structured Data  3. RESTful
>interaction patterns."
>Is there a common meta-meta-model: commonalities in how the data is
>shaped (regardless of domain or application) that can form a common
>starting point for the "structured data" part of Kingsley's comments.
>Then, an extensibility mechanism can be build around
> it as well and the implementations (RDF, etc.) can provide mappings for
>implementation-specific-implementation to the generic extension mechanism
>so that there is complete decoupling.

the beauty of REST is that you don't need a common metamodel. all you need
is a media type for the service surface you're looking at, and a data
model and representation that is required *for the interactions in the
context of this media type*. you can still happily link to other media
types covering other interactions, so there is no need to have the
universal übermodel. REST essentially says "let a thousand metamodels
bloom", as long as they provide services for specific aspects based on a
standardized service surface.

>2. I think once the "data structure" (data model, abstraction model,
>whatever everyone ends up agreeing to call it) is resolved, I believe the
>behavioral design around URI's, REST, etc. will be far less complex since
>there is much
> more structure in the existing W3C standards (http, etc.) and related
>work (REST, etc.) that will constrain us from diverting from the goal.

my slightly cynical take-away from the discussions so far has been that it
seems like we're reinventing the atom landscape in RDF. it might look a
little different because the underlying metamodel will be a graphs and not
trees, but other than that, we're shooting for pretty much the same
scenarios.

>With that, it'd be great to hear thoughts around what the "data model"
>part may look like and what the various opinions are.  What are the key
>abstractions that we all agree on is needed in a successful linked
>infrastructure?

if that helps i could certainly give a walk-through of atom, atompub, and
related standards and present what they're doing, how they're doing it,
and what kind of mechanisms of web architecture they use to achieve their
goals.

cheers,

dret.

Received on Tuesday, 7 August 2012 08:01:08 UTC