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 Toy-Usecase challenge for comparing RDF APIs to wrap data (was Re: Future of Clerezza and Stanbol)
Date Mon, 12 Nov 2012 19:45:58 GMT
May I suggest the following toy-usecase for comparing different API
proposals (we know all API can be used for triple stores, so it seems
interesting how the can be used to expose any data as RDF and the Space
complexity of such an adapter):

Given

interface Person() {
 String getGivenName();
 String getLastName();
 /**
 * @return true if other is an instance of Person with the same GivenName
and LastName, false otherwise
 */
 boolean equals(Object other);
}

Provide a method

Graph getAsGraph(Set<Person> pesons);

where `Graph` is the API of an RDF Graph that can change over time. The
returned `Graph`shall (if possible) be backed by the Set passed as argument
and thus reflect future changes to that set. The Graph shall support all
read operation but no addition or removal of triples. It's ok is some
iteration over the graph result in a ConcurrentModficationException if the
set changes during iteration (as one would get when iterating over the set
during such a modification).

- How does the code look like?
- Is it backed by the Set and does the result Graph reflects changes to the
set?
- What's the space complexity?

Challenge accepted?

Reto

On Mon, Nov 12, 2012 at 6:11 PM, Andy Seaborne <andy@apache.org> wrote:

> On 11/11/12 23:22, Rupert Westenthaler wrote:
>
>> Hi all ,
>>
>> On Sun, Nov 11, 2012 at 4:47 PM, Reto Bachmann-Gmür <reto@apache.org>
>> wrote:
>>
>>> - clerezza.rdf graudates as commons.rdf: a modular java/scala
>>> implementation of rdf related APIs, usable with and without OSGi
>>>
>>
>> For me this immediately raises the question: Why should the Clerezza
>> API become commons.rdf if 90+% (just a guess) of the Java RDF stuff is
>> based on Jena and Sesame? Creating an Apache commons project based on
>> an RDF API that is only used by a very low percentage of all Java RDF
>> applications is not feasible. Generally I see not much room for a
>> commons RDF project as long as there is not a commonly agreed RDF API
>> for Java.
>>
>
> Very good point.
>
> There is a finite and bounded supply of energy of people to work on such a
> thing and to make it work for the communities that use it.   For all of us,
> work on A means less work on B.
>
>
> An "RDF API" for applications needs to be more than RDF. A SPARQL engine
> is not simply abstracted from the storage by some "list(s,p,o)" API call.
>  It will die at scale, where scale here includes in-memory usage.
>
> My personal opinion is that wrapper APIs are not the way to go - they end
> up as a new API in themselves and the fact they are backed by different
> systems is really an implementation detail.  They end up having design
> opinions and gradually require more and more maintenace as the add more and
> more.
>
> API bridges are better (mapping one API to another - we are really talking
> about a small number of APIs, not 10s) as they expose the advantages of
> each system.
>
> The ideal is a set of interfaces systems can agree on.  I'm going to be
> contributing to the interfacization of the Graph API in Jena - if you have
> thoughts, send email to a list.
>
>         Andy
>
> PS See the work being done by Stephen Allen on coarse grained APIs:
>
> http://mail-archives.apache.**org/mod_mbox/jena-dev/201206.**
> mbox/%3CCAPTxtVOMMWxfk2%**2B4ciCExUBZyxsDKvuO0QshXF8uKha**
> D8txXjA%40mail.gmail.com%3E<http://mail-archives.apache.org/mod_mbox/jena-dev/201206.mbox/%3CCAPTxtVOMMWxfk2%2B4ciCExUBZyxsDKvuO0QshXF8uKhaD8txXjA%40mail.gmail.com%3E>
>
>
>

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