RE: JRDF - Announcement

As I see it, there are a number of reasons for a common API:

1/ Application portability, where application development is not making a
major commitment to one toolkit or another very early in the
design/development cycle.  Different SDKs have different strengths and foci.

2/ Shared concepts, enabling application developers to move their semantic
web skills between toolkits easily.

3/ Toolkit modularity, enabling different components, from different
developers, to be used within one framework.

There may well be others.

It would be good to get a sense of which problems are being addressed.  They
are all useful in their own ways but may lead in different directions.

- - - - -

Jena2 has two levels of API - the API Model, the application presentation
API provides a convenient programming paradigm; and the Graph API, which is
lower level and enables plugging together storage and inference engines.

In the Model API, resources know which more they are in so you can go
Resource.getProperty(someProp) and get the object value, or use the iterator
forms like Resource.listProperties(someProp).  There is an overhead in doing
this but it results in clearer code.  JRDF appears to be closer to Graph API
although the notion of the NodeFactory seems to tie nodes to a graph -
something we changed between Jena1 and Jena2 because it make inference hard.

I can't see how to find triples (0.2 JRDF) in Graphs - just add a triple,
remove a triple and test whether a triple is in a graph.  Is the
anticipation that this is done through a different API?

	Andy

Jena javadoc online:
http://jena.sourceforge.net/javadoc/index.html

> Andrew Newman wrote on 12/11/2003, 11:02 PM:
> I'd like any feedback on this, at all.  I'd especially be
> interested in other language support and which version of Java (I'd
> like to do a 1.5  specific API for example).
> Project page: http://jrdf.sf.net/

Received on Saturday, 20 December 2003 13:53:26 UTC