Thank you for your reply, it helps a lot. About Marmotta, I'm quite happy to write the documentation if someone can teach me how to do it myself. I will also have a look when I have time and try to submit pull requests if I think some bits of my own documentation can benefit the rest of the community.
About remote SOLR, I will have a look again into this but I could possibly use some help to set that up. Once again, I'm happy to give back any knowledge that I get from this process in the form of a step by step instruction guide. Ontonet: Will park this for now. Form data POST requests: Yes, turns out it is implemented, I noticed this when inspecting the graphical frontend for the enhancer, it's just the error message you get back when you send form data is misleading if you get the wrong fields: "Parsing Content as 'application/x-www-form-urlencoded' is not supported!Please directly POST the content and set the 'Content-Type' header to the media type of the parsed content. 'application/octet-stream' SHOULD BE used if the media type of the parsed content is not known." I can try to find the relevant piece of code and submit a pull request to change this message as well. Thanks for the extra info, it was helpful and useful. Best Regards, Antero On Tue, 24 May 2016 at 10:49 Rafa Haro <rh...@apache.org> wrote: > Hi Antero, > > I'm going to try to answer your questions as better as possible, but for > some of them probably Rupert could provide a better explanation. Besides > your questions, I will take a look to your documentation ASAP but please, > feel free to directly suggest any change you consider should be done. There > is a mirror of Apache Stanbol codebase at GitHub. Making pull requests > there would be a very good way for easing documentation improvements. We > can later take pull requests' diffs files and apply them directly to SVN > based local copy. > > On Mon, May 23, 2016 at 3:45 PM Antero Duarte <a.fduar...@gmail.com> > wrote: > > > Hi there, > > > > Okay, in order to keep this alive, I compiled a collection of the > > documentation that I have created related to Stanbol. I am sending this > > attached to this email as a zip file. If there is a better way to do it, > > just reply and tell me what it is. > > > > Some parts of the documentation are just an expansion on the official > > docs, so a lot of it will be repeated, just worded differently or with > some > > extra thing that I found useful. > > > > To complement this, I have some specific questions about where stanbol is > > moving towards and I'd like to welcome anyone that know the answer to any > > of them to reply to the email. > > > > What's the role of the Sesame Yard? > > The reason why I ask this is because I was able to configure a kiwi > > repository in a marmotta instance and register it in stanbol as a remote > > Sesame Yard, but unlike the Solr yard, there seems to be no way of > > connecting this to an engine and put it on an enhancement chain. Doing > this > > would allow greater flexibility as one could use marmotta as a remote > > triplestore. Is this implemented? Is it meant to work in a different way? > > > > As far as I know, that is exactly the use case the Sesame Yard was planned > for. As you have also stated, others have reported in the list several > problems for using it within a Linking Engine. So this is again a good > opportunity for compiling an step by step tutorial and include it as part > of the documentation. Anyway, and Rupert could probably confirm this point, > you must take into account that linking process is somehow limited using a > Sesame Yard. Several features of the Entity Lookup process in Stanbol are > totally coupled to the Solr Yard, basically because there is no way to > achieve the same with SPARQL queries and also because Triplestore's don't > provide fully fulltext search support > > > > > > What is the current version of Solr bundled with Stanbol, and are we > > planning on moving on to some more recent version? > > > > Stanbol's trunk solr's current version is 4.4.0. I suppose we can upfrade > to Solr 5, but I don't see a major issue with that right now. > > > > > > What is the status of connecting to a remote Solr instance? > > Stanbol already uses Solr in an embedded way so from an abstract > > perspective, it shouldn't be too hard to just plug it in to a remote > > instance of Solr possibly running in a different server. The advantages > of > > this would be obviously the decoupling of function and storage, more > > flexibility and control over the Solr instance (i.e applying a > > visualisation layer like banana <https://github.com/lucidworks/banana> > on > > it), but also an easier route to connect directly to the solr instance > > which I don't know how everyone else sees it, but I see it as just having > > more flexibility. > > > > Again, AFAIK, this is already possible. The main limitation of using an > stand-alone Solr server is that you could not use the current Stanbol FST > engine. FST is the best option if your knowledge base is very large, which > by the way would be probably the major reason for using an external Solr > cluster. > > > > > > What's both the current role and the "proposed" role of ontonet? > > Is it supposed to define a namespace globally? For example, if I > > define an ontology in ontonet, I don't need to worry about defining it > when > > I create a new custom vocabulary and I can just use it in the raw RDF > data? > > > > I can't help you with nothing regarding Ontonet, I have never used it, > sorry. > > > > > > How far are we from accepting form data POST requests to the enhancer? > > Frameworks and libraries like Express.js for node.js are deprecating > > the use of raw POST requests in favour of form data POST requests, is > this > > something Stanbol will want to at least support? > > > > Mmmm, I'm again not sure, it sounds to me that this is already supported, > but I would need to check it. If not, could you please create a Jira issue > for this? > > Thanks! > > > > > > Sorry for this huge dump of information, but these are just some things > > that have been on my mind for quite a while and this seemed like the best > > timing for sharing them with the community. As I said before, feel free > to > > comment on those if you know any answers, criticize my lack of research > if > > anything I ask has been said somewhere by someone before and comment on > the > > documentation I am providing (especially the places where I ask for > help). > > > > Best Regards, > > Antero > > > > On Fri, 20 May 2016 at 23:06 Stefano Cossu <sco...@artic.edu> wrote: > > > >> Hello, > >> > >> Great to see so much feedback. As A. Soroka mentioned, some Fedora > >> adopters are already using Stanbol or looking into it. We at the Art > >> Insitute of Chicago fall in the latter category. > >> > >> Reading and understanding the documentation has been tough indeed. I > have > >> some use cases and I have been trying to figure out whether Stanbol is a > >> good fit for them, but I cannot match what I read in the docs with what > I > >> have in my running Stanbol instance (for example, where is the content > >> hub?). Also, without a reasonably regular release schedule or a 1.x > release > >> available, it is hard to rely on Stanbol for tasks beyond experimental > or > >> ancillary. > >> > >> With a massive introduction of Linked Data concepts in the latest > version > >> of Fedora I foresee it being just a matter of time until more folks will > >> start looking at something to resolve semantic integration issues. If > that > >> is Stanbol's goal, it would be great to rely on a community project > rather > >> than on individual implementations. > >> > >> The AIC has very limited developer resources, but we may be able to > >> contribute with use cases, ideas, testing, and spreading the word; and > I am > >> sure that if enough awareness arises, more contribution may come from > other > >> sides. > >> > >> > >> Thanks, > >> > >> Stefano > >> > > > >> On 05/20/2016 06:34 AM, Antero Duarte wrote: > >> > > Hi, > >> > >> I will gather all the documentation I have, create some comments on what > >> I don't really understand and essentially got to work on a trial-error > >> basis and then I will send these to everyone. I will also outline in the > >> same email some features I don't understand, some features that I think > are > >> useful but don't know how to configure/ not sure if they are actually > fully > >> implemented and a list of items that I came across that no longer > apply/are > >> deprecated. > >> > >> Regards, > >> Antero > >> > >> On Fri, 20 May 2016 at 11:39 Rafa Haro < <rh...@apache.org> > >> rh...@apache.org> wrote: > >> > >> HI Antero, > >> > >> > >>> > >>> On Fri, May 20, 2016 at 12:23 PM Antero Duarte < <a.fduar...@gmail.com > > > >>> a.fduar...@gmail.com> wrote: > >>> > >>> > Hi there, > >>> > > >>> > Stanbol is great and I would hate to see it die. > >>> > > >>> > >>> Couldn't be more agree! > >>> > >>> > > >>> > About the lack of feedback from users/developers, I can only say that > >>> it > >>> > took quite a while for me to be able to reply to someone on this > >>> mailing > >>> > list because the learning curve is so steep. I bet a lot of people > >>> still > >>> > read and are interested in stanbol updates, but they just don't have > >>> the > >>> > technical know-how to be involved. I include myself in this group, I > >>> have > >>> > answered a couple of questions, but only really basic ones, as I fear > >>> my > >>> > knowledge of the platform as a whole doesn't allow me to answer more > >>> > complicated questions. > >>> > > >>> > I think one step that definitely needs to be taken is > >>> improving/updating > >>> > the existing documentation. I know for a fact that one thing that > >>> really > >>> > put me off when I first started using stanbol was the that there was > >>> > documentation that was unclear, examples that were unable to be > >>> reproduced > >>> > for several reasons, and outdated documents that referenced > components > >>> that > >>> > no longer existed in the latest stable release of stanbol (I'm not > even > >>> > talking about the latest build from trunk). > >>> > > >>> > >>> That's true again imho. Also Development documentation, not only final > >>> user > >>> one is needed. And probably some work on making the APIs more > >>> comprehensible. > >>> > >>> > >>> > > >>> > I have a couple of documents that I have written over time that made > it > >>> > easier for me to understand how stanbol works and I could share these > >>> but > >>> > they would need to be reviewed by someone who understands stanbol a > lot > >>> > better than me. > >>> > > >>> > >>> Please share, for sure we can all take benefit from it and improve the > >>> documentation > >>> > >>> > >>> > > >>> > I understand that you have busy lives and as developers, you'd rather > >>> use > >>> > the little time you have to code than to write documentation, but if > >>> we can > >>> > make stanbol more approachable to newcomers, I believe the developer > >>> pool > >>> > would increase greatly and we could make Stanbol great again. > >>> > > >>> > >>> +1. It would be great to have also concrete examples about what > features, > >>> components and son on are not clear enough or just deprecated in the > >>> current live documentation so we can start by those > >>> > >>> Thanks a lot! > >>> > >>> > >>> > > >>> > My two cents. > >>> > > >>> > Best Regards, > >>> > Antero Duarte > >>> > > >>> > >> > On Fri, 20 May 2016 at 10:26 Rafa Haro < <rh...@apache.org> > >>> rh...@apache.org> wrote: > >>> > > >>> > > Hi Soroka, > >>> > > > >>> > > First of all, reading this kind of emails is, in my opinion, a > cause > >>> of > >>> > > happiness as a new attempt to somehow reactivate the project. I > >>> share the > >>> > > same feeling about Apache Stanbol since sometime ago. More than one > >>> month > >>> > > ago, there was a Google Hangout meeting joined by some committers > and > >>> > also > >>> > > users. We tried to sketch an immediate roadmap and planned to > release > >>> > > version 1.0 in the following weeks after that meeting. We sent an > >>> email > >>> > to > >>> > > the list with the meeting minutes, but after that there was a lot > of > >>> > > silence again. > >>> > > > >>> > > Probably the main problem right now is probably the lack of quality > >>> time > >>> > to > >>> > > dedicate to the project for the current active committers. I can > only > >>> > speak > >>> > > for myself: in my particular case, in the last year I have used > >>> Stanbol > >>> > for > >>> > > a couple of projects, we developed a couple of custom engines that > >>> we can > >>> > > prepare for contribution, but we never found the proper time to do > >>> this, > >>> > > among other things because we didn't have clear if those engines > >>> could be > >>> > > useful for the community. And that is probably another symptom, we > >>> have > >>> > > been progressively losing feedback from users, > >>> developers....community: > >>> > > there are less and less messages in the mailing list every month. > >>> This > >>> > > scenario is probably not too much motivating for aiming > >>> contributions and > >>> > > finding new committers. There are probably more reasons, like > >>> Stanbol is > >>> > > not technically very friendly to be approached. > >>> > > > >>> > > Of course I'm not saying this situation is someone fault. I'm not > >>> very > >>> > sure > >>> > > about the best recipe for improving the situation either. > >>> > > > >>> > > Thoughts? > >>> > > > >>> > >> > > On Thu, May 19, 2016 at 5:49 PM A. Soroka < <aj...@virginia.edu> > >>> aj...@virginia.edu> wrote: > >>> > > > >>> > > > Hi, Stanbol folks! > >>> > > > > >>> > > > I'm writing to you on behalf of the community of Fedora Commons ( > >>> > > > http://fedora-commons.org). Fedora is an information > architecture > >>> with > >>> > > > open source reference implementation that has come into wide use > >>> over > >>> > the > >>> > > > last fifteen years in the "cultural heritage" world of libraries, > >>> > > archives, > >>> > > > museums, etc. For many years, we've been intensely concerned with > >>> the > >>> > > ideas > >>> > > > that go under the loose label of "the Semantic Web". In fact, the > >>> > latest > >>> > > > edition of Fedora is an Linked Data Platform implementation, > >>> amongst > >>> > > other > >>> > > > things. > >>> > > > > >>> > > > Several institutions using Fedora are also using Stanbol for > >>> various > >>> > > tasks > >>> > > > (supporting OpenRefine, metadata entity management, NER, etc.), > and > >>> > some > >>> > > > discussion has occurred about its state and future potential. > It's > >>> not > >>> > > > totally clear to us what kind of development community and > >>> commitment > >>> > > > therefrom currently exists. There has been discussion about a 1.0 > >>> > release > >>> > > > of Stanbol, but there doesn't seem to be much other activity in > the > >>> > > > codebase, with very few of the listed committers making commits. > >>> > > > > >>> > > > We were wondering if it is possible to get a better sense of the > >>> > > > near-mid-term future of the project. Is there a road map beyond > >>> the 1.0 > >>> > > > release? Is Stanbol seeking new developers? What kinds of > >>> resources are > >>> > > > missing to put more vitality back into Stanbol? It's an excellent > >>> > project > >>> > > > filled with great ideas and we'd like to see it move forward. > >>> > > > > >>> > > > We'd be happy to get together for a telephone call / Google > >>> Hangout / > >>> > > > other meeting, if that seems useful! > >>> > > > > >>> > > > --- > >>> > > > A. Soroka > >>> > > > The University of Virginia Library > >>> > > > > >>> > > > > >>> > > > >>> > > >>> > >> -- > >> > >> Stefano Cossu > >> Director of Application Services, Collections > >> > >> The Art Institute of Chicago > >> 116 S. Michigan Ave. > >> Chicago, IL 60603 > >> 312-499-4026 > >> > > >
