Hi, On 09.01.2013, at 11:49, Sergio Fernández <[email protected]> wrote: > `-- server > `-- client > `-- tools > `-- extras > > Where: > * 'server' will contain the actual Linked Data server
I would not use "server" as root for the "Linked Data Platform" implementation but rather use it for providing different server configurations, packagings and so on. IMO "ldp" or "core" would be better candidates for modules implementing the "Linked Data Platform". best Rupert > * 'client' the different implementations of the client library > * 'tools' all useful tools, including installation infrastructure, maven > plugins and archetypes > * 'extras' all extra stuff, such as kiwi triple store, sesame tools, ldpath > and so on > > Hope this proposal would fit with current and future modules. > > What I'm not sure is how to do with some things, such as SKOSjs... maybe put > it under 'extras'. > > Cheers, > > > On 08/01/13 14:24, Jakob Frank wrote: >> Hi, >> >> from my point of view after reading through the thread we should have >> four main "products/branches/reop-parts" with the current lmf-modules >> assigned as followed >> >> - Linked Data Server >> - lmf-core >> - lmf-sparql >> - lmf-ldcache >> - lmf-ldpath >> - lmf-webapp >> - lmf-installer >> - lmf-splash (?) >> - Client Libraries >> - lmf-client-* >> - KiWi Triple Store >> - kiwi >> - lmf-reasoner >> - lmf-versioning >> - LDPath >> - ldpath >> - Tools& More >> - *-maven-plugin >> - lmf-archetype-* >> - sesame >> >> I'm not sure about lmf-splash (maybe this should be merged into >> lmf-installer?). >> >> Like Thomas, I think lmf-security in its current state should be rather >> merged into lmf-core and replaced by a resource/triple centered security >> module. >> >> On the other hand I believe lmf-user is too closely coupled to the >> backend database model to be used with a generic sesame backend. >> (Sebastian is currently working on this separation (KiWi Triple Store)). >> >> >> Best, >> Jakob >> >> On Thu, 2013-01-03 at 14:11 +0100, Sergio Fernández wrote: >>> Hi, >>> >>> Now that INFRA-5610 [1] has been solved, before work over MARMOTTA-2 >>> [2], in the following days I'd like to discuss with all people what code >>> we'll import into Marmotta. >>> >>> The idea is to have a milestone releasing LMF 2.4 this month, and then >>> move to Marmotta. But, as we asserted in the proposal [3], the whole LMF >>> will not be contributed to Marmotta; to focus the project, actually only >>> those parts that make up the "Linked Data Platform", that includes the >>> following modules: >>> >>> * lmf-core >>> * lmf-sparql >>> * lmf-cache >>> * lmf-reasoner >>> * lmf-scheduler >>> * lmf-security >>> * lmf-ldpath >>> * lmf-versioning >>> * lmf-webapp >>> >>> There are some generic libraries we may also include: >>> >>> * ldpath >>> * sesame-tools >>> >>> Plus some installation infrastructure: >>> >>> * lmf-installer >>> * lmf-splash >>> >>> Around that there are some Maven plugins: >>> >>> * lmf-maven-plugin >>> * buildinfo-maven-plugin >>> * refpack-maven-plugin >>> >>> And archetypes: >>> >>> * lmf-archetype-module >>> * lmf-archetype-webapp >>> >>> On top of that, the lmf client library is currently implemented in >>> different languages: >>> >>> * lmf-client-java >>> * lmf-client-php >>> * lmf-client-js >>> >>> Besides some refactorizations and reorganization, I consider all those >>> artifacts relevant for Marmotta. >>> >>> For instance, all the media stuff would be out of the importation, >>> including: >>> >>> * lmf-search >>> * lmf-social >>> * lmf-classifier >>> * lmf-stanbol >>> >>> But I have doubts regarding some third-party tools: >>> >>> * SKOSjs >>> * Module for Drupal >>> * Extension for Google/Open Refine >>> >>> >>> What do you think? >>> >>> Cheers, >>> >>> >>> [1] https://issues.apache.org/jira/browse/INFRA-5610 >>> [2] https://issues.apache.org/jira/browse/MARMOTTA-2 >>> [3] http://wiki.apache.org/incubator/MarmottaProposal#Initial_Source >>> >> > > -- > Sergio Fernández
