- From: Alan Ruttenberg <alanruttenberg@gmail.com>
- Date: Wed, 10 Nov 2010 16:46:56 -0500
- 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. -Alan
Received on Wednesday, 10 November 2010 21:47:47 UTC