On Mon, Nov 12, 2012 at 5:46 PM, Andy Seaborne <[email protected]> wrote:
> On 09/11/12 09:56, Rupert Westenthaler wrote: > >> RDF libs: >> ==== >> >> Out of the viewpoint of Apache Stanbol one needs to ask the Question >> if it makes sense to manage an own RDF API. I expect the Semantic Web >> Standards to evolve quite a bit in the coming years and I do have >> concern that the Clerezza RDF modules will be updated/extended to >> provide implementations of those. One example of such an situation is >> SPARQL 1.1 that is around for quite some time and is still not >> supported by Clerezza. While I do like the small API, the flexibility >> to use different TripleStores and that Clerezza comes with OSGI >> support I think given the current situation we would need to discuss >> all options and those do also include a switch to Apache Jena or >> Sesame. Especially Sesame would be an attractive option as their RDF >> Graph API [1] is very similar to what Clerezza uses. Apache Jena's >> counterparts (Model [2] and Graph [3]) are considerable different and >> more complex interfaces. In addition Jena will only change to >> org.apache packages with the next major release so a switch before >> that release would mean two incompatible API changes. >> > > Jena isn't changing the packaging as such -- what we've discussed is > providing a package for the current API and then a new, org.apache API. > The new API may be much the same as the existing one or it may be > different - that depends on contributions made! > I didn't know about jena planning to introduce such a common API. > > I'd like to hear more about your experiences esp. with Graph API as that > is supposed to be quite simple - it's targeted at storage extensions as > well as supporting the richer Model API. Personally, aside from the fact > that Clerreza enforces slot constraints (no literals as subjects), the Jena > Graph API and Clerezza RDF core API seem reasonably aligned. > Yes the slot constraints comes from the RDF abstract syntax. In my opinion it's something one could decide to relax, by adding appropriate owl:sameAs bnode any graph could be transformed to an rdf-abstract-syntax compliant one. So maybe have a GnereicTripleCollection that can be converted to an RDFTRipleCollection - not sure. Just sticking to the spec and wait till this is allowed by the abstract syntax might be the easiest. Where I see advantages of the clerezza API: - Bases on collections framework so standard tools can be used for graphs - Immutable graphs follow identity criterion of RDF semantics, this allows graph component to be added to sets and more straight forwardly implement diff and patch algorithms - BNode have no ids: apart from promoting the usage of URIs where this is appropriate it allows behind the scenes leanification and saves memory where the backend doesn't hast such ids. > > (for generalised systems such as rules engine - and for SPARQL - triples > can arise with extras like literals as subjects; they get removed later) If this shall be an API for interoperability based on RDF standard I'm wonder if is shall be possible to expose such intermediate constructs. Reto
