Hi Samuel,
Sorry that I'm not answering any of your questions, but I wanted to clarify
something. My understanding of RDFIO is as follows: it takes in triples
that might look like:
"Joe Average" foaf:phone 123-4567
For such a triple, it would then find the page on the wiki called "Joe
Average", and if it doesn't exist, create it; and add something like the
following to the page:
[[Phone::123-4567]]
It would then also create the page "Property:Phone" on the wiki, and add to
it something like:
[[Has type::Telephone number]] (...or "String", "Text", etc.)
[[Equivalent URI::http://xmlns.com/foaf/0.1/phone]]
The latter seems totally fine to me. It's the former, the actual placement
of data on the page, that seems like it might be a problem. As I'm sure you
know, SMW data these days is usually stored via templates. Templates have a
lot of advantages to them, even if you're not using forms: they enforce a
consistent data structure and display, they make it easier to modify the
semantic "back-end", and they make editing easier, again whether or not you
use forms. So I would think that, ideally, any import system should create
or modify template calls, instead of adding hard-coded SMW tags.
You might argue that it doesn't really matter because users aren't supposed
to be editing these calls anyway - that SMW is just being used as a storage
mechanism for RDF data that's generated and maintained elsewhere. If that's
true, though, then maybe the whole concept of using SMW is an unnecessary
hack? I know that SMW offers a lot of advantages in terms of visualization,
but perhaps the real effort should be spent on getting visualization of
arbitrary RDF data improved? There are various tools that could potentially
be used for the job - Spark, Exhibit, Miga (sorry for the plug), and who
knows what else. This probably deserves a separate thread; but using SMW as
a repository for external RDF seems like both a hack and contrary to the
spirit of RDF - which is all about distributed queries. SPARQL + result
formats, in whatever form that takes, could be a big deal.
If the goal is rather a one-time import - and for the wiki's users to edit
the data from that point on - then again, I think template calls are the
way to go, if that's possible. That might require a retooling of at least
the import interface, though.
Any thoughts? Am I missing something?
-Yaron
On Tue, Oct 22, 2013 at 9:18 AM, Samuel Lampa <samuel.la...@gmail.com>wrote:
> I realize my post was a kind of fussy, so here are a few specific
> questions instead:
>
> == Question 1: Current status for import in SMW ==
>
> Is there any ongoing work to improve the import functionality in SMW?
>
>
> == Question 2: Interest in developing import in SMW ==
>
> Is there any interest or even plans to improve the import functionality
> in SMW?
>
>
> == Question 3: Interest in rewrite / update of SMWWriter ==
>
> More specifically, is there any interest in rewiving / rewriting /
> updating SMWWriter [1], or create something equivalent: A generic
> fact-editing interface, as an extension to the MediaWiki API?
>
> Comment 1: Note that SMWWriter (and later RDFIO) provides fact editing
> via *update of wiki articles*, not by directly inserting into a triple
> store. This is a big distinction, as most other SMW import tools I have
> seen take the second approach. The first approach though, of importinng
> *via wiki article updates*, has the benefit that it is totally
> independent of what triple store is using, and is of course crucial if
> one wants to have the wiki articles and the triplestore, in sync.
>
> Comment 2: It would be nice to have one, well supported, such
> functionality, which I could build upon from RDFIo, and other RDF /
> SPARQL tools that needs import functionality, could use as well.
>
>
> == Comments on all the questions ==
>
> The background to these questions is that I'm thinking about the future
> of import in SMW and would be happy if the core import functionality
> could be maintained for a foreseable future, independent on development
> of 3rd-party extensions such as RDFIO.
>
> I'm happy to help in that direction, but to make this become a trusted
> high-quality part of the Semantic Bundle for example, I'm afraid, would
> require the skills of someone with more programming experience and
> in-depth knowledge of SMW internals.
>
> Thus, I'm polling whether someone is interested in taking on such a
> project, alone or in collaboration?
>
>
> Best Regards
> // Samuel
>
>
> [1] http://semantic-mediawiki.org/wiki/Help:SMWWriter
>
>
>
>
>
>
>
> On 2013-10-21 15:23, Samuel Lampa wrote:
> > Hi all,
> >
> > What is the current status of (REST) APIs and import functionality in
> > SMW?
> >
> > As some of you might have noticed, I have been working a bit lately on
> > trying to finish the RDFIO extension to a workable state, efter many
> > years. At the same time, haing gone, over the last couple of years, to
> > a very green coder-wannabe, to having at least some year of working
> > coding experience, I start to get some perspective of what was the
> > situation before we started developing RDFIO, and what would have been
> > a more optimal path:
> >
> > 1. I realize Denny's SMWWriter was already very much operating in the
> > way one would want for this kind of module (exposed via the MediaWiki
> > REST API).
> >
> > 2. Thus, I wish I would have rather extended that with the SPARQL
> > functionality of the current RDFIO extension, and worked to drop the
> > dependency on the POM module.
> >
> > Instead, by lack of overview of things, I went away to create
> > specialized Special pages for everything (RDF Import, SPARQL endpoint,
> > and recently SPARQL endpoint copy / replication), and basically made
> > RDFIO into an add-on hack over how SMW normally works.
> >
> > It turns out I simply haven't seen the big picture clear enough to see
> > how things should have been done from the start, and to appreciate
> > Denny's work on this already :P
> >
> > So, when looking into the future, I would like to hear your thoughts
> > on the current situation regarding external APIs, and import
> > functionality, in SMW, and in which direction you would be interested
> > to work?
> >
> > Personally, while RDFIO is now there and functionality starts to be
> > reasonably stable*, I would love to have these things more packaged
> > like how the SMWWriter extension was (mostly exposing functionality
> > via MW API), and possibly integrated in the SMW core and less like how
> > it is now, with RDFIO as a separate box, doing it's stuff it's own way.
> >
> > For the move towards using MW API more, that would quite probably be
> > the future plans for RDFIO, if I can find an opportunity to continue
> > on it.
> >
> > A move towards SMW core of similar functionality (probably by newly
> > written code, and provided that is a thinkable direction for the core
> > devs), would most probably take a more skilled programmer / set of
> > programmers, than me alone, and I'm thus interested to hear what you
> > think about all this?
> >
> > Cheers
> > // Samuel
> >
> >
>
>
> --
> Developer at www.uppmax.uu.se & www.farmbio.uu.se
> M: samuel.la...@it.uu.se
> G: samuel.la...@gmail.com
> S: samuellampa
> P: +4670-2073732
> T: @smllmp
> B: saml.rilspace.org
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Semediawiki-devel mailing list
> Semediawiki-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>
--
WikiWorks · MediaWiki Consulting · http://wikiworks.com
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
