Archive talk:OntoLTS



Thread titleRepliesLast modified
Rule Knowledge322:39, 17 June 2013
SMW+ Community??221:50, 11 June 2013
ResearchSpace519:50, 10 June 2013
Documentation018:53, 10 June 2013

Rule Knowledge


if I am not totally wrong, the Rule Knkowledge extension required the proprietary Triple Store Connector to work, as SMW did not have a triple store connection then. Does anybody have an insight, if we can continue it using the core's ts connection?

Kind regards


06:10, 17 June 2013

I'm not a TSC user (yet) though I do think TSC is presently part of SMW Halo extension. I've proposed elsewhere that SMW Halo be broken into at least 4 (standalone) extensions, one of which would be the TSC Connector. I suspect that the TSC Connector is sensitive to the SMW level, consequently wont run now on SMW 1.8. Looking at SMWHalo/smwtsc/SMWTSC.php, one gets the impression that TSC was intended eventually to be its own extension.

So I'm hearing Rule Knowledge requires TSC because its interface uses SPARQL not Ask syntax? Any thoughts about recoding it for the Ask syntax? Thanks - jmc

19:19, 17 June 2013

Apart from few experiments, I am no TSC user either - so I cannot really help out here. Still, I am wondering about the different approaches of the core's ability to connect to a TS like described in Using SPARQL and RDF stores and the TSC. Wouldn't it be neat to have Rule Knowledge use the existing TS-connection?

22:39, 17 June 2013

Am thinking Talk:OntoLTS/Rule Knowledge may be a good place to have this discussion. Feel free to start the OntoLTS/Rule Knowledge page of course.

19:22, 17 June 2013

SMW+ Community??

Following up e-mail discussions I strongy argument against objectives like "Re-form the SMW+ community & support with documentation, tools, listserv & chatroom(s)" and "Ensure SMW+ remains relevant in a Wikidata-oriented environment"

We should not make the same mistakes again. There is already a very viable SMW community that is happy to support developement of features/functionality/extensions in core SMW or SMW extensions without the dependency horror of SMW+

I don't think we need a separate SMW+ community support. Just write great extensions using old code pieces and release them. Best example is

And SMW is already very relevant!

08:54, 11 June 2013

It wasn't my intention that the SMW+ community be distinguishable from the SMW community -- I agree that we want them to be the same now! We've procured 'permission' from the SMW community to discuss these extensions on SMW's mailing list, listserv, and chatroom, so the objective has been achieved in my opinion (this objective was written prior to having heard their welcoming us). So I'll edit that objective to be less misleading.

And I agree the Wikidata reference is unnecessary. I'll delete this.

18:53, 11 June 2013

Hi Bernhard,

I agree with you and John, that SMW+-features should be supported as part of the SMW-core, as far as the lead designers are d'accord, and as normal extensions to SMW.

Still, the existing documentation, if they are to be granted to us, should well be seen as a valuable asset that will ease the task of integrating into SMW and the SMW documentation. It is for that reason that I consider this the right place and frame to work on the things, that will enrich SMW as such.

Thanks to John for reactivating the motivation to work on it!

Kind regards


21:50, 11 June 2013


Hello! We (Onototext) are considering using SMW for the next version of the project This is still in the future, but we may decide to use (some parts of) SMW+. So we'd be interested in this collaboration

17:06, 5 February 2013
Edited by author.
Last edit: 08:40, 7 February 2013

Hi Vladimir,

That's Ontotext, right (as in the developer that's involved in Europeana, among other things)? I'd be very interested to keep an eon your work if you decide to go ahead and use either SMW or SMW+.

Anyway, this is actually the wrong venue. To contact the SMW devs (which I'm not), it's probably best to use the mailing list: I don't know what the story is with SMW+ these days.

21:01, 6 February 2013

I wouldn't say this is the wrong venue, actually - this is a discussion that's not restricted to just current SMW devs. And on the main page, it says "Please use talk pages for commentary."

22:54, 6 February 2013

Hi Cavila, nice to meet you! Yes, we provide a sparql endpoint for Europeana's EDM data, currently on trial basis.

Hi Yaron! The more I read about SMW the more I think it's the right platform for ResearchSpace.

  • The reason I want to explore SMW+ is mostly WYSIWYG: I am told repeatedly that art researchers cannot learn Wikitext nohow noway.
  • WikiMedia has started a major dev effort to create a fully-featured and safe visual editor: wikipedia:Wikipedia:VisualEditor. But it still doesn't handle a lot of stuff.
  • If we can't revive Halo's WYSIWYG, I guess we can just go with the pattern "form on top, followed by a free-text field, that uses some WYSIWYG editor"
  • The client at BM is also fond of pretty-looking UIs (which a MW skin would cover)
  • So you may want to emphasize WYSIWYG and skinning options in your brief.
11:12, 7 February 2013

For the sake of adding to the movement, like Vladimir, I'm also particularly interested in WYSIWYG. Right now, I'm stuck at MW 1.16 because it works (the most) reliably with SF 2.4 / FCKEditor. I've played with MW updates and associated SMW extension updates, and they have a lot of cool features that I can use immediately, but unfortunately most of my contributors need the editor. As it stands, I'm once again considering moving to MW 1.17 just to get the current OntoLTS installed... but with 1.20 out and stable, and semantic bundle about to not care about mw 1.17, I'm not crazy about that plan.

As far as I can tell, the WYSIWYG functionality exceeds the planned fuunctionality of the new VisualEditor, particularly in the area of Word import... though obviously roadmaps may change.

I'm probably too new and too busy to contribute, but if I can I will.

Take care. Sal

17:38, 5 March 2013

but with 1.20 out and stable, and semantic bundle about to not care about mw 1.17

Please understand that SMW+ extensions have many interfaces to both MW and SMW. Sure there'll be those that work with MW 1.18+ also, but I think it's important for our present goals to be focused on MW LTS version, with express understanding that all SMW+ extensions must work with the most recent, and all legacy, SMW versions.

I'm not bothered by SemBundle's policy that its deployment is without regard to MW LTS, but I'd be a bit surprised to hear that it'll reach a point that it can't be installed on MW 1.17.

19:50, 10 June 2013



I would like to add to the documentation. Having used (= administered & customized) SMW+ for quite some time, I might be able to add some stuff. Waiting for the starting signal.

Kind regards


18:53, 10 June 2013