You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stanbol.apache.org by Fabian Christ <ch...@googlemail.com> on 2011/06/05 18:35:16 UTC

Sandbox for new components? Starting with FactStore implementation

Hi,

at the moment the Stanbol infrastructure is rather focused in entities
in texts. An extension would be to integrates component that can
handle the relations (facts) between entities. I would like to propose
a new component called a "Fact Store". The idea came up in the IKS
project and a specification proposal can be found at [1]. I would like
to start an implementation of such a component as part of Stanbol.

My question: Should we create a playground/sandbox in Stanbol SVN for
such new components that have at this stage a proof of concept
character and will hopefully emerge to mature components?

[1] https://docs.google.com/document/d/1vp8MN2e6Pv1nitHhACS0hDGnfV_YzS2M6JhsMbWYxrY/edit?hl=de&authkey=CNSg96YN

Best,
 - Fabian

-- 
Fabian

Re: Sandbox for new components? Starting with FactStore implementation

Posted by Fabian Christ <ch...@googlemail.com>.
2011/7/3 Olivier Grisel <ol...@ensta.org>:
> 2011/6/5 Fabian Christ <ch...@googlemail.com>:
>> Hi,
>>
>> at the moment the Stanbol infrastructure is rather focused in entities
>> in texts. An extension would be to integrates component that can
>> handle the relations (facts) between entities. I would like to propose
>> a new component called a "Fact Store". The idea came up in the IKS
>> project and a specification proposal can be found at [1]. I would like
>> to start an implementation of such a component as part of Stanbol.
>>
>> My question: Should we create a playground/sandbox in Stanbol SVN for
>> such new components that have at this stage a proof of concept
>> character and will hopefully emerge to mature components?
>>
>> [1] https://docs.google.com/document/d/1vp8MN2e6Pv1nitHhACS0hDGnfV_YzS2M6JhsMbWYxrY/edit?hl=de&authkey=CNSg96YN
>
> Hi sorry for the late reply. I see in the SVN that you are using derby
> for this. Why not directly using a clerezza graph? That would make it
> trivial to store and retrieve RDF events using either lowlevel sparql
> or the custom HTTP API that you describe in the specification
> document.
>
> Using a clerezza graph would furthermore make it trivial to
> interoperate at the data level with the other OSGi services of the
> platform.

My idea was just to store relationships between entities. And the
natural technology for relations and entities is a relational database
for me here. I don't really understand the benefits that an RDF graph
would give. But that may just be the case because I'm much more
familiar with entities and relations. Additionally, Rupert argued that
it would not be such a good idea for performance reasons to use a
triple graph for this. But also here - I didn't really understood the
details when and why this would really become a problem.

In summary, I decided to use a relational database because it was the
natural way for me to implement this. I see the point that it makes
things easier if all services operate on RDF graphs. At the moment
this FactStore implementation is a little experiment and I want to
figure out where the real problems are when you use it in
applications. Maybe it turns out that it was the wrong decision but I
want to try ;)

-- 
Fabian

Re: Sandbox for new components? Starting with FactStore implementation

Posted by Olivier Grisel <ol...@ensta.org>.
2011/6/5 Fabian Christ <ch...@googlemail.com>:
> Hi,
>
> at the moment the Stanbol infrastructure is rather focused in entities
> in texts. An extension would be to integrates component that can
> handle the relations (facts) between entities. I would like to propose
> a new component called a "Fact Store". The idea came up in the IKS
> project and a specification proposal can be found at [1]. I would like
> to start an implementation of such a component as part of Stanbol.
>
> My question: Should we create a playground/sandbox in Stanbol SVN for
> such new components that have at this stage a proof of concept
> character and will hopefully emerge to mature components?
>
> [1] https://docs.google.com/document/d/1vp8MN2e6Pv1nitHhACS0hDGnfV_YzS2M6JhsMbWYxrY/edit?hl=de&authkey=CNSg96YN

Hi sorry for the late reply. I see in the SVN that you are using derby
for this. Why not directly using a clerezza graph? That would make it
trivial to store and retrieve RDF events using either lowlevel sparql
or the custom HTTP API that you describe in the specification
document.

Using a clerezza graph would furthermore make it trivial to
interoperate at the data level with the other OSGi services of the
platform.

-- 
Olivier
http://twitter.com/ogrisel - http://github.com/ogrisel