incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmür <r...@apache.org>
Subject Re: Future of Clerezza and Stanbol
Date Mon, 12 Nov 2012 19:42:51 GMT
On Mon, Nov 12, 2012 at 5:46 PM, Andy Seaborne <andy@apache.org> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message