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 2012/10/11 23:10:25 UTC
Next releases
Hi,
I am investigating the components that should go for a release in the
near future. We should try to bring as much components to a 1.0 status
as possible. After graduation it would be a good sign to start and
establish a release cycle.
My first release candidate would be the Enhancer with all Enhancement
Engines. So I will check the Enhancer and engines if all requirements
for a release are met (license, POMs, etc).
What about other components? Please, make suggestions as I do not have
a detailed overview of the status of all the code parts and branches.
Best,
- Fabian
--
Fabian
http://twitter.com/fctwitt
Re: Next releases
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
Hi Fabian,
the ontology manager could use a release, there are many new features
since 0.9.0-incubating.
plus, there's the OntoNet API renaming issue underway, so perhaps this
could be an intermediate release with both APIs for some backwards
compatibility, and then a further release will phase out the deprecated API.
note however that it requires an updated commons.owl too, but it's even
better to have it with the OWL API from Maven-central (waiting for a
compatible OWL 2 reasoner [1]). Also the reasoners.web bundle should be
re-released.
Do we make releases for specific commons at all?
I think November would be good for submitting RC's. Right now I'm busy
writing my thesis, then I plan to finalize the API renaming and add a
few more unit/integration tests so I can check some details in the
improved features and close their tickets.
Alessandro
[1]
http://sourceforge.net/mailarchive/forum.php?thread_name=CAD2jOMN2YegVbJTchud-U4YQCzbyo%2B%3DJhciO7sYD%2Btg0U5A3Yg%40mail.gmail.com&forum_name=owlapi-developer
On 10/11/12 11:10 PM, Fabian Christ wrote:
> Hi,
>
> I am investigating the components that should go for a release in the
> near future. We should try to bring as much components to a 1.0 status
> as possible. After graduation it would be a good sign to start and
> establish a release cycle.
>
> My first release candidate would be the Enhancer with all Enhancement
> Engines. So I will check the Enhancer and engines if all requirements
> for a release are met (license, POMs, etc).
>
> What about other components? Please, make suggestions as I do not have
> a detailed overview of the status of all the code parts and branches.
>
> Best,
> - Fabian
>
--
M.Sc. Alessandro Adamou
Alma Mater Studiorum - Università di Bologna
Department of Computer Science
Mura Anteo Zamboni 7, 40127 Bologna - Italy
Semantic Technology Laboratory (STLab)
Institute for Cognitive Science and Technology (ISTC)
National Research Council (CNR)
Via Nomentana 56, 00161 Rome - Italy
"I will give you everything, just don't demand anything."
(Ettore Petrolini, 1917)
Not sent from my iSnobTechDevice
Re: Next releases
Posted by Fabian Christ <ch...@googlemail.com>.
2012/10/16 Alessandro Adamou <ad...@cs.unibo.it>:
> Hi,
>
> I have a question on the release policy.
>
> The criterion for releasing a standalone module is that it has to be working
> on the latest launcher released (the 0.9.0-incubating one iirc)? Or can we
> assume it to be working on a compiled launcher from a certain more recent
> trunk revision?
Releasing components and launcher configurations are two separate
things. We should aim for releasing a stable launcher configuration
that only includes released components. That is the plan for the
stable launcher. This launcher is supposed to use only released
components. At the moment we are missing correct releases of
bundlelist that would enable us to create such a stable launcher.
At the moment it is just fine if everything is working in the SNAPSHOT
full launcher. We do not have any other criteria, yet.
> If so should/can we release up-to-date dependencies along with the module
> itself or call for separate releases?
When releasing a component all of its SNAPSHOT dependencies have to be
released. If your component has dependencies e.g. to commons
components, then those need to be released as well.
We can call a vote for a component release that includes releases of
commons components.
I would just like to separate releases of the main components, i.e.
entityhub, contenthub, enhancer, ontologymanager.
Best,
- Fabian
Re: Next releases
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
Hi,
I have a question on the release policy.
The criterion for releasing a standalone module is that it has to be
working on the latest launcher released (the 0.9.0-incubating one iirc)?
Or can we assume it to be working on a compiled launcher from a certain
more recent trunk revision?
If so should/can we release up-to-date dependencies along with the
module itself or call for separate releases?
Thanks
Alessandro
On 10/11/12 11:10 PM, Fabian Christ wrote:
> Hi,
>
> I am investigating the components that should go for a release in the
> near future. We should try to bring as much components to a 1.0 status
> as possible. After graduation it would be a good sign to start and
> establish a release cycle.
>
> My first release candidate would be the Enhancer with all Enhancement
> Engines. So I will check the Enhancer and engines if all requirements
> for a release are met (license, POMs, etc).
>
> What about other components? Please, make suggestions as I do not have
> a detailed overview of the status of all the code parts and branches.
>
> Best,
> - Fabian
>
--
M.Sc. Alessandro Adamou
Alma Mater Studiorum - Università di Bologna
Department of Computer Science
Mura Anteo Zamboni 7, 40127 Bologna - Italy
Semantic Technology Laboratory (STLab)
Institute for Cognitive Science and Technology (ISTC)
National Research Council (CNR)
Via Nomentana 56, 00161 Rome - Italy
"I will give you everything, just don't demand anything."
(Ettore Petrolini, 1917)
Not sent from my iSnobTechDevice
Re: Next releases
Posted by Rupert Westenthaler <ru...@gmail.com>.
Hi all
On Fri, Oct 12, 2012 at 5:48 PM, ajs6f@virginia.edu <aj...@virginia.edu> wrote:
> Thanks for that detailed answer. Don't worry, I understand that the notion of yard is specific to the EntityHub-- I was just using it as an analogy.
>
The current Entityhub Yard implementations will be used as backend for
SemanticIndex implementations with the new System. In fact very
similar as the Yard interface is already used by the Entityhub
Indexing Tool - as an indexing destination.
>
> I have one other question about this specific effort: in IndexingSource I find the important method:
>
> Item get(String uri) throws StoreException
>
> so it seems that this interface is meant to be used synchronously in direct operation, when get() doesn't block for any long time waiting for a large datum to transit or for slow storage to produce results. In order to use this gear in these cases, would it be necessary to rewrite the upper-level component "Content Create/Update"? Or could one expect to create a kind of queuing component and wire it between "Content Create/Update" and "Content Item Storage", maintaining synchronous behavior in the upper level of architecture?
That is true. The intended usage of the interfaces of the
semanticindexing module is synchronous. If necessary the semantic
indexing process as a whole can be implemented to be asynchronously
(e.g. use a queue that is processed by multiple worker threads).
As mentioned in my other mail, the first release of the
semanticindexing module together with the Contenthub will most likely
not include a general implementation of the indexing process, but I
plan to implement such a component as part of the adaption of the
Entityhub to the new system. As the Entityhub Indexing Tool already
uses a multi threaded producer/consumer based indexing pipeline I
might likely start from their.
Note the description of the "indexing process" is included in my mail
about the "Stanbol Semantic Indexing" module.
best
Rupert
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: Next releases
Posted by "ajs6f@virginia.edu" <aj...@virginia.edu>.
Thanks for that detailed answer. Don't worry, I understand that the notion of yard is specific to the EntityHub-- I was just using it as an analogy.
I do have a further question about general architecture: there exists currently a CMSAdaptor service that aims to map content repositories and semantic stores into each other. Is there an intention of cohering the abstractions for content storage and semantic storage between these two efforts (ContentHub and CMSAdaptor)? I realize that the intentions of each are distinct, but it seems that much of the underlying machinery might be reusable, and it might help integrators (like me {grin}) if they both could be addressed with a minimum of "glue", in cases where the semantic store is suitable for both indexing and ontology storage. If it's not obvious, I'd like to imagine a design in which a content repository is both indexed and typed by Stanbol services into the same semantic storage.
I have one other question about this specific effort: in IndexingSource I find the important method:
Item get(String uri) throws StoreException
so it seems that this interface is meant to be used synchronously in direct operation, when get() doesn't block for any long time waiting for a large datum to transit or for slow storage to produce results. In order to use this gear in these cases, would it be necessary to rewrite the upper-level component "Content Create/Update"? Or could one expect to create a kind of queuing component and wire it between "Content Create/Update" and "Content Item Storage", maintaining synchronous behavior in the upper level of architecture?
---
A. Soroka
Software & Systems Engineering :: Online Library Environment
the University of Virginia Library
On Oct 12, 2012, at 11:27 AM, Suat Gonul wrote:
> Hi,
>
> On 10/12/2012 5:57 PM, ajs6f@virginia.edu wrote:
>> Do I understand rightly that one eventual consequence of this architecture will be that content items might be stored in some external service with a standardized interface (say, a JCR repository) and semantic-indexed into another external service?
>
> Exactly, this kind of Store implementation would wrap the nodes in a JCR
> repository as ContentItems and those ContentItems would be indexed in
> different SemanticIndexes. We have a plan to provide a basic JCR
> compliant Store implementation in the following months.
>
>>
>> The diagram attached to the main issue shows Solr as the implementing component for the semantic-index. Is there expected to be a possibility to use an RDF store in that role? (In the way that one can choose Solr or Clerezza to back a yard in the the EntityHub?)
>
> This is also correct. We are already working on a Clerezza based
> SemanticIndex implementation, although it is not a yard managed by the
> Entityhub.
>
>>
>> Lastly, can you point me to the interfaces that will be actually be used to store an item? The reason I am asking is that I am wondering about asynchronizing behavior (for example, for very large content items or very high-latency storage).
>
> Sure. We have three main interfaces for the time being:
>
> * IndexingSource[1]: Read-only indexing source to be used by the
> SemanticIndex implementations.
> * Store[2]: An extension for the IndexingSource interface providing
> create and delete operations.
> * SemanticIndex[3]: The interface describing methods to semantically
> index items
>
> You can find the current implementations for these interface for the
> ContentItem type in the following links:
>
> * FileStore[4]: This Store implementation serializes ContentItems into
> the zip files and store in the file system.
> * SolrSemanticIndex[5]: This is a Solr based SemanticIndex
> implementation.
>
> Please note that the current state of these won't compile successfully
> since I didn't have time to adjust dependency versions according to
> latest changes in the trunk.
>
> Best,
> Suat
>
> [1]
> https://svn.apache.org/repos/asf/stanbol/branches/contenthub-two-layered-structure/commons/semanticindex/servicesapi/src/main/java/org/apache/stanbol/commons/semanticindex/store/IndexingSource.java
> [2]
> https://svn.apache.org/repos/asf/stanbol/branches/contenthub-two-layered-structure/commons/semanticindex/servicesapi/src/main/java/org/apache/stanbol/commons/semanticindex/store/Store.java
> [3]
> https://svn.apache.org/repos/asf/stanbol/branches/contenthub-two-layered-structure/commons/semanticindex/servicesapi/src/main/java/org/apache/stanbol/commons/semanticindex/index/SemanticIndex.java
> [4]
> https://svn.apache.org/repos/asf/stanbol/branches/contenthub-two-layered-structure/contenthub/store/file/src/main/java/org/apache/stanbol/contenthub/store/file/FileStore.java
> [5]
> https://svn.apache.org/repos/asf/stanbol/branches/contenthub-two-layered-structure/contenthub/index/src/main/java/org/apache/stanbol/contenthub/index/solr/SolrSemanticIndex.java
>
>> This looks like really excellent work!
>>
>> ---
>> A. Soroka
>> Software & Systems Engineering :: Online Library Environment
>> the University of Virginia Library
>>
>> On Oct 12, 2012, at 10:35 AM, Suat Gönül wrote:
>>
>>> Hi Stephane,
>>>
>>> The parent issue for this structure is STANBOL-471[1]. You can find an
>>> image within that issue representing the general structure offered by the
>>> 2-layered approach. The parent issue has some sub-issues. Especially, in
>>> STANBOL-498 and STANBOL-499, you can find detailed information regarding to
>>> the mentioned two layers. Once, I had written a mail mentioning about this
>>> structure at [2]. Please note that some of the class names have changed
>>> since that mail.
>>>
>>> The main purpose of this approach is to separate the storage and indexing
>>> functionalities of Contenthub. However, it seems that these changes can be
>>> adapted throughout the Stanbol.For instance, Rupert has already developed
>>> some Store implementations in the scope of Entityhub(see STANBOL-704),
>>> although they are not in the final state yet. This separation will allow to
>>> implement different SemanticIndex implementations for different use cases
>>> based on the same Store keeping some items. There can also be different
>>> Store implementations. For instance a Clerezza graph can be used as a Store
>>> or another Store implementation can be implemented as a bridge between
>>> Stanbol and a real content management system, etc.
>>>
>>> As solr version, we use the one specified in the parent pom.xml of the
>>> Stanbol. And it is currently 3.2.0.
>>>
>>> Hope this helps, best,
>>> Suat
>>>
>>> [1] https://issues.apache.org/jira/browse/STANBOL-471
>>> [2] http://markmail.org/message/o4quthsuubhlswtz
>>>
>>> On Fri, Oct 12, 2012 at 4:07 PM, Stéphane Gamard <
>>> stephane.gamard@searchbox.com> wrote:
>>>
>>>> Hi Suat,
>>>>
>>>> Can I ask you to point me to some doc about the 2-layer service? What
>>>> is its purpose? And another question is about the solr version used,
>>>> which one is it?
>>>>
>>>> Cheers,
>>>>
>>>> Stephane
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Oct 12, 2012, at 1:00 PM, Suat Gonul <su...@gmail.com> wrote:
>>>>
>>>>> Hi Fabian,
>>>>>
>>>>> I am planning to make a release for Contenthub. We have done some
>>>>> updates on the this component in the "trunk" since the 0.9.0-incubating
>>>>> release. However, as you know there is also a new structure for
>>>>> Contenthub in the "contenthub-two-layered-branch". Although, the work in
>>>>> the branch is still in progress and the changes in the trunk are not so
>>>>> much, I would like to make a release of Contenthub before merging that
>>>>> branch into to the trunk.
>>>>>
>>>>> Currently, we are doing some improvements on Contenthub in the trunk.
>>>>> Once that job is done, we can prepare a release. WDYT?
>>>>>
>>>>> Best,
>>>>> Suat
>>>>>
>>>>> On 10/12/2012 12:10 AM, Fabian Christ wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I am investigating the components that should go for a release in the
>>>>>> near future. We should try to bring as much components to a 1.0 status
>>>>>> as possible. After graduation it would be a good sign to start and
>>>>>> establish a release cycle.
>>>>>>
>>>>>> My first release candidate would be the Enhancer with all Enhancement
>>>>>> Engines. So I will check the Enhancer and engines if all requirements
>>>>>> for a release are met (license, POMs, etc).
>>>>>>
>>>>>> What about other components? Please, make suggestions as I do not have
>>>>>> a detailed overview of the status of all the code parts and branches.
>>>>>>
>>>>>> Best,
>>>>>> - Fabian
>>
>
Re: Next releases
Posted by Suat Gonul <su...@gmail.com>.
Hi,
On 10/12/2012 5:57 PM, ajs6f@virginia.edu wrote:
> Do I understand rightly that one eventual consequence of this architecture will be that content items might be stored in some external service with a standardized interface (say, a JCR repository) and semantic-indexed into another external service?
Exactly, this kind of Store implementation would wrap the nodes in a JCR
repository as ContentItems and those ContentItems would be indexed in
different SemanticIndexes. We have a plan to provide a basic JCR
compliant Store implementation in the following months.
>
> The diagram attached to the main issue shows Solr as the implementing component for the semantic-index. Is there expected to be a possibility to use an RDF store in that role? (In the way that one can choose Solr or Clerezza to back a yard in the the EntityHub?)
This is also correct. We are already working on a Clerezza based
SemanticIndex implementation, although it is not a yard managed by the
Entityhub.
>
> Lastly, can you point me to the interfaces that will be actually be used to store an item? The reason I am asking is that I am wondering about asynchronizing behavior (for example, for very large content items or very high-latency storage).
Sure. We have three main interfaces for the time being:
* IndexingSource[1]: Read-only indexing source to be used by the
SemanticIndex implementations.
* Store[2]: An extension for the IndexingSource interface providing
create and delete operations.
* SemanticIndex[3]: The interface describing methods to semantically
index items
You can find the current implementations for these interface for the
ContentItem type in the following links:
* FileStore[4]: This Store implementation serializes ContentItems into
the zip files and store in the file system.
* SolrSemanticIndex[5]: This is a Solr based SemanticIndex
implementation.
Please note that the current state of these won't compile successfully
since I didn't have time to adjust dependency versions according to
latest changes in the trunk.
Best,
Suat
[1]
https://svn.apache.org/repos/asf/stanbol/branches/contenthub-two-layered-structure/commons/semanticindex/servicesapi/src/main/java/org/apache/stanbol/commons/semanticindex/store/IndexingSource.java
[2]
https://svn.apache.org/repos/asf/stanbol/branches/contenthub-two-layered-structure/commons/semanticindex/servicesapi/src/main/java/org/apache/stanbol/commons/semanticindex/store/Store.java
[3]
https://svn.apache.org/repos/asf/stanbol/branches/contenthub-two-layered-structure/commons/semanticindex/servicesapi/src/main/java/org/apache/stanbol/commons/semanticindex/index/SemanticIndex.java
[4]
https://svn.apache.org/repos/asf/stanbol/branches/contenthub-two-layered-structure/contenthub/store/file/src/main/java/org/apache/stanbol/contenthub/store/file/FileStore.java
[5]
https://svn.apache.org/repos/asf/stanbol/branches/contenthub-two-layered-structure/contenthub/index/src/main/java/org/apache/stanbol/contenthub/index/solr/SolrSemanticIndex.java
> This looks like really excellent work!
>
> ---
> A. Soroka
> Software & Systems Engineering :: Online Library Environment
> the University of Virginia Library
>
> On Oct 12, 2012, at 10:35 AM, Suat Gönül wrote:
>
>> Hi Stephane,
>>
>> The parent issue for this structure is STANBOL-471[1]. You can find an
>> image within that issue representing the general structure offered by the
>> 2-layered approach. The parent issue has some sub-issues. Especially, in
>> STANBOL-498 and STANBOL-499, you can find detailed information regarding to
>> the mentioned two layers. Once, I had written a mail mentioning about this
>> structure at [2]. Please note that some of the class names have changed
>> since that mail.
>>
>> The main purpose of this approach is to separate the storage and indexing
>> functionalities of Contenthub. However, it seems that these changes can be
>> adapted throughout the Stanbol.For instance, Rupert has already developed
>> some Store implementations in the scope of Entityhub(see STANBOL-704),
>> although they are not in the final state yet. This separation will allow to
>> implement different SemanticIndex implementations for different use cases
>> based on the same Store keeping some items. There can also be different
>> Store implementations. For instance a Clerezza graph can be used as a Store
>> or another Store implementation can be implemented as a bridge between
>> Stanbol and a real content management system, etc.
>>
>> As solr version, we use the one specified in the parent pom.xml of the
>> Stanbol. And it is currently 3.2.0.
>>
>> Hope this helps, best,
>> Suat
>>
>> [1] https://issues.apache.org/jira/browse/STANBOL-471
>> [2] http://markmail.org/message/o4quthsuubhlswtz
>>
>> On Fri, Oct 12, 2012 at 4:07 PM, Stéphane Gamard <
>> stephane.gamard@searchbox.com> wrote:
>>
>>> Hi Suat,
>>>
>>> Can I ask you to point me to some doc about the 2-layer service? What
>>> is its purpose? And another question is about the solr version used,
>>> which one is it?
>>>
>>> Cheers,
>>>
>>> Stephane
>>>
>>> Sent from my iPhone
>>>
>>> On Oct 12, 2012, at 1:00 PM, Suat Gonul <su...@gmail.com> wrote:
>>>
>>>> Hi Fabian,
>>>>
>>>> I am planning to make a release for Contenthub. We have done some
>>>> updates on the this component in the "trunk" since the 0.9.0-incubating
>>>> release. However, as you know there is also a new structure for
>>>> Contenthub in the "contenthub-two-layered-branch". Although, the work in
>>>> the branch is still in progress and the changes in the trunk are not so
>>>> much, I would like to make a release of Contenthub before merging that
>>>> branch into to the trunk.
>>>>
>>>> Currently, we are doing some improvements on Contenthub in the trunk.
>>>> Once that job is done, we can prepare a release. WDYT?
>>>>
>>>> Best,
>>>> Suat
>>>>
>>>> On 10/12/2012 12:10 AM, Fabian Christ wrote:
>>>>> Hi,
>>>>>
>>>>> I am investigating the components that should go for a release in the
>>>>> near future. We should try to bring as much components to a 1.0 status
>>>>> as possible. After graduation it would be a good sign to start and
>>>>> establish a release cycle.
>>>>>
>>>>> My first release candidate would be the Enhancer with all Enhancement
>>>>> Engines. So I will check the Enhancer and engines if all requirements
>>>>> for a release are met (license, POMs, etc).
>>>>>
>>>>> What about other components? Please, make suggestions as I do not have
>>>>> a detailed overview of the status of all the code parts and branches.
>>>>>
>>>>> Best,
>>>>> - Fabian
>
Re: Next releases
Posted by Stéphane Gamard <st...@searchbox.com>.
Excellent and thank you, I was stuck on a thing device all day :).
Sent from my iPhone
On Oct 12, 2012, at 5:27 PM, Suat Gonul <su...@gmail.com> wrote:
> Hi,
>
> On 10/12/2012 5:57 PM, ajs6f@virginia.edu wrote:
>> Do I understand rightly that one eventual consequence of this architecture will be that content items might be stored in some external service with a standardized interface (say, a JCR repository) and semantic-indexed into another external service?
>
> Exactly, this kind of Store implementation would wrap the nodes in a JCR
> repository as ContentItems and those ContentItems would be indexed in
> different SemanticIndexes. We have a plan to provide a basic JCR
> compliant Store implementation in the following months.
>
>>
>> The diagram attached to the main issue shows Solr as the implementing component for the semantic-index. Is there expected to be a possibility to use an RDF store in that role? (In the way that one can choose Solr or Clerezza to back a yard in the the EntityHub?)
>
> This is also correct. We are already working on a Clerezza based
> SemanticIndex implementation, although it is not a yard managed by the
> Entityhub.
>
>>
>> Lastly, can you point me to the interfaces that will be actually be used to store an item? The reason I am asking is that I am wondering about asynchronizing behavior (for example, for very large content items or very high-latency storage).
>
> Sure. We have three main interfaces for the time being:
>
> * IndexingSource[1]: Read-only indexing source to be used by the
> SemanticIndex implementations.
> * Store[2]: An extension for the IndexingSource interface providing
> create and delete operations.
> * SemanticIndex[3]: The interface describing methods to semantically
> index items
>
> You can find the current implementations for these interface for the
> ContentItem type in the following links:
>
> * FileStore[4]: This Store implementation serializes ContentItems into
> the zip files and store in the file system.
> * SolrSemanticIndex[5]: This is a Solr based SemanticIndex
> implementation.
>
> Please note that the current state of these won't compile successfully
> since I didn't have time to adjust dependency versions according to
> latest changes in the trunk.
>
> Best,
> Suat
>
> [1]
> https://svn.apache.org/repos/asf/stanbol/branches/contenthub-two-layered-structure/commons/semanticindex/servicesapi/src/main/java/org/apache/stanbol/commons/semanticindex/store/IndexingSource.java
> [2]
> https://svn.apache.org/repos/asf/stanbol/branches/contenthub-two-layered-structure/commons/semanticindex/servicesapi/src/main/java/org/apache/stanbol/commons/semanticindex/store/Store.java
> [3]
> https://svn.apache.org/repos/asf/stanbol/branches/contenthub-two-layered-structure/commons/semanticindex/servicesapi/src/main/java/org/apache/stanbol/commons/semanticindex/index/SemanticIndex.java
> [4]
> https://svn.apache.org/repos/asf/stanbol/branches/contenthub-two-layered-structure/contenthub/store/file/src/main/java/org/apache/stanbol/contenthub/store/file/FileStore.java
> [5]
> https://svn.apache.org/repos/asf/stanbol/branches/contenthub-two-layered-structure/contenthub/index/src/main/java/org/apache/stanbol/contenthub/index/solr/SolrSemanticIndex.java
>
>> This looks like really excellent work!
>>
>> ---
>> A. Soroka
>> Software & Systems Engineering :: Online Library Environment
>> the University of Virginia Library
>>
>> On Oct 12, 2012, at 10:35 AM, Suat Gönül wrote:
>>
>>> Hi Stephane,
>>>
>>> The parent issue for this structure is STANBOL-471[1]. You can find an
>>> image within that issue representing the general structure offered by the
>>> 2-layered approach. The parent issue has some sub-issues. Especially, in
>>> STANBOL-498 and STANBOL-499, you can find detailed information regarding to
>>> the mentioned two layers. Once, I had written a mail mentioning about this
>>> structure at [2]. Please note that some of the class names have changed
>>> since that mail.
>>>
>>> The main purpose of this approach is to separate the storage and indexing
>>> functionalities of Contenthub. However, it seems that these changes can be
>>> adapted throughout the Stanbol.For instance, Rupert has already developed
>>> some Store implementations in the scope of Entityhub(see STANBOL-704),
>>> although they are not in the final state yet. This separation will allow to
>>> implement different SemanticIndex implementations for different use cases
>>> based on the same Store keeping some items. There can also be different
>>> Store implementations. For instance a Clerezza graph can be used as a Store
>>> or another Store implementation can be implemented as a bridge between
>>> Stanbol and a real content management system, etc.
>>>
>>> As solr version, we use the one specified in the parent pom.xml of the
>>> Stanbol. And it is currently 3.2.0.
>>>
>>> Hope this helps, best,
>>> Suat
>>>
>>> [1] https://issues.apache.org/jira/browse/STANBOL-471
>>> [2] http://markmail.org/message/o4quthsuubhlswtz
>>>
>>> On Fri, Oct 12, 2012 at 4:07 PM, Stéphane Gamard <
>>> stephane.gamard@searchbox.com> wrote:
>>>
>>>> Hi Suat,
>>>>
>>>> Can I ask you to point me to some doc about the 2-layer service? What
>>>> is its purpose? And another question is about the solr version used,
>>>> which one is it?
>>>>
>>>> Cheers,
>>>>
>>>> Stephane
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Oct 12, 2012, at 1:00 PM, Suat Gonul <su...@gmail.com> wrote:
>>>>
>>>>> Hi Fabian,
>>>>>
>>>>> I am planning to make a release for Contenthub. We have done some
>>>>> updates on the this component in the "trunk" since the 0.9.0-incubating
>>>>> release. However, as you know there is also a new structure for
>>>>> Contenthub in the "contenthub-two-layered-branch". Although, the work in
>>>>> the branch is still in progress and the changes in the trunk are not so
>>>>> much, I would like to make a release of Contenthub before merging that
>>>>> branch into to the trunk.
>>>>>
>>>>> Currently, we are doing some improvements on Contenthub in the trunk.
>>>>> Once that job is done, we can prepare a release. WDYT?
>>>>>
>>>>> Best,
>>>>> Suat
>>>>>
>>>>> On 10/12/2012 12:10 AM, Fabian Christ wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I am investigating the components that should go for a release in the
>>>>>> near future. We should try to bring as much components to a 1.0 status
>>>>>> as possible. After graduation it would be a good sign to start and
>>>>>> establish a release cycle.
>>>>>>
>>>>>> My first release candidate would be the Enhancer with all Enhancement
>>>>>> Engines. So I will check the Enhancer and engines if all requirements
>>>>>> for a release are met (license, POMs, etc).
>>>>>>
>>>>>> What about other components? Please, make suggestions as I do not have
>>>>>> a detailed overview of the status of all the code parts and branches.
>>>>>>
>>>>>> Best,
>>>>>> - Fabian
>>
>
Re: Next releases
Posted by "ajs6f@virginia.edu" <aj...@virginia.edu>.
Do I understand rightly that one eventual consequence of this architecture will be that content items might be stored in some external service with a standardized interface (say, a JCR repository) and semantic-indexed into another external service?
The diagram attached to the main issue shows Solr as the implementing component for the semantic-index. Is there expected to be a possibility to use an RDF store in that role? (In the way that one can choose Solr or Clerezza to back a yard in the the EntityHub?)
Lastly, can you point me to the interfaces that will be actually be used to store an item? The reason I am asking is that I am wondering about asynchronizing behavior (for example, for very large content items or very high-latency storage).
This looks like really excellent work!
---
A. Soroka
Software & Systems Engineering :: Online Library Environment
the University of Virginia Library
On Oct 12, 2012, at 10:35 AM, Suat Gönül wrote:
> Hi Stephane,
>
> The parent issue for this structure is STANBOL-471[1]. You can find an
> image within that issue representing the general structure offered by the
> 2-layered approach. The parent issue has some sub-issues. Especially, in
> STANBOL-498 and STANBOL-499, you can find detailed information regarding to
> the mentioned two layers. Once, I had written a mail mentioning about this
> structure at [2]. Please note that some of the class names have changed
> since that mail.
>
> The main purpose of this approach is to separate the storage and indexing
> functionalities of Contenthub. However, it seems that these changes can be
> adapted throughout the Stanbol.For instance, Rupert has already developed
> some Store implementations in the scope of Entityhub(see STANBOL-704),
> although they are not in the final state yet. This separation will allow to
> implement different SemanticIndex implementations for different use cases
> based on the same Store keeping some items. There can also be different
> Store implementations. For instance a Clerezza graph can be used as a Store
> or another Store implementation can be implemented as a bridge between
> Stanbol and a real content management system, etc.
>
> As solr version, we use the one specified in the parent pom.xml of the
> Stanbol. And it is currently 3.2.0.
>
> Hope this helps, best,
> Suat
>
> [1] https://issues.apache.org/jira/browse/STANBOL-471
> [2] http://markmail.org/message/o4quthsuubhlswtz
>
> On Fri, Oct 12, 2012 at 4:07 PM, Stéphane Gamard <
> stephane.gamard@searchbox.com> wrote:
>
>> Hi Suat,
>>
>> Can I ask you to point me to some doc about the 2-layer service? What
>> is its purpose? And another question is about the solr version used,
>> which one is it?
>>
>> Cheers,
>>
>> Stephane
>>
>> Sent from my iPhone
>>
>> On Oct 12, 2012, at 1:00 PM, Suat Gonul <su...@gmail.com> wrote:
>>
>>> Hi Fabian,
>>>
>>> I am planning to make a release for Contenthub. We have done some
>>> updates on the this component in the "trunk" since the 0.9.0-incubating
>>> release. However, as you know there is also a new structure for
>>> Contenthub in the "contenthub-two-layered-branch". Although, the work in
>>> the branch is still in progress and the changes in the trunk are not so
>>> much, I would like to make a release of Contenthub before merging that
>>> branch into to the trunk.
>>>
>>> Currently, we are doing some improvements on Contenthub in the trunk.
>>> Once that job is done, we can prepare a release. WDYT?
>>>
>>> Best,
>>> Suat
>>>
>>> On 10/12/2012 12:10 AM, Fabian Christ wrote:
>>>> Hi,
>>>>
>>>> I am investigating the components that should go for a release in the
>>>> near future. We should try to bring as much components to a 1.0 status
>>>> as possible. After graduation it would be a good sign to start and
>>>> establish a release cycle.
>>>>
>>>> My first release candidate would be the Enhancer with all Enhancement
>>>> Engines. So I will check the Enhancer and engines if all requirements
>>>> for a release are met (license, POMs, etc).
>>>>
>>>> What about other components? Please, make suggestions as I do not have
>>>> a detailed overview of the status of all the code parts and branches.
>>>>
>>>> Best,
>>>> - Fabian
>>>
>>
Re: Next releases
Posted by Suat Gönül <su...@gmail.com>.
Hi Stephane,
The parent issue for this structure is STANBOL-471[1]. You can find an
image within that issue representing the general structure offered by the
2-layered approach. The parent issue has some sub-issues. Especially, in
STANBOL-498 and STANBOL-499, you can find detailed information regarding to
the mentioned two layers. Once, I had written a mail mentioning about this
structure at [2]. Please note that some of the class names have changed
since that mail.
The main purpose of this approach is to separate the storage and indexing
functionalities of Contenthub. However, it seems that these changes can be
adapted throughout the Stanbol.For instance, Rupert has already developed
some Store implementations in the scope of Entityhub(see STANBOL-704),
although they are not in the final state yet. This separation will allow to
implement different SemanticIndex implementations for different use cases
based on the same Store keeping some items. There can also be different
Store implementations. For instance a Clerezza graph can be used as a Store
or another Store implementation can be implemented as a bridge between
Stanbol and a real content management system, etc.
As solr version, we use the one specified in the parent pom.xml of the
Stanbol. And it is currently 3.2.0.
Hope this helps, best,
Suat
[1] https://issues.apache.org/jira/browse/STANBOL-471
[2] http://markmail.org/message/o4quthsuubhlswtz
On Fri, Oct 12, 2012 at 4:07 PM, Stéphane Gamard <
stephane.gamard@searchbox.com> wrote:
> Hi Suat,
>
> Can I ask you to point me to some doc about the 2-layer service? What
> is its purpose? And another question is about the solr version used,
> which one is it?
>
> Cheers,
>
> Stephane
>
> Sent from my iPhone
>
> On Oct 12, 2012, at 1:00 PM, Suat Gonul <su...@gmail.com> wrote:
>
> > Hi Fabian,
> >
> > I am planning to make a release for Contenthub. We have done some
> > updates on the this component in the "trunk" since the 0.9.0-incubating
> > release. However, as you know there is also a new structure for
> > Contenthub in the "contenthub-two-layered-branch". Although, the work in
> > the branch is still in progress and the changes in the trunk are not so
> > much, I would like to make a release of Contenthub before merging that
> > branch into to the trunk.
> >
> > Currently, we are doing some improvements on Contenthub in the trunk.
> > Once that job is done, we can prepare a release. WDYT?
> >
> > Best,
> > Suat
> >
> > On 10/12/2012 12:10 AM, Fabian Christ wrote:
> >> Hi,
> >>
> >> I am investigating the components that should go for a release in the
> >> near future. We should try to bring as much components to a 1.0 status
> >> as possible. After graduation it would be a good sign to start and
> >> establish a release cycle.
> >>
> >> My first release candidate would be the Enhancer with all Enhancement
> >> Engines. So I will check the Enhancer and engines if all requirements
> >> for a release are met (license, POMs, etc).
> >>
> >> What about other components? Please, make suggestions as I do not have
> >> a detailed overview of the status of all the code parts and branches.
> >>
> >> Best,
> >> - Fabian
> >
>
Re: Next releases
Posted by Stéphane Gamard <st...@searchbox.com>.
Hi Suat,
Can I ask you to point me to some doc about the 2-layer service? What
is its purpose? And another question is about the solr version used,
which one is it?
Cheers,
Stephane
Sent from my iPhone
On Oct 12, 2012, at 1:00 PM, Suat Gonul <su...@gmail.com> wrote:
> Hi Fabian,
>
> I am planning to make a release for Contenthub. We have done some
> updates on the this component in the "trunk" since the 0.9.0-incubating
> release. However, as you know there is also a new structure for
> Contenthub in the "contenthub-two-layered-branch". Although, the work in
> the branch is still in progress and the changes in the trunk are not so
> much, I would like to make a release of Contenthub before merging that
> branch into to the trunk.
>
> Currently, we are doing some improvements on Contenthub in the trunk.
> Once that job is done, we can prepare a release. WDYT?
>
> Best,
> Suat
>
> On 10/12/2012 12:10 AM, Fabian Christ wrote:
>> Hi,
>>
>> I am investigating the components that should go for a release in the
>> near future. We should try to bring as much components to a 1.0 status
>> as possible. After graduation it would be a good sign to start and
>> establish a release cycle.
>>
>> My first release candidate would be the Enhancer with all Enhancement
>> Engines. So I will check the Enhancer and engines if all requirements
>> for a release are met (license, POMs, etc).
>>
>> What about other components? Please, make suggestions as I do not have
>> a detailed overview of the status of all the code parts and branches.
>>
>> Best,
>> - Fabian
>
Re: Next releases
Posted by Suat Gonul <su...@gmail.com>.
Hi Fabian,
I am planning to make a release for Contenthub. We have done some
updates on the this component in the "trunk" since the 0.9.0-incubating
release. However, as you know there is also a new structure for
Contenthub in the "contenthub-two-layered-branch". Although, the work in
the branch is still in progress and the changes in the trunk are not so
much, I would like to make a release of Contenthub before merging that
branch into to the trunk.
Currently, we are doing some improvements on Contenthub in the trunk.
Once that job is done, we can prepare a release. WDYT?
Best,
Suat
On 10/12/2012 12:10 AM, Fabian Christ wrote:
> Hi,
>
> I am investigating the components that should go for a release in the
> near future. We should try to bring as much components to a 1.0 status
> as possible. After graduation it would be a good sign to start and
> establish a release cycle.
>
> My first release candidate would be the Enhancer with all Enhancement
> Engines. So I will check the Enhancer and engines if all requirements
> for a release are met (license, POMs, etc).
>
> What about other components? Please, make suggestions as I do not have
> a detailed overview of the status of all the code parts and branches.
>
> Best,
> - Fabian
>