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

hello henry.

On 2012-08-07 14:43 , "Henry Story" <henry.story@bblfish.net> wrote:
>What if your metamodels are isomorphic? I think that is what you are
>saying. In which case yes, you can translate between each one of them
>without loss. That means that the choice is then no longer to be made at
>that level.

the important thing to keep in mind with metamodels is the ecosystem
backing them; ecosystems of developers, systems, software,
query/processing languages supporting them, and binding frameworks for
programming languages. sure i can map a relational model to a generalized
graph (and vice versa), but is it a cost-effective way for me to do when
all i need to do is perfectly well served in a relational world where i
can easily find millions of developers and a vast ecosystems of systems
and tools? there is a reason why there is a very rich ecosystem of
metamodels out there, despite the fact that you can always define mapping
rules.

>The next question is: where has the most work been done in building a
>metamodel that works with the Web? And the answer there is clear: RDF. It
>keeps things simple by sticking to plain relations, making it easy to
>learn, and uses URIs for the names of the entities and the relations,
>allowing us to build linked data and LDP, and it has even build a
>tradition of syntax agnosticism.

the more interesting question is: do we even need to tell people which
metamodel is good for them? the web thrives on media types and loose
coupling, and everybody is free to choose what they want to do internally
to manage their data (and what works best for them as a business decision,
as mentioned in the previous paragraph). all we need to tell people is
what kind of metamodel we're picking *for the service surface of the
functionality we are targeting with the platform*, and that does not need
to be the metamodel services use internally for what they're doing (and
for reaching directly into their data, SPARQL has an HTTP protocol and
thus this part is covered already). we *could* choose to say that we
require those metamodels to be the same, and then we start building
something specifically for a certain subset of service implementations,
but that's a choice we are free to make (and the WG decided that we do
want to focus on RDF-based implementations).

>So in my view there is no competition here. It's RDF which wins here for
>that reason. Those who wish to adapt another of their favorite metamodel
>can do that. When you have done the work, we can come back and discuss
>it.  (Just remember that it will be mappable to RDF anyway, so it's not
>so clear what the advantages would be.)

that seems a bit one-dimensional to me. saying that RDF is the best webby
metamodel and thus must be used is, at best, far-fetched. for example,
popularity might be one other interesting metric to look at, and there RDF
would not even move the scale. i am sure you could come up with many other
possible metrics. but we don't have to tell people what the best metamodel
for their data is, that's the beauty of media types.

but let's step back: the initial question raised by ashok and reza was
whether this WG intended to provide solutions that would not specifically
target RDF-centric scenarios, and all i was trying to say was that i would
have wished it decided to do that, but that recent discussions seemed to
indicate that the group preferred an RDF focus. that's a choice the WG has
every right to make, but it's not the only possible path we could take.

cheers,

dret.

Received on Tuesday, 7 August 2012 13:38:33 UTC