You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@apache.org> on 2013/09/01 13:37:02 UTC

Capabilities

It's hard to find many uses in the main code base of capabilities.  I 
can only find two uses in main/java at all:

* use of sizeAccurate() in the isomorphism code
* findSafeContract() in RDF/XML writing.

Otherwise it's all in the testing code.

Oddly, it does not seem to be reflected in the Model API.

The Inf code seems to provide them - but is it used?

Conclusion: a feature that is not worth it.

I think the principle should be easy implementation for new storage 
systems.  A simple, straight forward graph interface would be the way to go.

This is not saying Capabilities are wrong - when the world was simpler, 
the idea of Capabilities made sense.  The overall system has moved on 
and is too complicated for the idea central set of features which are 
either provided or not.

e.g FileGraph - it claims to  provides transactions (which isn't even a 
capability! Details.).  Actually, the transaction contract is quite hard 
to provide and the code can be useful without full crash-resistance.


To support testing, there is an alternative of providing test suites 
that cover the ideal correctly, simple and cleanly.

If some subsystem wants to opt out of some tests, it inherits the tests 
and stubs out the parts it does not want to provide.  And documents it 
somewhere (FileGraph says it supports weak transactions).

@Test public void somefeature_01() { /* Choose not to support this */ }

Now, we have a test collection that is simpler and the responsibility is 
moved to the subsystem.  The test suite captures the true contract. 
there is no central concept of global variations.  It's very hard to 
define the right set of capabilities that is both general and reflects 
real choices.

e.g. TDB (nor SDB) never provided "minimal" or "complete" styles of 
reification (again, was not a capability!).  Both require additional 
persistent state to be kept and that is a huge amount of work for 
features that were, at best, rarely used.  They both simple stubbed out 
the tests that needed those modes.

Mode "standard" and is done by calculation only, no persistent state. 
Having seen the amount of work the RDB layer had to do to provide the 
features, it was clear to me it was not worth it and certainly not worth 
holding up release until every feature was done.

Where else can we simplify the base system?

	Andy

Re: Capabilities

Posted by Andy Seaborne <an...@apache.org>.
Chris,

What is the contract for 'findSafeContract'?

	Andy


Re: Capabilities

Posted by Claude Warren <cl...@xenei.com>.
I think of the capabilities as akin to the database metadata in JDBC
(though metadata is much larger), some people use it some don't but if you
don't you do so at your own risk.

I would like to keep it.

Claude


On Mon, Sep 2, 2013 at 9:31 AM, Chris Dollin
<ch...@epimorphics.com>wrote:

> On Sunday, September 01, 2013 12:37:02 PM Andy Seaborne wrote:
> > It's hard to find many uses in the main code base of capabilities.  I
> > can only find two uses in main/java at all:
> >
> > * use of sizeAccurate() in the isomorphism code
> > * findSafeContract() in RDF/XML writing.
>
> Capabilities were added as a way of allowing graphs to describe
> how far they went to meet some contracts, eg "you can't update
> me, no matter how hard you call add(Triple)". In practice no-one [1]
> bothered to query the capabilites before doing something that
> they were relevant to ...
>
> So "experiment that didn't work out" is likely the state of affairs
> and dropping capabilities is a good idea ... assuming we can
> find suitable replacements around findSafeContract and sizeAccurate
> (which might turn out to be documentation that says "don't do that!"
> for the iffy cases).
>
> Chris
>
> [1] Apart from some of the early Jena developers ...
>
> --
> RIP Diana Wynne Jones, 1934 - 2011.
>
> Epimorphics Ltd, http://www.epimorphics.com
> Registered address: Court Lodge, 105 High Street, Portishead, Bristol BS20
> 6PT
> Epimorphics Ltd. is a limited company registered in England (number
> 7016688)
>
>


-- 
I like: Like Like - The likeliest place on the web<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren

Re: Capabilities

Posted by Chris Dollin <ch...@epimorphics.com>.
On Sunday, September 01, 2013 12:37:02 PM Andy Seaborne wrote:
> It's hard to find many uses in the main code base of capabilities.  I 
> can only find two uses in main/java at all:
> 
> * use of sizeAccurate() in the isomorphism code
> * findSafeContract() in RDF/XML writing.

Capabilities were added as a way of allowing graphs to describe
how far they went to meet some contracts, eg "you can't update
me, no matter how hard you call add(Triple)". In practice no-one [1]
bothered to query the capabilites before doing something that
they were relevant to ...

So "experiment that didn't work out" is likely the state of affairs
and dropping capabilities is a good idea ... assuming we can
find suitable replacements around findSafeContract and sizeAccurate
(which might turn out to be documentation that says "don't do that!"
for the iffy cases).

Chris

[1] Apart from some of the early Jena developers ...

-- 
RIP Diana Wynne Jones, 1934 - 2011.

Epimorphics Ltd, http://www.epimorphics.com
Registered address: Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT
Epimorphics Ltd. is a limited company registered in England (number 7016688)