W3C home > Mailing lists > Public > public-lod@w3.org > November 2010

Re: Model Semantics, Representation Syntax, and Systems Integration

From: Alan Ruttenberg <alanruttenberg@gmail.com>
Date: Wed, 10 Nov 2010 16:46:56 -0500
Message-ID: <AANLkTiknq8WGAXhefq2H+d5GPzL7axTri3EysXkR6OY_@mail.gmail.com>
To: Kingsley Idehen <kidehen@openlinksw.com>
Cc: "public-lod@w3.org" <public-lod@w3.org>
On Wed, Nov 10, 2010 at 4:20 PM, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>> Again, I don't agree that interchange formats are "negotiable". They
>> need to be standardized, and they need to be adopted, lest there be
>> (very uninteresting, but very real) obstructions to interchange.
> This is were we differ.

I'm not sure we differ, or are talking about the same thing.

> I think we can have exemplars e.g. RDFa, RDF/XML etc.. But global adoption
> will always be mercurial. Thus, middleware will always have a vital role.

I'm not sure I would call these exemplars. They are standards, which
means that they have (at least via the process that these were created
by) had many eyes look at them and there is a reasonable chance that
they are well specified.

> Middleware will basically play the babelfish role.

No objection to Middleware *helping*. But it isn't enough. You want to
have the *option* of making your software not *depend* on a vendor
(however fond I am of this particular vendor :)

It isn't feasible for each project to support all formats. So for
projects that want to do this (and there are a lot) it should be the
case that they can be able to emit and absorb something that will
predictably work.

> As you know, this is exactly what the Virtuoso Sponger has always been
> about. That's why we nested it deeply in the Virtuoso SPARQL engine etc..

We like the sponger :)
However note that there are issues. The translations that the sponger
makes are not reviewed or documented with the same rigor that
standards are. So there is an element of uncertainty in using the
result from the sponger. That matters more or less depending on what
the application you are building is.

>> The format issue is mostly a solved problem, IMO. Yes angle
>> brackets are ugly, but what really matters is that a decision was
>> made.
> Solved, but via middleware. Thus, middleware (wrapper) developers need to
> grok the opportunity at hand. Outside middleware realm, developer are
> ultimately aligned to syntax.

No question that middleware provides good opportunities on the side of
the consumer, and is a good proposition from a business point of view
in many cases.

But, as I said, there are important applications that will not be
constructed in this way, and as an architectural principle we should
be creating systems that are based on well-defined standards, and
clear semantics.

So: Market middleware? Yes. Take advantage of middleware when
appropriate? Yes. Have an architectural dependence on middleware? No.

Received on Wednesday, 10 November 2010 21:47:47 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:29:51 UTC