You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stanbol.apache.org by Sebastian Schaffert <se...@salzburgresearch.at> on 2011/07/22 15:06:14 UTC
Proposal for Integration of Linked Media Framework in Apache Stanbol
Dear all,
following up the discussion in the community workshop in Paris, I would like to formally offer the integration of our Linked Media Framework into Apache Stanbol. The software is currently available under BSD license at the Google Code website at http://code.google.com/p/kiwi/. Here is a short summary of the functionality it can offer (mostly from the website where you can also find more in-detail documentation):
--- 8< ---- 8< ---
The Linked Media Framework is an easy-to-setup server application that bundles central Semantic Web technologies to offer advanced services. The Linked Media Framework consists of LMF Core and LMF Modules.
LMF Core
========
The core component of the Linked Media Framework is a Linked Data Server that allows to expose data following the Linked Data Principles:
* Use URIs as names for things.
* Use HTTP URIs, so that people can look up those names.
* When someone looks up a URI, provide useful information, using the standards (RDF, SPARQL).
* Include links to other URIs, so that they can discover more things.
The Linked Data Server implemented as part of the LMF goes beyond the Linked Data principles by extending them with Linked Data Updates and by integrating management of metadata and content and making both accessible in a uniform way. In addition to the Linked Data Server, the LMF Core also offers a SPARQL endpoint.
LMF Modules
===========
As extension for the LMF Core, we are working on a number of optional modules that can be used to extend the functionality of the Linked Media Server:
Implemented:
* LMF Semantic Search offers a highly configurable Semantic Search service based on Apache SOLR. Several semantic search indexes can be configured in the same LMF instance using an RDF Path Language that allows traversal over several Linked Data sources.
* LMF Linked Data Cache implements a cache to the Linked Data Cloud that is transparently used when querying the content of the LMF using either SPARQL or the Semantic Search component. In case a local resource links to a remote resource in the Linked Data Cloud and this relationship is queried, the remote resource will be retrieved in the background and cached locally.
* LMF Reasoner implements a rule-based reasoner that allows to process Datalog-style rules over RDF triples; the LMF Reasoner is based on the reasoning component developed in the KiWi project, the predecessor of the LMF
Under Progress:
* LMF Permissions implements and extends the WebID and WebACL specifications for standards-conforming authentication and access control in the Linked Media Framework. (state: almost completed)
* LMF Enhancer offers semantic enhancement of content by analysing textual and media content; the LMF Enhancer will build upon the Apache Stanbol framework (state: started)
* LMF Media Interlinking will implement support for multimedia interlinking based on the work in the W3C Multimedia Fragments WG and theW3C Multimedia Annotations WG
* LMF Versioning implements versioning of metadata updates; versioning itself is already carried out by LMF Core, but the management of versions will be carried out by this module (state: started)
--- 8< ---- 8< ---
As far as I can see, Apache Stanbol and the Linked Media Framework currently cover mostly complementary areas and I think that a combination could be of benefit for both projects. In particular, I would think that the Linked Media Framework can also offer an almost ready implementation of the Stanbol Content Hub, as well as a free reasoner and full Linked Data capabilities (server as well as client) and Semantic Search.
Last but not least it is also of strategic interest for the KMT group at Salzburg Research to (1) integrate the technologies developed in the group, and (2) avoid duplication of effort if it is not necessary.
What I can offer is that - following a discussion on the mailinglist - we donate the LMF code base to Apache Stanbol and try integrating the two projects in the next months. Since the LMF is easily deployable as a .war file, a first step could be to deploy the web application inside Apache Stanbol as an OSGi web application. This could demonstrate the usefulness of the combination. Of course, in the course of the integration it would be necessary to isolate the individual modules of the LMF as separate components.
Difficulties I see at the moment (just to mention these...):
- technological issue: LMF is currently not using OSGi, but it uses a Gradle build system, Java 6 EE dependency injection (CDI) and a typical Java EE architecture which is incompatible with OSGi for now; one of our selling points is also "easy setup" and "lightweight", so I would not really like to change this for a complicated architecture ...
- license issue: LMF might still use libraries that are released under incompatible licenses, so this needs to be checked. In particular, Hibernate is still licensed under LGPL, and it is one of the core libraries of the LMF; porting to other persistence frameworks might require a lot of effort
- organisational issue: LMF is developed in several projects that have their specific goals; we will in some way need to still be able to follow our goals in these projects, e.g. by appropriate Stanbol extensions; all software developed in these projects is Open Source though...
Now let the discussion begin ... ;-)
Sebastian
--
| Dr. Sebastian Schaffert sebastian.schaffert@salzburgresearch.at
| Salzburg Research Forschungsgesellschaft http://www.salzburgresearch.at
| Head of Knowledge and Media Technologies Group +43 662 2288 423
| Jakob-Haringer Strasse 5/II
| A-5020 Salzburg
Re: Proposal for Integration of Linked Media Framework in Apache Stanbol
Posted by Sebastian Schaffert <se...@salzburgresearch.at>.
Dear Stefane, all,
thanks for your comments and welcome. Some replies in-line ;-)
Am 23.07.2011 um 20:36 schrieb Stefane Fermigier:
>
>
>> Difficulties I see at the moment (just to mention these...):
>> - technological issue: LMF is currently not using OSGi, but it uses a Gradle build system,
>
> OSGi is not a build system (ok, there is a build system specific to OSGi, called BND, and maybe that's what people who are really committed to OSGi should be using - but that's another story).
Sorry, I expressed myself not clearly. I know that OSGi is not a build system, the "but" should have been more like an "and". ;-)
>
> Stanbol uses Maven. I don't think there is anything fundamentally wrong with Gradle (and there are many things that are wrong with Maven, but that's also another story), but Maven is pretty much the standard, and it makes sense to migrate the LMF build system to Maven.
The main reason for us to take Gradle was that I was fed up with build systems that try to do simple things in complicated XML files. We are all software engineers, why not also write a build file in code? And Gradle offers this functionality very nicely. But of course we would switch to Maven. It is just that OSGi and Maven are the two main hurdles for us to take, because we are not very experienced in either. And we would need your help there :-)
>
> Apparently, there's a plugin for that, so that shouldn't be too much work:
>
> http://www.gradle.org/maven_plugin.html
>
>> Java 6 EE dependency injection (CDI) and a typical Java EE architecture which is incompatible with OSGi for now;
>
> Yes, this is probably more intrusive.
>
>> one of our selling points is also "easy setup" and "lightweight", so I would not really like to change this for a complicated architecture ...
>
> Some people would argue that there isn't much that's not "lightweight" with OSGi (OSGi services are just POJOs), and I don't think OSGi (for the part we're using in Stanbol at least), is more "complicated" that CDI. They probably should not be seen as competing, but as complementary approaches, and actually using DI with OSGi services is something that's already covered with SCR or iPOJO.
Yes, I think this is just our lack of experience with the technology and my rather bad experience with large frameworks (like Seam) in KiWi. We wanted to have an architecture were basically every Java developer could jump in without too much framework knowledge.
On the other hand I can very well see the advantages of an OSGi architecture, and if we can get some initial help I am pretty sure that we will quickly be quite fast in it.
> I don't have experience mixing CDI and OSGi, though (and that's something that could be useful for Nuxeo, so we're willing to investigate). Googling for "OSGi+CDI" gives some interesting links:
>
> http://blogs.oracle.com/sivakumart/entry/typesafe_injection_of_dynamic_osgi
> http://mathieuancelin.github.com/weld-osgi/
>
> So it's definitively something people are wanting to do.
Yes, and probably it is not too hard to achieve. The only major issue right now is that OSGi separates classpaths while CDI scans the classpath for services to register in JNDI when it starts up. As long as we only use injection inside a single OSGi module, there is probably not such a big issue.
>
>> - license issue: LMF might still use libraries that are released under incompatible licenses, so this needs to be checked. In particular, Hibernate is still licensed under LGPL, and it is one of the core libraries of the LMF; porting to other persistence frameworks might require a lot of effort
>
> I don't know what's the ASF view on Hibernate. What are the alternatives ? EclipseLink is a viable alternative, I think, but it's licensed under the EPL. Does the ASF have a JPA project that's mature enough to replace Hibernate (OpenJPA ?) ?
I never worked with OpenJPA, but it might be an alternative. In most parts, the persistence of the LMF is more or less separated from the logic anyways, and we could even write our own persistence layer (I actually considered this out of performance reasons, because Hibernate introduces a huge overhead). The most difficult part could be rewriting queries we are using, because HQL is more expressive than JPQL. But I think it is doable.
Greetings,
Sebastian
--
| Dr. Sebastian Schaffert sebastian.schaffert@salzburgresearch.at
| Salzburg Research Forschungsgesellschaft http://www.salzburgresearch.at
| Head of Knowledge and Media Technologies Group +43 662 2288 423
| Jakob-Haringer Strasse 5/II
| A-5020 Salzburg
Re: Proposal for Integration of Linked Media Framework in Apache Stanbol
Posted by Sebastian Schaffert <se...@salzburgresearch.at>.
Hi Bertrand,
Am 25.07.2011 um 10:44 schrieb Bertrand Delacretaz:
> On Mon, Jul 25, 2011 at 10:33 AM, Sebastian Schaffert
> <se...@salzburgresearch.at> wrote:
>> ....I can absolutely understand why people are not in love with Hibernate. Not
>> only is the license not fitting, it is also a much too complex piece of software,
>> and the community and developers are very unfriendly and unresponsive
>> when you have questions....
>
> And ORM is an anti pattern anyway ;-)
> http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern
I mostly agree, but the author misses one point: I think the main reason people are using ORM frameworks is the abstraction from the actual database vendors. And this is of course only necessary because database vendors failed to agree on a single SQL standard (well, they did, but they don't follow it).
If there was an easy way to get away with this problem, I would be the first to again implement my own model abstractions (as I did before ;-)).
Greetings,
Sebastian
--
| Dr. Sebastian Schaffert sebastian.schaffert@salzburgresearch.at
| Salzburg Research Forschungsgesellschaft http://www.salzburgresearch.at
| Head of Knowledge and Media Technologies Group +43 662 2288 423
| Jakob-Haringer Strasse 5/II
| A-5020 Salzburg
Re: Proposal for Integration of Linked Media Framework in Apache Stanbol
Posted by Stefane Fermigier <sf...@nuxeo.com>.
On Jul 25, 2011, at 12:41 PM, Sebastian Schaffert wrote:
> Dear Bertrand and Stefane,
>
> to get the thread back on-topic, some in-line replies ;-)
>
> Am 25.07.2011 um 11:38 schrieb Bertrand Delacretaz:
>
>> On Mon, Jul 25, 2011 at 11:20 AM, Stefane Fermigier <sf...@nuxeo.com> wrote:
>>> On Jul 25, 2011, at 10:44 AM, Bertrand Delacretaz wrote:
>>>> ...ORM is an anti pattern anyway ;-)
>>
>>> ...since Sebastian and his team made a great deal of effort to create their own ORM ("Object-RDF mapping")
>>> in the first place, we'd better acknowledge instead that "object-something mappings" are useful tools,
>>> with (as all tools) some limitations that one needs to be aware of...
>>
>> To me the main problem with SQL-to-object mappers is, as explained in
>> the seldo.com blog post, that if SQL is the wrong model for your data
>> (i.e. your data is not relational), mapping that to objects won't
>> help. I just creates more mess ;-)
>>
>> I haven't looked closely at what Sebastian's team have implemented in
>> this case, but an object to RDF mapping might make perfect sense if
>> RDF is the right model for your project and the mapped objects help
>> you access it. No impedance mismatch in that case.
>
>
> What we are really doing is an RDF-to-relational database mapping, and ORM is mainly the vehicle to create an abstraction from the different database vendors. It would not be so difficult to get rid of the ORM completely, because we are essentially just working with relational data.
OK, then you probably need some database abstraction layer, and not an ORM.
I don't know what's available in the Java world. In Python, we have SQLAlchemy which has both a database abstraction layer and an ORM, and you can use the former without the latter. This is viewed as a huge benefit of SQLAlchemy over other Python ORMs (at the expense of a slightly steeper learning curve).
There was an interesting discussion on this subject last week on Reddit:
http://www.reddit.com/r/Python/comments/iupwe/sqlalchemy_and_you/
OTOH, in the Java world, JPA is the standard (a good standard, I think, overall, and one with several implementations which is healthy). In the Python world there is no standard for ORM, so solutions are judged more on their technical merit that on adherence to a given standard.
OK, in the Java world there is another standard, JDO (http://en.wikipedia.org/wiki/Java_Data_Objects). I have never used it so I can't comment.
> Performance- and complexity-wise it would definately make sense. But we would loose database independence, an argument that was often brought before, because companies typically already have a certain database landscape, they have DBAs that are expert on one system, they have fast servers running already one system, backups in place, ...
Indeed. We at Nuxeo love Postgres, but also support, because that's what our customers ask for: MS SQL Server, Oracle and MySQL (+ H2 for tests). We will probably also support DB2 in the future.
For Stanbol to be used alongside Nuxeo in real-life projects, it's important (not a blocking issue, but not just a nice-to-have either) that Stanbol supports the same databases, or can be easily tuned to support new ones when needed.
S.
--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com/ - +33 1 40 33 79 87 - http://twitter.com/sfermigier
Join the Nuxeo Group on LinkedIn: http://linkedin.com/groups?gid=43314
New Nuxeo release: http://nuxeo.com/dm54
"There's no such thing as can't. You always have a choice."
Re: Proposal for Integration of Linked Media Framework in Apache Stanbol
Posted by Sebastian Schaffert <se...@salzburgresearch.at>.
Dear Bertrand and Stefane,
to get the thread back on-topic, some in-line replies ;-)
Am 25.07.2011 um 11:38 schrieb Bertrand Delacretaz:
> On Mon, Jul 25, 2011 at 11:20 AM, Stefane Fermigier <sf...@nuxeo.com> wrote:
>> On Jul 25, 2011, at 10:44 AM, Bertrand Delacretaz wrote:
>>> ...ORM is an anti pattern anyway ;-)
>
>> ...since Sebastian and his team made a great deal of effort to create their own ORM ("Object-RDF mapping")
>> in the first place, we'd better acknowledge instead that "object-something mappings" are useful tools,
>> with (as all tools) some limitations that one needs to be aware of...
>
> To me the main problem with SQL-to-object mappers is, as explained in
> the seldo.com blog post, that if SQL is the wrong model for your data
> (i.e. your data is not relational), mapping that to objects won't
> help. I just creates more mess ;-)
>
> I haven't looked closely at what Sebastian's team have implemented in
> this case, but an object to RDF mapping might make perfect sense if
> RDF is the right model for your project and the mapped objects help
> you access it. No impedance mismatch in that case.
What we are really doing is an RDF-to-relational database mapping, and ORM is mainly the vehicle to create an abstraction from the different database vendors. It would not be so difficult to get rid of the ORM completely, because we are essentially just working with relational data.
Performance- and complexity-wise it would definately make sense. But we would loose database independence, an argument that was often brought before, because companies typically already have a certain database landscape, they have DBAs that are expert on one system, they have fast servers running already one system, backups in place, ...
Greetings,
Sebastian
--
| Dr. Sebastian Schaffert sebastian.schaffert@salzburgresearch.at
| Salzburg Research Forschungsgesellschaft http://www.salzburgresearch.at
| Head of Knowledge and Media Technologies Group +43 662 2288 423
| Jakob-Haringer Strasse 5/II
| A-5020 Salzburg
Re: Proposal for Integration of Linked Media Framework in Apache Stanbol
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Jul 25, 2011 at 11:20 AM, Stefane Fermigier <sf...@nuxeo.com> wrote:
> On Jul 25, 2011, at 10:44 AM, Bertrand Delacretaz wrote:
>> ...ORM is an anti pattern anyway ;-)
> ...since Sebastian and his team made a great deal of effort to create their own ORM ("Object-RDF mapping")
> in the first place, we'd better acknowledge instead that "object-something mappings" are useful tools,
> with (as all tools) some limitations that one needs to be aware of...
To me the main problem with SQL-to-object mappers is, as explained in
the seldo.com blog post, that if SQL is the wrong model for your data
(i.e. your data is not relational), mapping that to objects won't
help. I just creates more mess ;-)
I haven't looked closely at what Sebastian's team have implemented in
this case, but an object to RDF mapping might make perfect sense if
RDF is the right model for your project and the mapped objects help
you access it. No impedance mismatch in that case.
>
> ...even Jackrabbit has an object-something mapping, "object content mapping" as
> they call it: http://jackrabbit.apache.org/object-content-mapping.html...
Similar problem as with SQL-to-object mappers IMO, but in reverse: the
JCR model is IMO well suited to content manipulation (given the right
underlying content model), so wrapping that under a generic object
mapping layer makes no sense.
But this is getting very off-topic now (and sorry I was part of that
thread hijacking ;-)
-Bertrand
Re: Proposal for Integration of Linked Media Framework in Apache Stanbol
Posted by Stefane Fermigier <sf...@nuxeo.com>.
On Jul 25, 2011, at 10:44 AM, Bertrand Delacretaz wrote:
> On Mon, Jul 25, 2011 at 10:33 AM, Sebastian Schaffert
> <se...@salzburgresearch.at> wrote:
>> ....I can absolutely understand why people are not in love with Hibernate. Not
>> only is the license not fitting, it is also a much too complex piece of software,
>> and the community and developers are very unfriendly and unresponsive
>> when you have questions....
>
> And ORM is an anti pattern anyway ;-)
> http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern
I like the "Vietnam of computer science" article better :)
But since Sebastian and his team made a great deal of effort to create their own ORM ("Object-RDF mapping") in the first place, we'd better acknowledge instead that "object-something mappings" are useful tools, with (as all tools) some limitations that one needs to be aware of.
Actually, even Jackrabbit has an object-something mapping, "object content mapping" as they call it: http://jackrabbit.apache.org/object-content-mapping.html
S.
--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com/ - +33 1 40 33 79 87 - http://twitter.com/sfermigier
Join the Nuxeo Group on LinkedIn: http://linkedin.com/groups?gid=43314
New Nuxeo release: http://nuxeo.com/dm54
"There's no such thing as can't. You always have a choice."
Re: Proposal for Integration of Linked Media Framework in Apache Stanbol
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Jul 25, 2011 at 10:33 AM, Sebastian Schaffert
<se...@salzburgresearch.at> wrote:
> ....I can absolutely understand why people are not in love with Hibernate. Not
> only is the license not fitting, it is also a much too complex piece of software,
> and the community and developers are very unfriendly and unresponsive
> when you have questions....
And ORM is an anti pattern anyway ;-)
http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern
-Bertrand
Re: Proposal for Integration of Linked Media Framework in Apache Stanbol
Posted by Sebastian Schaffert <se...@salzburgresearch.at>.
Am 23.07.2011 um 20:47 schrieb florent andré:
>
>
> On 07/23/2011 08:36 PM, Stefane Fermigier wrote:
>>
>> On Jul 22, 2011, at 3:06 PM, Sebastian Schaffert wrote:
>>
> ...
>>
>>> - license issue: LMF might still use libraries that are released under incompatible licenses, so this needs to be checked. In particular, Hibernate is still licensed under LGPL, and it is one of the core libraries of the LMF; porting to other persistence frameworks might require a lot of effort
>>
>> I don't know what's the ASF view on Hibernate. What are the alternatives ? EclipseLink is a viable alternative, I think, but it's licensed under the EPL. Does the ASF have a JPA project that's mature enough to replace Hibernate (OpenJPA ?) ?
>
> ASF is not in love with Hibernate. :)
> Moreover if Hibernate is a required lib for the project.
>
> http://cayenne.apache.org/
> Can be considered as an alternative.
I think that OpenJPA might be an easier choice for migration, because we are mostly using EntityManager-based operations anyways.
And I can absolutely understand why people are not in love with Hibernate. Not only is the license not fitting, it is also a much too complex piece of software, and the community and developers are very unfriendly and unresponsive when you have questions.
>
Greetings,
Sebastian
--
| Dr. Sebastian Schaffert sebastian.schaffert@salzburgresearch.at
| Salzburg Research Forschungsgesellschaft http://www.salzburgresearch.at
| Head of Knowledge and Media Technologies Group +43 662 2288 423
| Jakob-Haringer Strasse 5/II
| A-5020 Salzburg
Re: Proposal for Integration of Linked Media Framework in Apache Stanbol
Posted by Stefane Fermigier <sf...@nuxeo.com>.
On Jul 23, 2011, at 8:47 PM, florent andré wrote:
>
>
> On 07/23/2011 08:36 PM, Stefane Fermigier wrote:
>>
>> On Jul 22, 2011, at 3:06 PM, Sebastian Schaffert wrote:
>>
> ...
>>
>>> - license issue: LMF might still use libraries that are released under incompatible licenses, so this needs to be checked. In particular, Hibernate is still licensed under LGPL, and it is one of the core libraries of the LMF; porting to other persistence frameworks might require a lot of effort
>>
>> I don't know what's the ASF view on Hibernate. What are the alternatives ? EclipseLink is a viable alternative, I think, but it's licensed under the EPL. Does the ASF have a JPA project that's mature enough to replace Hibernate (OpenJPA ?) ?
>
> ASF is not in love with Hibernate. :)
> Moreover if Hibernate is a required lib for the project.
>
> http://cayenne.apache.org/
> Can be considered as an alternative.
First time I'm hearing about Cayenne (which is a first bad sign), and Cayenne doesn't seem to implement JPA, which is doubly a bad sign:
- It forces adherence to a non-standard way of doing things
- It forces a big rewrite of LMF which uses JPA.
S.
--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com/ - +33 1 40 33 79 87 - http://twitter.com/sfermigier
Join the Nuxeo Group on LinkedIn: http://linkedin.com/groups?gid=43314
New Nuxeo release: http://nuxeo.com/dm54
"There's no such thing as can't. You always have a choice."
Re: Proposal for Integration of Linked Media Framework in Apache
Stanbol
Posted by florent andré <fl...@4sengines.com>.
On 07/23/2011 08:36 PM, Stefane Fermigier wrote:
>
> On Jul 22, 2011, at 3:06 PM, Sebastian Schaffert wrote:
>
...
>
>> - license issue: LMF might still use libraries that are released under incompatible licenses, so this needs to be checked. In particular, Hibernate is still licensed under LGPL, and it is one of the core libraries of the LMF; porting to other persistence frameworks might require a lot of effort
>
> I don't know what's the ASF view on Hibernate. What are the alternatives ? EclipseLink is a viable alternative, I think, but it's licensed under the EPL. Does the ASF have a JPA project that's mature enough to replace Hibernate (OpenJPA ?) ?
ASF is not in love with Hibernate. :)
Moreover if Hibernate is a required lib for the project.
http://cayenne.apache.org/
Can be considered as an alternative.
I'm really exiting with this proposal ! Big +1.
++
Re: Proposal for Integration of Linked Media Framework in Apache Stanbol
Posted by Stefane Fermigier <sf...@nuxeo.com>.
On Jul 22, 2011, at 3:06 PM, Sebastian Schaffert wrote:
> Dear all,
>
> following up the discussion in the community workshop in Paris, I would like to formally offer the integration of our Linked Media Framework into Apache Stanbol.
Thanks for moving this forward Sebastian. I'm one of the people who asked for this merge to be discussed during the Paris Workshop, and I'm really happy that this is discussed now.
> Difficulties I see at the moment (just to mention these...):
> - technological issue: LMF is currently not using OSGi, but it uses a Gradle build system,
OSGi is not a build system (ok, there is a build system specific to OSGi, called BND, and maybe that's what people who are really committed to OSGi should be using - but that's another story).
Stanbol uses Maven. I don't think there is anything fundamentally wrong with Gradle (and there are many things that are wrong with Maven, but that's also another story), but Maven is pretty much the standard, and it makes sense to migrate the LMF build system to Maven.
Apparently, there's a plugin for that, so that shouldn't be too much work:
http://www.gradle.org/maven_plugin.html
> Java 6 EE dependency injection (CDI) and a typical Java EE architecture which is incompatible with OSGi for now;
Yes, this is probably more intrusive.
> one of our selling points is also "easy setup" and "lightweight", so I would not really like to change this for a complicated architecture ...
Some people would argue that there isn't much that's not "lightweight" with OSGi (OSGi services are just POJOs), and I don't think OSGi (for the part we're using in Stanbol at least), is more "complicated" that CDI. They probably should not be seen as competing, but as complementary approaches, and actually using DI with OSGi services is something that's already covered with SCR or iPOJO.
I don't have experience mixing CDI and OSGi, though (and that's something that could be useful for Nuxeo, so we're willing to investigate). Googling for "OSGi+CDI" gives some interesting links:
http://blogs.oracle.com/sivakumart/entry/typesafe_injection_of_dynamic_osgi
http://mathieuancelin.github.com/weld-osgi/
So it's definitively something people are wanting to do.
> - license issue: LMF might still use libraries that are released under incompatible licenses, so this needs to be checked. In particular, Hibernate is still licensed under LGPL, and it is one of the core libraries of the LMF; porting to other persistence frameworks might require a lot of effort
I don't know what's the ASF view on Hibernate. What are the alternatives ? EclipseLink is a viable alternative, I think, but it's licensed under the EPL. Does the ASF have a JPA project that's mature enough to replace Hibernate (OpenJPA ?) ?
> - organisational issue: LMF is developed in several projects that have their specific goals; we will in some way need to still be able to follow our goals in these projects, e.g. by appropriate Stanbol extensions; all software developed in these projects is Open Source though...
I think this would be very good for the project, because it would definitively allow us to check the mark "doesn't depend on IKS to move forward".
S.
--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com/ - +33 1 40 33 79 87 - http://twitter.com/sfermigier
Join the Nuxeo Group on LinkedIn: http://linkedin.com/groups?gid=43314
New Nuxeo release: http://nuxeo.com/dm54
"There's no such thing as can't. You always have a choice."
Re: Proposal for Integration of Linked Media Framework in Apache Stanbol
Posted by Sebastian Schaffert <se...@salzburgresearch.at>.
Sorry, this was meant for Rupert so I wrote in German ... but nothing secret ;-)
It says that I would also like to achieve this and that I would like to ger rid of Hibernate if there is a clean way ...
Btw, I am on vacation starting this evening... in case of questions my colleaue Thomas can surely answer competently in my place. I will check mail from time to time though ;-)
Greetings,
Sebastian
Am 26.07.2011 um 21:18 schrieb Sebastian Schaffert:
> Danke für die Unterstützung, da würd ich auch gern hin. ;-)
>
> Aber viele Vorschläge sind schon sehr gut, ich würd wirklich gerne weg von Hibernate wenn es eine saubere Möglichkeit gibt ...
>
> lg
> Sebastian
>
> Am 26.07.2011 um 18:59 schrieb Rupert Westenthaler:
>
>> Hi
>>
>> I think we should investigate if it would make sense to implement the
>> Clerezza APIs on top of the "Kiwi" Triple store. This would allow any
>> Clerezza based Application - including stanbol - to use this Triple
>> store implementation.
>>
>> WDYT
>> Rupert
>>
>> On Tue, Jul 26, 2011 at 5:54 PM, Sebastian Schaffert
>> <se...@salzburgresearch.at> wrote:
>>> Dear Florent,
>>>
>>> Am 26.07.2011 um 16:46 schrieb florent andré:
>>>>
>>>>>
>>>>> The dependency to Hibernate is mostly for the triple store, not for CMS capabilities. And this is something I don't see how to avoid in the near future because we need to store additional information about triples for reasoning and versioning.
>>>>>
>>>>> Versioning is also of triples, not of content. As such it is probably also interesting to the Stanbol community.
>>>>
>>>> I'm interesting in a little explanation of the way you store version / history of triples.
>>>
>>> We use a purely relational approach actually:
>>> - a table "KIWINODE" stores RDF nodes (unified table for literals, blank nodes and resources)
>>> - a table "TRIPLES" stores triples with id, subject, predicate, object, context, marker for deleted, marker for inferred, timestamp, creator (subject, predicate, object, context, creator are references to KIWINODE)
>>> - a table "VERSION" stores version ID, timestamp, creator
>>> - join tables "VERSION_ADDEDNODES", "VERSION_REMOVEDNODES", "VERSION_ADDEDTRIPLES", "VERSION_REMOVEDTRIPLES" store references to added and removed nodes and to added and removed triples; for deleted triples and nodes, the boolean marker will be set to true, for added nodes it will be false
>>>
>>> Versioning is thus a simple database operation. "Active" (undeleted) triples can be easily filtered using the boolean marker. Undoing simply means reversing the operations (add and remove) on triples and nodes.
>>>
>>>
>>>>
>>>> I begin to think about that (but just think for now :) ), and the possible help of big tables (e.g. hbase) for this...
>>>>
>>>> Hbase is a (kind of) 3 dimensional database :
>>>> - 1 is column
>>>> - 1 is row
>>>> - 1 is timestamp
>>>
>> I think there is currently a lot of work on how to handle Graph
>> Structures in this kind of data stores. I am definitely interested in
>> this topic but currently I do not have the time to investigate it in
>> more detail.
>>
>>> I really don't see the point. A relational database is already n-dimensional ;-)
>>>
>>
>> As long as you can handle the amount of triples on a single machine it
>> is fore sure more efficient and easier to implement to handle it with
>> a relational database.
>> I think there is also a new TripleStore implementation around that
>> uses Solr/Lucene to store Triples. Someone has mentioned it in Paris,
>> but I have forgot the name of the project.
>>
>>>
>>>>
>>>> So, for my 100 feet idea :
>>>> - each triple is a row
>>>> - ?s, ?p, ?o each a column (or a column family)
>>>>
>>>> And so, history of each triple is store on the 3rd dimension : timestamps.
>>>>
>>>> This can bring to a really clean and easy design... if not strong technical/integration restrictions comes...
>>>
>>> I am not really convinced, but maybe you can offer some more details and convince me.;-) I am not familiar with these kinds of databases.
>>>
>>> My thought is that relational databases are really well suited for the task because this is what they have been designed for (triples are really purely relational data), with one (minor) exception: expensive join operations happen frequently when querying RDF, and there is almost no chance to materialize them in advance. This can be compensated a bit by proper indexing and configuration of the database, however.
>>>
>>
>> Yago2 uses a special n-triple model that includes subject, predicate,
>> object, temporal, spatial and full text. For spatial and full text
>> they use the according extensions of the relational databases. By that
>> they can creatly reduce the amount of joins for requests for event
>> like data.
>>
>> Again this discussion is very related to the work of Fabian on the Factstore!
>>
>> best
>> Rupert
>>
>> --
>> | Rupert Westenthaler rupert.westenthaler@gmail.com
>> | Bodenlehenstraße 11 ++43-699-11108907
>> | A-5500 Bischofshofen
>
> Sebastian
> --
> | Dr. Sebastian Schaffert sebastian.schaffert@salzburgresearch.at
> | Salzburg Research Forschungsgesellschaft http://www.salzburgresearch.at
> | Head of Knowledge and Media Technologies Group +43 662 2288 423
> | Jakob-Haringer Strasse 5/II
> | A-5020 Salzburg
>
Sebastian
--
| Dr. Sebastian Schaffert sebastian.schaffert@salzburgresearch.at
| Salzburg Research Forschungsgesellschaft http://www.salzburgresearch.at
| Head of Knowledge and Media Technologies Group +43 662 2288 423
| Jakob-Haringer Strasse 5/II
| A-5020 Salzburg
Re: Proposal for Integration of Linked Media Framework in Apache Stanbol
Posted by Sebastian Schaffert <se...@salzburgresearch.at>.
Danke für die Unterstützung, da würd ich auch gern hin. ;-)
Aber viele Vorschläge sind schon sehr gut, ich würd wirklich gerne weg von Hibernate wenn es eine saubere Möglichkeit gibt ...
lg
Sebastian
Am 26.07.2011 um 18:59 schrieb Rupert Westenthaler:
> Hi
>
> I think we should investigate if it would make sense to implement the
> Clerezza APIs on top of the "Kiwi" Triple store. This would allow any
> Clerezza based Application - including stanbol - to use this Triple
> store implementation.
>
> WDYT
> Rupert
>
> On Tue, Jul 26, 2011 at 5:54 PM, Sebastian Schaffert
> <se...@salzburgresearch.at> wrote:
>> Dear Florent,
>>
>> Am 26.07.2011 um 16:46 schrieb florent andré:
>>>
>>>>
>>>> The dependency to Hibernate is mostly for the triple store, not for CMS capabilities. And this is something I don't see how to avoid in the near future because we need to store additional information about triples for reasoning and versioning.
>>>>
>>>> Versioning is also of triples, not of content. As such it is probably also interesting to the Stanbol community.
>>>
>>> I'm interesting in a little explanation of the way you store version / history of triples.
>>
>> We use a purely relational approach actually:
>> - a table "KIWINODE" stores RDF nodes (unified table for literals, blank nodes and resources)
>> - a table "TRIPLES" stores triples with id, subject, predicate, object, context, marker for deleted, marker for inferred, timestamp, creator (subject, predicate, object, context, creator are references to KIWINODE)
>> - a table "VERSION" stores version ID, timestamp, creator
>> - join tables "VERSION_ADDEDNODES", "VERSION_REMOVEDNODES", "VERSION_ADDEDTRIPLES", "VERSION_REMOVEDTRIPLES" store references to added and removed nodes and to added and removed triples; for deleted triples and nodes, the boolean marker will be set to true, for added nodes it will be false
>>
>> Versioning is thus a simple database operation. "Active" (undeleted) triples can be easily filtered using the boolean marker. Undoing simply means reversing the operations (add and remove) on triples and nodes.
>>
>>
>>>
>>> I begin to think about that (but just think for now :) ), and the possible help of big tables (e.g. hbase) for this...
>>>
>>> Hbase is a (kind of) 3 dimensional database :
>>> - 1 is column
>>> - 1 is row
>>> - 1 is timestamp
>>
> I think there is currently a lot of work on how to handle Graph
> Structures in this kind of data stores. I am definitely interested in
> this topic but currently I do not have the time to investigate it in
> more detail.
>
>> I really don't see the point. A relational database is already n-dimensional ;-)
>>
>
> As long as you can handle the amount of triples on a single machine it
> is fore sure more efficient and easier to implement to handle it with
> a relational database.
> I think there is also a new TripleStore implementation around that
> uses Solr/Lucene to store Triples. Someone has mentioned it in Paris,
> but I have forgot the name of the project.
>
>>
>>>
>>> So, for my 100 feet idea :
>>> - each triple is a row
>>> - ?s, ?p, ?o each a column (or a column family)
>>>
>>> And so, history of each triple is store on the 3rd dimension : timestamps.
>>>
>>> This can bring to a really clean and easy design... if not strong technical/integration restrictions comes...
>>
>> I am not really convinced, but maybe you can offer some more details and convince me.;-) I am not familiar with these kinds of databases.
>>
>> My thought is that relational databases are really well suited for the task because this is what they have been designed for (triples are really purely relational data), with one (minor) exception: expensive join operations happen frequently when querying RDF, and there is almost no chance to materialize them in advance. This can be compensated a bit by proper indexing and configuration of the database, however.
>>
>
> Yago2 uses a special n-triple model that includes subject, predicate,
> object, temporal, spatial and full text. For spatial and full text
> they use the according extensions of the relational databases. By that
> they can creatly reduce the amount of joins for requests for event
> like data.
>
> Again this discussion is very related to the work of Fabian on the Factstore!
>
> best
> Rupert
>
> --
> | Rupert Westenthaler rupert.westenthaler@gmail.com
> | Bodenlehenstraße 11 ++43-699-11108907
> | A-5500 Bischofshofen
Sebastian
--
| Dr. Sebastian Schaffert sebastian.schaffert@salzburgresearch.at
| Salzburg Research Forschungsgesellschaft http://www.salzburgresearch.at
| Head of Knowledge and Media Technologies Group +43 662 2288 423
| Jakob-Haringer Strasse 5/II
| A-5020 Salzburg
Re: Proposal for Integration of Linked Media Framework in Apache Stanbol
Posted by Rupert Westenthaler <ru...@gmail.com>.
Hi
I think we should investigate if it would make sense to implement the
Clerezza APIs on top of the "Kiwi" Triple store. This would allow any
Clerezza based Application - including stanbol - to use this Triple
store implementation.
WDYT
Rupert
On Tue, Jul 26, 2011 at 5:54 PM, Sebastian Schaffert
<se...@salzburgresearch.at> wrote:
> Dear Florent,
>
> Am 26.07.2011 um 16:46 schrieb florent andré:
>>
>>>
>>> The dependency to Hibernate is mostly for the triple store, not for CMS capabilities. And this is something I don't see how to avoid in the near future because we need to store additional information about triples for reasoning and versioning.
>>>
>>> Versioning is also of triples, not of content. As such it is probably also interesting to the Stanbol community.
>>
>> I'm interesting in a little explanation of the way you store version / history of triples.
>
> We use a purely relational approach actually:
> - a table "KIWINODE" stores RDF nodes (unified table for literals, blank nodes and resources)
> - a table "TRIPLES" stores triples with id, subject, predicate, object, context, marker for deleted, marker for inferred, timestamp, creator (subject, predicate, object, context, creator are references to KIWINODE)
> - a table "VERSION" stores version ID, timestamp, creator
> - join tables "VERSION_ADDEDNODES", "VERSION_REMOVEDNODES", "VERSION_ADDEDTRIPLES", "VERSION_REMOVEDTRIPLES" store references to added and removed nodes and to added and removed triples; for deleted triples and nodes, the boolean marker will be set to true, for added nodes it will be false
>
> Versioning is thus a simple database operation. "Active" (undeleted) triples can be easily filtered using the boolean marker. Undoing simply means reversing the operations (add and remove) on triples and nodes.
>
>
>>
>> I begin to think about that (but just think for now :) ), and the possible help of big tables (e.g. hbase) for this...
>>
>> Hbase is a (kind of) 3 dimensional database :
>> - 1 is column
>> - 1 is row
>> - 1 is timestamp
>
I think there is currently a lot of work on how to handle Graph
Structures in this kind of data stores. I am definitely interested in
this topic but currently I do not have the time to investigate it in
more detail.
> I really don't see the point. A relational database is already n-dimensional ;-)
>
As long as you can handle the amount of triples on a single machine it
is fore sure more efficient and easier to implement to handle it with
a relational database.
I think there is also a new TripleStore implementation around that
uses Solr/Lucene to store Triples. Someone has mentioned it in Paris,
but I have forgot the name of the project.
>
>>
>> So, for my 100 feet idea :
>> - each triple is a row
>> - ?s, ?p, ?o each a column (or a column family)
>>
>> And so, history of each triple is store on the 3rd dimension : timestamps.
>>
>> This can bring to a really clean and easy design... if not strong technical/integration restrictions comes...
>
> I am not really convinced, but maybe you can offer some more details and convince me.;-) I am not familiar with these kinds of databases.
>
> My thought is that relational databases are really well suited for the task because this is what they have been designed for (triples are really purely relational data), with one (minor) exception: expensive join operations happen frequently when querying RDF, and there is almost no chance to materialize them in advance. This can be compensated a bit by proper indexing and configuration of the database, however.
>
Yago2 uses a special n-triple model that includes subject, predicate,
object, temporal, spatial and full text. For spatial and full text
they use the according extensions of the relational databases. By that
they can creatly reduce the amount of joins for requests for event
like data.
Again this discussion is very related to the work of Fabian on the Factstore!
best
Rupert
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: Proposal for Integration of Linked Media Framework in Apache Stanbol
Posted by Sebastian Schaffert <se...@salzburgresearch.at>.
Dear Florent,
Am 26.07.2011 um 16:46 schrieb florent andré:
>
>>
>> The dependency to Hibernate is mostly for the triple store, not for CMS capabilities. And this is something I don't see how to avoid in the near future because we need to store additional information about triples for reasoning and versioning.
>>
>> Versioning is also of triples, not of content. As such it is probably also interesting to the Stanbol community.
>
> I'm interesting in a little explanation of the way you store version / history of triples.
We use a purely relational approach actually:
- a table "KIWINODE" stores RDF nodes (unified table for literals, blank nodes and resources)
- a table "TRIPLES" stores triples with id, subject, predicate, object, context, marker for deleted, marker for inferred, timestamp, creator (subject, predicate, object, context, creator are references to KIWINODE)
- a table "VERSION" stores version ID, timestamp, creator
- join tables "VERSION_ADDEDNODES", "VERSION_REMOVEDNODES", "VERSION_ADDEDTRIPLES", "VERSION_REMOVEDTRIPLES" store references to added and removed nodes and to added and removed triples; for deleted triples and nodes, the boolean marker will be set to true, for added nodes it will be false
Versioning is thus a simple database operation. "Active" (undeleted) triples can be easily filtered using the boolean marker. Undoing simply means reversing the operations (add and remove) on triples and nodes.
>
> I begin to think about that (but just think for now :) ), and the possible help of big tables (e.g. hbase) for this...
>
> Hbase is a (kind of) 3 dimensional database :
> - 1 is column
> - 1 is row
> - 1 is timestamp
I really don't see the point. A relational database is already n-dimensional ;-)
>
> So, for my 100 feet idea :
> - each triple is a row
> - ?s, ?p, ?o each a column (or a column family)
>
> And so, history of each triple is store on the 3rd dimension : timestamps.
>
> This can bring to a really clean and easy design... if not strong technical/integration restrictions comes...
I am not really convinced, but maybe you can offer some more details and convince me.;-) I am not familiar with these kinds of databases.
My thought is that relational databases are really well suited for the task because this is what they have been designed for (triples are really purely relational data), with one (minor) exception: expensive join operations happen frequently when querying RDF, and there is almost no chance to materialize them in advance. This can be compensated a bit by proper indexing and configuration of the database, however.
Greetings,
Sebastian
--
| Dr. Sebastian Schaffert sebastian.schaffert@salzburgresearch.at
| Salzburg Research Forschungsgesellschaft http://www.salzburgresearch.at
| Head of Knowledge and Media Technologies Group +43 662 2288 423
| Jakob-Haringer Strasse 5/II
| A-5020 Salzburg
Re: Proposal for Integration of Linked Media Framework in Apache
Stanbol
Posted by florent andré <fl...@4sengines.com>.
On 07/25/2011 10:53 AM, Sebastian Schaffert wrote:
>
> Am 22.07.2011 um 19:27 schrieb Rupert Westenthaler:
>
>
...
>
> The dependency to Hibernate is mostly for the triple store, not for CMS capabilities. And this is something I don't see how to avoid in the near future because we need to store additional information about triples for reasoning and versioning.
>
> Versioning is also of triples, not of content. As such it is probably also interesting to the Stanbol community.
I'm interesting in a little explanation of the way you store version /
history of triples.
I begin to think about that (but just think for now :) ), and the
possible help of big tables (e.g. hbase) for this...
Hbase is a (kind of) 3 dimensional database :
- 1 is column
- 1 is row
- 1 is timestamp
So, for my 100 feet idea :
- each triple is a row
- ?s, ?p, ?o each a column (or a column family)
And so, history of each triple is store on the 3rd dimension : timestamps.
This can bring to a really clean and easy design... if not strong
technical/integration restrictions comes...
Just a tought...
++
Re: Proposal for Integration of Linked Media Framework in Apache Stanbol
Posted by Sebastian Schaffert <se...@salzburgresearch.at>.
Am 22.07.2011 um 19:27 schrieb Rupert Westenthaler:
> Hi
>
> Let me add my first comments
>
>>
>> LMF Core
>> ========
>>
>> The core component of the Linked Media Framework is a Linked Data Server that allows to expose data following the Linked Data Principles:
>> * Use URIs as names for things.
>> * Use HTTP URIs, so that people can look up those names.
>> * When someone looks up a URI, provide useful information, using the standards (RDF, SPARQL).
>> * Include links to other URIs, so that they can discover more things.
>> The Linked Data Server implemented as part of the LMF goes beyond the Linked Data principles by extending them with Linked Data Updates and by integrating management of metadata and content and making both accessible in a uniform way. In addition to the Linked Data Server, the LMF Core also offers a SPARQL endpoint.
>>
>
> The Linked Data Server incl. the LMF extensions (content+metadata and
> full CRUD) functionality would be a very nice extension for STANBOL:
> (1) because it is central for the plant Contenthub.(2) it is also
> relevant for the Entityhub and (3) if we design this component smart,
> that it should be possible that it could provide an easy way for many
> existing CMS systems to support LOD for there contents.
Number (3) is actually the central argument that we had for LMF, just that our partners are not really CMS providers. They are more in the media asset management and document management area. But the same arguments and approaches hold there ;-)
I have some ideas on how to do this integration properly. At the moment, the LMF stores content itself, which is not really practical. It would be much more reasonable to have a configurable redirect from the content URIs to the respective content management systems (could even be several different at the same time using some kind of configurable mapping - a content management system, a media asset management system, a wiki ...)
>
>> LMF Modules
>> ===========
>>
>> As extension for the LMF Core, we are working on a number of optional modules that can be used to extend the functionality of the Linked Media Server:
>>
>> Implemented:
>> * LMF Semantic Search offers a highly configurable Semantic Search service based on Apache SOLR. Several semantic search indexes can be configured in the same LMF instance using an RDF Path Language that allows traversal over several Linked Data sources.
>
> At first this sounds similar to the SolrYard used by the Entityhub but
> in the details it is very different.
[...]
Thanks for the clarification, I should maybe have emphasised this. SOLR can indeed be used for many different purposes - in our case it is actually exposed to the user and not only used internally. Therefore we want the SOLR service to be "as much SOLR as possible", because we want users to be able to use existing SOLR tools like the great AJAX-SOLR.
>
>> * LMF Reasoner implements a rule-based reasoner that allows to process Datalog-style rules over RDF triples; the LMF Reasoner is based on the reasoning component developed in the KiWi project, the predecessor of the LMF
>>
>
> In my opinion this component may have the biggest impact if used in
> combination with the LMF Semantic Search/Indexing component - adding
> the possibility to use Rules (in addition to the RDF Path Language)
> to specify how to build documents for the semantic index.
> If this can solve the licencing Issues with current Reasoners would be
> interesting. I think the current Rule/Reasoner functionality is based
> on OWL-DL and SWRL and I do not know how that relates to Datalog-style
> rule languages.
The problem I have with existing reasoners is that they are either only Description Logics or Description Logics+Rules. In both cases they introduce the high complexity of DL reasoning, but DL reasoning is mostly only interesting for consistency and schema checking. Even if the DL people claim that DL is decidable, this only means that the reasoner will terminate eventually in finite time - but this may be in 1000 years.;-) A purely rule-based reasoner can be much more efficient.
>>
>
> However the LMF provides also a lot of Semantic CMS capabilities.
> Features like "LMF Versioning", "LMF Permissions" and its dependency
> to Hibernate are hints about that. Stanbol explicitly excludes such
> stuff because one can typically already find this features in the
> existing CMS stacks of potential Stanbol users.
The dependency to Hibernate is mostly for the triple store, not for CMS capabilities. And this is something I don't see how to avoid in the near future because we need to store additional information about triples for reasoning and versioning.
Versioning is also of triples, not of content. As such it is probably also interesting to the Stanbol community.
Permissions is a topic that will likely become highly relevant for Stanbol as well. We actually only added it because it is a requirement of the SNML technology partners. There are e.g. many cases where only selected people should have access to the metadata or even the fact of existance of a resource (consider a document about a medical treatment ...).
The real Semantic CMS functionality in the LMF should go away anyways, even in the SNML scenarios. Because they are very similar to the CMS scenarios in IKS anyways ... so this is a good opportunity to do it :)
Greetings,
Sebastian
--
| Dr. Sebastian Schaffert sebastian.schaffert@salzburgresearch.at
| Salzburg Research Forschungsgesellschaft http://www.salzburgresearch.at
| Head of Knowledge and Media Technologies Group +43 662 2288 423
| Jakob-Haringer Strasse 5/II
| A-5020 Salzburg
Re: Proposal for Integration of Linked Media Framework in Apache Stanbol
Posted by Rupert Westenthaler <ru...@gmail.com>.
Hi
Let me add my first comments
>
> LMF Core
> ========
>
> The core component of the Linked Media Framework is a Linked Data Server that allows to expose data following the Linked Data Principles:
> * Use URIs as names for things.
> * Use HTTP URIs, so that people can look up those names.
> * When someone looks up a URI, provide useful information, using the standards (RDF, SPARQL).
> * Include links to other URIs, so that they can discover more things.
> The Linked Data Server implemented as part of the LMF goes beyond the Linked Data principles by extending them with Linked Data Updates and by integrating management of metadata and content and making both accessible in a uniform way. In addition to the Linked Data Server, the LMF Core also offers a SPARQL endpoint.
>
The Linked Data Server incl. the LMF extensions (content+metadata and
full CRUD) functionality would be a very nice extension for STANBOL:
(1) because it is central for the plant Contenthub.(2) it is also
relevant for the Entityhub and (3) if we design this component smart,
that it should be possible that it could provide an easy way for many
existing CMS systems to support LOD for there contents.
> LMF Modules
> ===========
>
> As extension for the LMF Core, we are working on a number of optional modules that can be used to extend the functionality of the Linked Media Server:
>
> Implemented:
> * LMF Semantic Search offers a highly configurable Semantic Search service based on Apache SOLR. Several semantic search indexes can be configured in the same LMF instance using an RDF Path Language that allows traversal over several Linked Data sources.
At first this sounds similar to the SolrYard used by the Entityhub but
in the details it is very different.
Here it is the goal to use a Path Language to
* define the Information indexed for a Document
* create a Solr Schema that stores exactly such information in fields
with simple names
* based on the paths retrieves Information from different DataSources
such as the Entityhub, Enhancement Results possible CMS queries via
the CMSAdapter, ...)
* users will directly access the Solr Index via the normal Solr
RESTful interface.
The SolrYard aims to use a single schema that it capable to store
Entities of any kind (without schema limitations). For providing this
it uses rather tricky prefixes and postfixes for Solr fields. Solr
Indices are not intended to be directly used by Users, but via the
Java API/RESTful API of the Entityhub. However all the Solr related
utilities (like creating/loading SolrCores via the Sling Installer/
Stanbol DataFileprovider) will be used by both components. This is
also the reason why I have already started to move this
functionalities over to the stanbol.commons.solr bundle.
I think the first and most intuitive use is to use this component to
build the Search Interface for the Contenthub (similar to what it
already does within the LMF), but this is also an very related to the
work Fabian has started with the Factstore (the path configuration
would be the definition of the fact).
> * LMF Linked Data Cache implements a cache to the Linked Data Cloud that is transparently used when querying the content of the LMF using either SPARQL or the Semantic Search component. In case a local resource links to a remote resource in the Linked Data Cloud and this relationship is queried, the remote resource will be retrieved in the background and cached locally.
Linked Data Crawling functionality is definitely of interest to the
Entityhub. It could be used build more efficient local caches (e.g. to
prefetch data that are only a single URI away from data already used).
However such a feature is also of general interest to CMS.
> * LMF Reasoner implements a rule-based reasoner that allows to process Datalog-style rules over RDF triples; the LMF Reasoner is based on the reasoning component developed in the KiWi project, the predecessor of the LMF
>
In my opinion this component may have the biggest impact if used in
combination with the LMF Semantic Search/Indexing component - adding
the possibility to use Rules (in addition to the RDF Path Language)
to specify how to build documents for the semantic index.
If this can solve the licencing Issues with current Reasoners would be
interesting. I think the current Rule/Reasoner functionality is based
on OWL-DL and SWRL and I do not know how that relates to Datalog-style
rule languages.
> Under Progress:
> * LMF Permissions implements and extends the WebID and WebACL specifications for standards-conforming authentication and access control in the Linked Media Framework. (state: almost completed)
> * LMF Enhancer offers semantic enhancement of content by analysing textual and media content; the LMF Enhancer will build upon the Apache Stanbol framework (state: started)
> * LMF Media Interlinking will implement support for multimedia interlinking based on the work in the W3C Multimedia Fragments WG and theW3C Multimedia Annotations WG
> * LMF Versioning implements versioning of metadata updates; versioning itself is already carried out by LMF Core, but the management of versions will be carried out by this module (state: started)
> --- 8< ---- 8< ---
>
> As far as I can see, Apache Stanbol and the Linked Media Framework currently cover mostly complementary areas and I think that a combination could be of benefit for both projects. In particular, I would think that the Linked Media Framework can also offer an almost ready implementation of the Stanbol Content Hub, as well as a free reasoner and full Linked Data capabilities (server as well as client) and Semantic Search.
>
> Last but not least it is also of strategic interest for the KMT group at Salzburg Research to (1) integrate the technologies developed in the group, and (2) avoid duplication of effort if it is not necessary.
>
> What I can offer is that - following a discussion on the mailinglist - we donate the LMF code base to Apache Stanbol and try integrating the two projects in the next months. Since the LMF is easily deployable as a .war file, a first step could be to deploy the web application inside Apache Stanbol as an OSGi web application. This could demonstrate the usefulness of the combination. Of course, in the course of the integration it would be necessary to isolate the individual modules of the LMF as separate components.
>
> Difficulties I see at the moment (just to mention these...):
> - technological issue: LMF is currently not using OSGi, but it uses a Gradle build system, Java 6 EE dependency injection (CDI) and a typical Java EE architecture which is incompatible with OSGi for now; one of our selling points is also "easy setup" and "lightweight", so I would not really like to change this for a complicated architecture ...
I think the Stanbol community is a very good place for getting help
with OSGI related questions.
> - license issue: LMF might still use libraries that are released under incompatible licenses, so this needs to be checked. In particular, Hibernate is still licensed under LGPL, and it is one of the core libraries of the LMF; porting to other persistence frameworks might require a lot of effort
> - organisational issue: LMF is developed in several projects that have their specific goals; we will in some way need to still be able to follow our goals in these projects, e.g. by appropriate Stanbol extensions; all software developed in these projects is Open Source though...
>
Relating to this one has simple to consider that the focus of Stanbol
and the LMF is a little be different:
Stanbol tries to be the Semantic Engine that brings Semantic
Capabilities to CMS. The LMF also provides a lot of such capabilities.
Luckily such capabilities are mostly complementary and therefore it
would be a really great thing to merge them and build a single more
capable thing with an even stronger community.
However the LMF provides also a lot of Semantic CMS capabilities.
Features like "LMF Versioning", "LMF Permissions" and its dependency
to Hibernate are hints about that. Stanbol explicitly excludes such
stuff because one can typically already find this features in the
existing CMS stacks of potential Stanbol users.
For the LMF this stuff is important because such features are required
for the kind of research projects we need to run here at Salzburg
Research.
What does that mean? In my opinion this simply indicates that there
will be still a LMF around after the merging with Stanbol. It will
have a very strong dependency to Stanbol and the remaining parts will
be much more focused around Semantic ContentManagement.
best
Rupert Westenthaler
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: Proposal for Integration of Linked Media Framework in Apache
Stanbol
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
Hi Sebastian. Thank you! We had been looking forward to that and will
gladly dig through it.
Alessandro
On 7/22/11 3:06 PM, Sebastian Schaffert wrote:
> Dear all,
>
> following up the discussion in the community workshop in Paris, I would like to formally offer the integration of our Linked Media Framework into Apache Stanbol. The software is currently available under BSD license at the Google Code website at http://code.google.com/p/kiwi/. Here is a short summary of the functionality it can offer (mostly from the website where you can also find more in-detail documentation):
>
> --- 8< ---- 8< ---
> The Linked Media Framework is an easy-to-setup server application that bundles central Semantic Web technologies to offer advanced services. The Linked Media Framework consists of LMF Core and LMF Modules.
>
> LMF Core
> ========
>
> The core component of the Linked Media Framework is a Linked Data Server that allows to expose data following the Linked Data Principles:
> * Use URIs as names for things.
> * Use HTTP URIs, so that people can look up those names.
> * When someone looks up a URI, provide useful information, using the standards (RDF, SPARQL).
> * Include links to other URIs, so that they can discover more things.
> The Linked Data Server implemented as part of the LMF goes beyond the Linked Data principles by extending them with Linked Data Updates and by integrating management of metadata and content and making both accessible in a uniform way. In addition to the Linked Data Server, the LMF Core also offers a SPARQL endpoint.
>
> LMF Modules
> ===========
>
> As extension for the LMF Core, we are working on a number of optional modules that can be used to extend the functionality of the Linked Media Server:
>
> Implemented:
> * LMF Semantic Search offers a highly configurable Semantic Search service based on Apache SOLR. Several semantic search indexes can be configured in the same LMF instance using an RDF Path Language that allows traversal over several Linked Data sources.
> * LMF Linked Data Cache implements a cache to the Linked Data Cloud that is transparently used when querying the content of the LMF using either SPARQL or the Semantic Search component. In case a local resource links to a remote resource in the Linked Data Cloud and this relationship is queried, the remote resource will be retrieved in the background and cached locally.
> * LMF Reasoner implements a rule-based reasoner that allows to process Datalog-style rules over RDF triples; the LMF Reasoner is based on the reasoning component developed in the KiWi project, the predecessor of the LMF
>
> Under Progress:
> * LMF Permissions implements and extends the WebID and WebACL specifications for standards-conforming authentication and access control in the Linked Media Framework. (state: almost completed)
> * LMF Enhancer offers semantic enhancement of content by analysing textual and media content; the LMF Enhancer will build upon the Apache Stanbol framework (state: started)
> * LMF Media Interlinking will implement support for multimedia interlinking based on the work in the W3C Multimedia Fragments WG and theW3C Multimedia Annotations WG
> * LMF Versioning implements versioning of metadata updates; versioning itself is already carried out by LMF Core, but the management of versions will be carried out by this module (state: started)
> --- 8< ---- 8< ---
>
> As far as I can see, Apache Stanbol and the Linked Media Framework currently cover mostly complementary areas and I think that a combination could be of benefit for both projects. In particular, I would think that the Linked Media Framework can also offer an almost ready implementation of the Stanbol Content Hub, as well as a free reasoner and full Linked Data capabilities (server as well as client) and Semantic Search.
>
> Last but not least it is also of strategic interest for the KMT group at Salzburg Research to (1) integrate the technologies developed in the group, and (2) avoid duplication of effort if it is not necessary.
>
> What I can offer is that - following a discussion on the mailinglist - we donate the LMF code base to Apache Stanbol and try integrating the two projects in the next months. Since the LMF is easily deployable as a .war file, a first step could be to deploy the web application inside Apache Stanbol as an OSGi web application. This could demonstrate the usefulness of the combination. Of course, in the course of the integration it would be necessary to isolate the individual modules of the LMF as separate components.
>
> Difficulties I see at the moment (just to mention these...):
> - technological issue: LMF is currently not using OSGi, but it uses a Gradle build system, Java 6 EE dependency injection (CDI) and a typical Java EE architecture which is incompatible with OSGi for now; one of our selling points is also "easy setup" and "lightweight", so I would not really like to change this for a complicated architecture ...
> - license issue: LMF might still use libraries that are released under incompatible licenses, so this needs to be checked. In particular, Hibernate is still licensed under LGPL, and it is one of the core libraries of the LMF; porting to other persistence frameworks might require a lot of effort
> - organisational issue: LMF is developed in several projects that have their specific goals; we will in some way need to still be able to follow our goals in these projects, e.g. by appropriate Stanbol extensions; all software developed in these projects is Open Source though...
>
>
> Now let the discussion begin ... ;-)
>
>
> Sebastian
--
M.Sc. Alessandro Adamou
Alma Mater Studiorum - Università di Bologna
Department of Computer Science
Mura Anteo Zamboni 7, Bologna - Italy
Semantic Technology Laboratory (STLab)
Institute for Cognitive Science and Technology (ISTC)
National Research Council (CNR)
Via Nomentana 56, 00161 Rome - Italy
"As for the charges against me, I am unconcerned. I am beyond their timid, lying morality, and so I am beyond caring."
(Col. Walter E. Kurtz)
Re: Proposal for Integration of Linked Media Framework in Apache Stanbol
Posted by Enrico Daga <en...@gmail.com>.
Hi,
I am very happy for this proposal, and I think we can join efforts on
implementing reasoning capabilities in Stanbol.
Personally, I will be out of work for a couple of weeks, then I will
do my part on adding KIWI as reasoning service and discuss the
implementation of long-term reasoning operations and triple storing
lookup features.
see also the other thread on this list: "What's going on with Stanbol Reasoners"
Bests
Enrico
On 1 September 2011 09:25, Andreas Kuckartz <A....@ping.de> wrote:
> I think that was and is a great proposal.
>
> What is the status of the integration? (Roadmap?)
>
> Cheers,
> Andreas
> ---
>
> Am 22.07.2011 15:06, schrieb Sebastian Schaffert:
>> Dear all,
>>
>> following up the discussion in the community workshop in Paris, I
> would like to formally offer the integration of our Linked Media
> Framework into Apache Stanbol. The software is currently available under
> BSD license at the Google Code website at
> http://code.google.com/p/kiwi/. Here is a short summary of the
> functionality it can offer (mostly from the website where you can also
> find more in-detail documentation):
>>
>> ...
>
>
--
Enrico Daga
--
http://www.enridaga.net
skype: enri-pan
Re: Proposal for Integration of Linked Media Framework in Apache Stanbol
Posted by Sebastian Schaffert <se...@salzburgresearch.at>.
Dear Andreas and all,
Am 01.09.2011 um 09:25 schrieb Andreas Kuckartz:
> I think that was and is a great proposal.
>
> What is the status of the integration? (Roadmap?)
I would see the following steps of integration:
1. we create an OSGi module out of the LMF WAR file, e.g. using PAX Web
-> this would allow to use the LMF services in one installation with Apache Stanbol so at least people can start experimenting, but this is not a very tight integration, other Stanbol components would need to access LMF services via the REST API
timeline: end of september if Rupert and I find the time to sit together for two days
2. we try to split up the LMF modules (which are not OSGi, just JAR with CDI for dependency injection) into separate OSGi modules so that the LMF modules can be configured separately; LMF modules expose their API via OSGi services
-> this would allow other Stanbol components to use the LMF services directly via Java / OSGi API; some functionality that is offered by both LMF and Stanbol will be duplicated (e.g. there is much overlap between LMF and Clarezza, and between LMF and EntityHub/ContentHub) because LMF services depend currently on this functionality
timeline: october/november/december
3. we unify the APIs of LMF and Stanbol so that there is no duplicate functionality, and we resolve the library dependencies of LMF so that they are compatible with Stanbol
-> would be the full integration of the LMF functionality in Stanbol; I am not sure when and how we will achieve it because I have no estimation about what needs to be done
3) is complicated because many services in the LMF depend on libraries and models that are currently used and it is not so easy to e.g. port the reasoner to Jena or Clarezza datamodels. Also, we chose the models and libraries (e.g. Sesame) deliberately and very conciously because they were the best option for our problems.
Greetings,
Sebastian
--
| Dr. Sebastian Schaffert sebastian.schaffert@salzburgresearch.at
| Salzburg Research Forschungsgesellschaft http://www.salzburgresearch.at
| Head of Knowledge and Media Technologies Group +43 662 2288 423
| Jakob-Haringer Strasse 5/II
| A-5020 Salzburg
Re: Proposal for Integration of Linked Media Framework in Apache
Stanbol
Posted by Andreas Kuckartz <A....@ping.de>.
I think that was and is a great proposal.
What is the status of the integration? (Roadmap?)
Cheers,
Andreas
---
Am 22.07.2011 15:06, schrieb Sebastian Schaffert:
> Dear all,
>
> following up the discussion in the community workshop in Paris, I
would like to formally offer the integration of our Linked Media
Framework into Apache Stanbol. The software is currently available under
BSD license at the Google Code website at
http://code.google.com/p/kiwi/. Here is a short summary of the
functionality it can offer (mostly from the website where you can also
find more in-detail documentation):
>
> ...