Re: Model Semantics, Representation Syntax, and Systems Integration

On 11/10/10 4:46 PM, Alan Ruttenberg wrote:
> 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 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

Received on Wednesday, 10 November 2010 22:17:37 UTC