On 11/10/10 4:46 PM, Alan Ruttenberg wrote:
On Wed, Nov 10, 2010 at 4:20 PM, Kingsley Idehen<[email protected]> 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 increasingly see RDF as a format. I am thinking beyond SemWeb
community. The model dimension I prefer is EAV.
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.
Exemplars because to others they may not be standards.
I understand your point, but W3C doesn't mean its a broadly accepted
standard.
The Web isn't ubiquitous because of the W3C. Of course, W3C effort will
protect and guide its evolution etc..
When pushing forward, the notion of a standard from a body doesn't
really work. History has show successes to be retrospective.
Example: Killer App. vs Killer User.
You can make Killer Users from new innovations. Over time, said Killer
Users may deem you innovations the Killer App. But that moniker will be
endowed retrospectively. I've never seen it work any other way.
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 :)
Naturally, so make a commitment to a conceptual model, negotiate the
formats that work for you when retrieving data from a data server.
The Case for RDF formats:
By the above I mean: RDF family of formats lead by RDFa and RDF/XML.
When people buy into EAV, they are going to first make up their own
formats (GData, OData etc..), but here's what going to happen
ultimately, they will try to reinvent one of the existing RDF formats.
That's how I anticipate the exemplars becoming standards via the
traditional de facto route. Why? Because the opportunity cost of being
left behind will become completely palpable.
Real World Examples?
Google & Yahoo! adopting GoodRelations and RDFa. Facebook and OpenGraph.
In all of these cases, each was some variant of a "No RDF zone" (that
includes Google even with R. Guha in place), for a variety of reasons.
RDFa is fast becoming normative re. normative format. Not because the
W3C said it should be so, but because the cost of it not being so has
become palpable (it's effect on business models has materialized).
It isn't feasible for each project to support all formats.
I agree, so when people try to reinvent RDF they will come to appreciate
RDF :-)
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.
Yes.
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.
Yes, including the fact that I haven't had the time to make a decent
presentation that explains:
1. What it is
2. Why it's important
3. How it works -- including why URIBurner is deliberately slow.
The translations that the sponger
makes are not reviewed or documented with the same rigor that
standards are.
Correct.
The whole idea behind the sponger is that people should make their own
Cartridges or tweak the ones we deliver gratis (fidelity varies widely
across the 80+ cartridges that we've developed).
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.
Yes.
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.
Yes, we agree.
We just need to mesh roadmaps to this destination.
In my experience, people have to feel some pain (e.g. reinventing RDF)
prior to appreciation.
So: Market middleware? Yes. Take advantage of middleware when
appropriate? Yes. Have an architectural dependence on middleware? No.
100% agreement!
-Alan
--
Regards,
Kingsley Idehen
President& CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
