From: Samuel L. <sam...@gm...> - 2013-10-21 13:24:10
|
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 |
From: Samuel L. <sam...@gm...> - 2013-10-21 13:30:40
|
To give some more background for my thoughts, I realize that the main reasons for not including SMWWriter in core at the time, have been the dependencies it was relying upon (Page Object Model): http://semantic-mediawiki.org/wiki/Help:SMWWriter The size of the code is also mentioned, but I wonder whether that is really a case anymore, with the growing size of the SMW core library itself anyway? I could mention that RDFIO currently depends on Wiki Object Model [1], rather than Page Object Model, due to better stability, but I had in my plans to try to drop even that dependency if possible, as the next step for RDFIO. // Samuel 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: sam...@it... G: sam...@gm... S: samuellampa P: +4670-2073732 T: @smllmp B: saml.rilspace.org |
From: Samuel L. <sam...@gm...> - 2013-10-21 14:30:16
|
Just another note ... future work would probably need to do something about the RDF library dependency situation. The current state of ARC2, with 30 open issues [1], and no SPARQL 1.1 support, is a little worrying. Haven't got my head around EasyRDF [3] enought to say if it covers all the functionality of ARC2 though, so can't tell. [1] https://github.com/semsol/arc2/issues?state=open [2] https://github.com/semsol/arc2/issues/57 [3] http://www.easyrdf.org/ Best // Samuel On 2013-10-21 15:30, Samuel Lampa wrote: > To give some more background for my thoughts, I realize that the main > reasons for not including SMWWriter in core at the time, have been the > dependencies it was relying upon (Page Object Model): > > http://semantic-mediawiki.org/wiki/Help:SMWWriter > > The size of the code is also mentioned, but I wonder whether that is > really a case anymore, with the growing size of the SMW core library > itself anyway? > > I could mention that RDFIO currently depends on Wiki Object Model [1], > rather than Page Object Model, due to better stability, but I had in > my plans to try to drop even that dependency if possible, as the next > step for RDFIO. > > // Samuel > > > 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: sam...@it... G: sam...@gm... S: samuellampa P: +4670-2073732 T: @smllmp B: saml.rilspace.org |
From: Yaron K. <ya...@wi...> - 2013-10-21 14:53:51
|
Hi Samuel, Perhaps a bit of background information would be helpful. What does RDFIO do? What, if anything, do you want it do further? What did SMWWriter do? How do POM/WOM fit into this whole thing? And how does this relate to the RDF triplestore functionality that SMW now has? -Yaron On Mon, Oct 21, 2013 at 10:30 AM, Samuel Lampa <sam...@gm...>wrote: > Just another note ... future work would probably need to do something > about the RDF library dependency situation. The current state of ARC2, > with 30 open issues [1], and no SPARQL 1.1 support, is a little worrying. > > Haven't got my head around EasyRDF [3] enought to say if it covers all > the functionality of ARC2 though, so can't tell. > > [1] https://github.com/semsol/arc2/issues?state=open > [2] https://github.com/semsol/arc2/issues/57 > [3] http://www.easyrdf.org/ > > Best > // Samuel > > On 2013-10-21 15:30, Samuel Lampa wrote: > > To give some more background for my thoughts, I realize that the main > > reasons for not including SMWWriter in core at the time, have been the > > dependencies it was relying upon (Page Object Model): > > > > http://semantic-mediawiki.org/wiki/Help:SMWWriter > > > > The size of the code is also mentioned, but I wonder whether that is > > really a case anymore, with the growing size of the SMW core library > > itself anyway? > > > > I could mention that RDFIO currently depends on Wiki Object Model [1], > > rather than Page Object Model, due to better stability, but I had in > > my plans to try to drop even that dependency if possible, as the next > > step for RDFIO. > > > > // Samuel > > > > > > 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: sam...@it... > G: sam...@gm... > 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=60135031&iu=/4140/ostg.clktrk > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Samuel L. <sam...@gm...> - 2013-10-21 15:16:55
|
Yeah, sorry, you're right. I'm too indulged in my own thoughts, so I forget to provide context ... So, a quick overview of the motivation, history and current status of RDFIO: == Two usa cases == The start of RDFIO was when me and Denny realized we were thinking of the same thing: "Providing a means of updating the (semantic) text in wiki articles, using SPARQL." I aditionally wanted to be able to: "Import *plain RDF triples*, with no need for an ontology, into wiki pages, keep the original URI:s, and be able to export / query the triples in their *original* format" This was not possible at the time, since the existing "ontology import", would AFAIK only import the "classes" of an OWN ontology. Not the "instances" of plain RDF triples. == Low hanging fruit, using existing parts == As most pieces was there already to implement these two features, it seemed kind of a low hanging fruit. At that point, the existing pieces were: * SMWWriter Denny's extension for updating semantic text in wiki articles, via MW API * PageObjectModel An extension providing a programmatic API to access and modify content of wiki pages * ARC2 A PHP RDF library, providing parsers between most common RDF formats and SPARQL, and also including a pure PHP based SPARQL endpoint. Later, the SMWWriter and PageObjectModel were dropped, since WikiObjectModel could do the same (except expose the functionality via MW API), and provided better stability. == Current status == In the first version (the one currently in the MW repos), RDFIO was a large and ugly hack, and almost impossible to maintain. Since a year or two back, I've been working on a complete rewrite of RDFIO (currently hosted at github) with a much more straightforward approach, and with a bit less dependencies (and hope to improve that still). I have now, the last weeks, tried to improve the reliability of the code by adding a bunch of unit tests, and some system tests, and I think it is now stable enough for wider testing. === Current features === The current features are: 1. RDF Import - Import plain RDF triples into wiki pages and facts, with some configurable logic for how to figure out suitable wiki titles for URI:s. 2. SPARQL endpoint - A Pure PHP SPARQL endpoint with write capabilities (using ARC2:s custom SPARQL+ syntax) to update wiki article content. Also has options to query by using original URI:s (those used when importing external RDF data), rather than SMW:s internal format (on eht form "http://...Special:URIResolver/..."). 3. SPARQL Import - Point at an external SPARQL endpoint and start importing it's triples (Only manually, 10 triples at a time, so far). Hope it provide the context needed! ... otherwise, feel free to ask more! Best // Samuel On 2013-10-21 16:53, Yaron Koren wrote: > Hi Samuel, > > Perhaps a bit of background information would be helpful. What does > RDFIO do? What, if anything, do you want it do further? What did > SMWWriter do? How do POM/WOM fit into this whole thing? And how does > this relate to the RDF triplestore functionality that SMW now has? > > -Yaron > > > On Mon, Oct 21, 2013 at 10:30 AM, Samuel Lampa <sam...@gm... > <mailto:sam...@gm...>> wrote: > > Just another note ... future work would probably need to do something > about the RDF library dependency situation. The current state of ARC2, > with 30 open issues [1], and no SPARQL 1.1 support, is a little > worrying. > > Haven't got my head around EasyRDF [3] enought to say if it covers all > the functionality of ARC2 though, so can't tell. > > [1] https://github.com/semsol/arc2/issues?state=open > [2] https://github.com/semsol/arc2/issues/57 > [3] http://www.easyrdf.org/ > > Best > // Samuel > > On 2013-10-21 15:30, Samuel Lampa wrote: > > To give some more background for my thoughts, I realize that the > main > > reasons for not including SMWWriter in core at the time, have > been the > > dependencies it was relying upon (Page Object Model): > > > > http://semantic-mediawiki.org/wiki/Help:SMWWriter > > > > The size of the code is also mentioned, but I wonder whether that is > > really a case anymore, with the growing size of the SMW core library > > itself anyway? > > > > I could mention that RDFIO currently depends on Wiki Object > Model [1], > > rather than Page Object Model, due to better stability, but I had in > > my plans to try to drop even that dependency if possible, as the > next > > step for RDFIO. > > > > // Samuel > > > > > > On 2013-10-21 15:23, Samuel Lampa wrote: > >> Hi all, > >> > >> What is the current status of (REST) APIs and import > functionality in > >> SMW? > > <snip> > |
From: James HK <jam...@gm...> - 2013-10-21 16:24:21
|
Hi, ## SMWWriter/POM Looking at the extension and taken into the account the following statement "This page describes an extension developed in 2010, which was not released and appears to have been abandoned." [1] that SMWWriter/POM will be less likely a candidate for building a core component and therefore other means [2] should be discussed to support such feature in future. Start and endpoint for SMW is the subject (a wikipage article), any modification should go through and triggered by an appropriate update of a subject. If possible all updates should use the official MW API to avoid any issues that would arise by a data model change (either on the side of MW or SMW). ## RDF/ Export In the past, RAP[3] was part of SMW which has been discontinued for some reasons and Wikidata [4] decided to use easyRDF for the export. ## Serialization Maybe of interest (while not directly related to this thread), SMW 1.9 comes with a full serializer/deserializer of a SemanticData container ([5], [6], [7], [8]) that can be used externally. ## SPARQL I can't say anything about it as I'm not sufficiently involved in this topic. [1] http://semantic-mediawiki.org/wiki/Help:SMWWriter [2] http://www.mediawiki.org/wiki/API:Edit [3] http://www.wiwiss.fu-berlin.de/suhl/bizer/rdfapi/ [4] http://lists.wikimedia.org/pipermail/wikidata-tech/2013-May/000005.html [5] https://github.com/wikimedia/mediawiki-extensions-SemanticMediaWiki/blob/master/includes/api/ApiBrowse.php [6] https://github.com/wikimedia/mediawiki-extensions-SemanticMediaWiki/blob/master/docs/api.md [7] https://github.com/wikimedia/mediawiki-extensions-SemanticMediaWiki/blob/master/includes/serializer/Serializers/SemanticDataSerializer.php [8] https://github.com/wikimedia/mediawiki-extensions-SemanticMediaWiki/blob/master/includes/serializer/Deserializers/SemanticDataDeserializer.php Cheers On 10/22/13, Samuel Lampa <sam...@gm...> wrote: > Yeah, sorry, you're right. I'm too indulged in my own thoughts, so I > forget to provide context ... > > So, a quick overview of the motivation, history and current status of > RDFIO: > > == Two usa cases == > > The start of RDFIO was when me and Denny realized we were thinking of > the same thing: > "Providing a means of updating the (semantic) text in wiki articles, > using SPARQL." > > I aditionally wanted to be able to: > "Import *plain RDF triples*, with no need for an ontology, into wiki > pages, keep the original URI:s, and be able to export / query the > triples in their *original* format" > > This was not possible at the time, since the existing "ontology import", > would AFAIK only import the "classes" of an OWN ontology. Not the > "instances" of plain RDF triples. > > > == Low hanging fruit, using existing parts == > > As most pieces was there already to implement these two features, it > seemed kind of a low hanging fruit. At that point, the existing pieces > were: > > * SMWWriter > Denny's extension for updating semantic text in wiki articles, via MW API > > * PageObjectModel > An extension providing a programmatic API to access and modify content > of wiki pages > > * ARC2 > A PHP RDF library, providing parsers between most common RDF formats and > SPARQL, and also including a pure PHP based SPARQL endpoint. > > Later, the SMWWriter and PageObjectModel were dropped, since > WikiObjectModel could do the same (except expose the functionality via > MW API), and provided better stability. > > == Current status == > > In the first version (the one currently in the MW repos), RDFIO was a > large and ugly hack, and almost impossible to maintain. > > Since a year or two back, I've been working on a complete rewrite of > RDFIO (currently hosted at github) with a much more straightforward > approach, and with a bit less dependencies (and hope to improve that > still). > > I have now, the last weeks, tried to improve the reliability of the code > by adding a bunch of unit tests, and some system tests, and I think it > is now stable enough for wider testing. > > === Current features === > > The current features are: > > 1. RDF Import - Import plain RDF triples into wiki pages and facts, with > some configurable logic for how to figure out suitable wiki titles for > URI:s. > > 2. SPARQL endpoint - A Pure PHP SPARQL endpoint with write capabilities > (using ARC2:s custom SPARQL+ syntax) to update wiki article content. > Also has options to query by using original URI:s (those used when > importing external RDF data), rather than SMW:s internal format (on eht > form "http://...Special:URIResolver/..."). > > 3. SPARQL Import - Point at an external SPARQL endpoint and start > importing it's triples (Only manually, 10 triples at a time, so far). > > > > Hope it provide the context needed! ... otherwise, feel free to ask more! > > Best > // Samuel > > > On 2013-10-21 16:53, Yaron Koren wrote: >> Hi Samuel, >> >> Perhaps a bit of background information would be helpful. What does >> RDFIO do? What, if anything, do you want it do further? What did >> SMWWriter do? How do POM/WOM fit into this whole thing? And how does >> this relate to the RDF triplestore functionality that SMW now has? >> >> -Yaron >> >> >> On Mon, Oct 21, 2013 at 10:30 AM, Samuel Lampa <sam...@gm... >> <mailto:sam...@gm...>> wrote: >> >> Just another note ... future work would probably need to do something >> about the RDF library dependency situation. The current state of >> ARC2, >> with 30 open issues [1], and no SPARQL 1.1 support, is a little >> worrying. >> >> Haven't got my head around EasyRDF [3] enought to say if it covers >> all >> the functionality of ARC2 though, so can't tell. >> >> [1] https://github.com/semsol/arc2/issues?state=open >> [2] https://github.com/semsol/arc2/issues/57 >> [3] http://www.easyrdf.org/ >> >> Best >> // Samuel >> >> On 2013-10-21 15:30, Samuel Lampa wrote: >> > To give some more background for my thoughts, I realize that the >> main >> > reasons for not including SMWWriter in core at the time, have >> been the >> > dependencies it was relying upon (Page Object Model): >> > >> > http://semantic-mediawiki.org/wiki/Help:SMWWriter >> > >> > The size of the code is also mentioned, but I wonder whether that >> is >> > really a case anymore, with the growing size of the SMW core >> library >> > itself anyway? >> > >> > I could mention that RDFIO currently depends on Wiki Object >> Model [1], >> > rather than Page Object Model, due to better stability, but I had >> in >> > my plans to try to drop even that dependency if possible, as the >> next >> > step for RDFIO. >> > >> > // Samuel >> > >> > >> > On 2013-10-21 15:23, Samuel Lampa wrote: >> >> Hi all, >> >> >> >> What is the current status of (REST) APIs and import >> functionality in >> >> SMW? >> >> <snip> >> > > > ------------------------------------------------------------------------------ > 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=60135031&iu=/4140/ostg.clktrk > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > |
From: Samuel L. <sam...@gm...> - 2013-10-21 16:43:59
|
Hi James, Many thanks for the info and pointers! It gives me a sense of the current thinking in the topic, which is what I was looking for. On 2013-10-21 18:24, James HK wrote: > Hi, > > ## SMWWriter/POM > Looking at the extension and taken into the account the following > statement "This page describes an extension developed in 2010, which > was not released and appears to have been abandoned." [1] that > SMWWriter/POM will be less likely a candidate for building a core > component and therefore other means [2] should be discussed to support > such feature in future. > > Start and endpoint for SMW is the subject (a wikipage article), any > modification should go through and triggered by an appropriate update > of a subject. If possible all updates should use the official MW API > to avoid any issues that would arise by a data model change (either on > the side of MW or SMW). Yes, this is what is done already in RDFIO. The MW API is available both as a REST service, and as a programmatic API (which is the one that RDFIO uses), which might cause a little confusion in the discussion :) ... so, RDFIO uses MW API for writing (After the modifications of the wiki text is done with the help of WikiObjectModel / WOM). But what would be nice, is to also expose the current SPARQL based fact editing features that RDFIO provide, via the *REST* part of the API, as a separate "API-extension", or what to call it (don't know exactly how this works, but I think that is what SMWWriter did at the time). > ## RDF/ Export > In the past, RAP[3] was part of SMW which has been discontinued for > some reasons and Wikidata [4] decided to use easyRDF for the export. Yeah, EasyRDF seems to be what most people go for. It's functionality does not seem to match ARC2 completely though, which made me wait with a switch to it so far. > ## Serialization > Maybe of interest (while not directly related to this thread), SMW 1.9 > comes with a full serializer/deserializer of a SemanticData container > ([5], [6], [7], [8]) that can be used externally. Interesting! While it does not seem to contain any conversion to/from RDF / SPARQL formats, it might potentially be useful for extensions doing that, such as RDFIO. Will look closer into that. Cheers // Samuel > ## SPARQL > I can't say anything about it as I'm not sufficiently involved in this topic. > > [1] http://semantic-mediawiki.org/wiki/Help:SMWWriter > > [2] http://www.mediawiki.org/wiki/API:Edit > > [3] http://www.wiwiss.fu-berlin.de/suhl/bizer/rdfapi/ > > [4] http://lists.wikimedia.org/pipermail/wikidata-tech/2013-May/000005.html > > [5] https://github.com/wikimedia/mediawiki-extensions-SemanticMediaWiki/blob/master/includes/api/ApiBrowse.php > > [6] https://github.com/wikimedia/mediawiki-extensions-SemanticMediaWiki/blob/master/docs/api.md > > [7] https://github.com/wikimedia/mediawiki-extensions-SemanticMediaWiki/blob/master/includes/serializer/Serializers/SemanticDataSerializer.php > > [8] https://github.com/wikimedia/mediawiki-extensions-SemanticMediaWiki/blob/master/includes/serializer/Deserializers/SemanticDataDeserializer.php > > Cheers > > On 10/22/13, Samuel Lampa <sam...@gm...> wrote: >> Yeah, sorry, you're right. I'm too indulged in my own thoughts, so I >> forget to provide context ... >> >> So, a quick overview of the motivation, history and current status of >> RDFIO: >> >> == Two usa cases == >> >> The start of RDFIO was when me and Denny realized we were thinking of >> the same thing: >> "Providing a means of updating the (semantic) text in wiki articles, >> using SPARQL." >> >> I aditionally wanted to be able to: >> "Import *plain RDF triples*, with no need for an ontology, into wiki >> pages, keep the original URI:s, and be able to export / query the >> triples in their *original* format" >> >> This was not possible at the time, since the existing "ontology import", >> would AFAIK only import the "classes" of an OWN ontology. Not the >> "instances" of plain RDF triples. >> >> >> == Low hanging fruit, using existing parts == >> >> As most pieces was there already to implement these two features, it >> seemed kind of a low hanging fruit. At that point, the existing pieces >> were: >> >> * SMWWriter >> Denny's extension for updating semantic text in wiki articles, via MW API >> >> * PageObjectModel >> An extension providing a programmatic API to access and modify content >> of wiki pages >> >> * ARC2 >> A PHP RDF library, providing parsers between most common RDF formats and >> SPARQL, and also including a pure PHP based SPARQL endpoint. >> >> Later, the SMWWriter and PageObjectModel were dropped, since >> WikiObjectModel could do the same (except expose the functionality via >> MW API), and provided better stability. >> >> == Current status == >> >> In the first version (the one currently in the MW repos), RDFIO was a >> large and ugly hack, and almost impossible to maintain. >> >> Since a year or two back, I've been working on a complete rewrite of >> RDFIO (currently hosted at github) with a much more straightforward >> approach, and with a bit less dependencies (and hope to improve that >> still). >> >> I have now, the last weeks, tried to improve the reliability of the code >> by adding a bunch of unit tests, and some system tests, and I think it >> is now stable enough for wider testing. >> >> === Current features === >> >> The current features are: >> >> 1. RDF Import - Import plain RDF triples into wiki pages and facts, with >> some configurable logic for how to figure out suitable wiki titles for >> URI:s. >> >> 2. SPARQL endpoint - A Pure PHP SPARQL endpoint with write capabilities >> (using ARC2:s custom SPARQL+ syntax) to update wiki article content. >> Also has options to query by using original URI:s (those used when >> importing external RDF data), rather than SMW:s internal format (on eht >> form "http://...Special:URIResolver/..."). >> >> 3. SPARQL Import - Point at an external SPARQL endpoint and start >> importing it's triples (Only manually, 10 triples at a time, so far). >> >> >> >> Hope it provide the context needed! ... otherwise, feel free to ask more! >> >> Best >> // Samuel >> >> >> On 2013-10-21 16:53, Yaron Koren wrote: >>> Hi Samuel, >>> >>> Perhaps a bit of background information would be helpful. What does >>> RDFIO do? What, if anything, do you want it do further? What did >>> SMWWriter do? How do POM/WOM fit into this whole thing? And how does >>> this relate to the RDF triplestore functionality that SMW now has? >>> >>> -Yaron >>> >>> >>> On Mon, Oct 21, 2013 at 10:30 AM, Samuel Lampa <sam...@gm... >>> <mailto:sam...@gm...>> wrote: >>> >>> Just another note ... future work would probably need to do something >>> about the RDF library dependency situation. The current state of >>> ARC2, >>> with 30 open issues [1], and no SPARQL 1.1 support, is a little >>> worrying. >>> >>> Haven't got my head around EasyRDF [3] enought to say if it covers >>> all >>> the functionality of ARC2 though, so can't tell. >>> >>> [1] https://github.com/semsol/arc2/issues?state=open >>> [2] https://github.com/semsol/arc2/issues/57 >>> [3] http://www.easyrdf.org/ >>> >>> Best >>> // Samuel >>> >>> On 2013-10-21 15:30, Samuel Lampa wrote: >>> > To give some more background for my thoughts, I realize that the >>> main >>> > reasons for not including SMWWriter in core at the time, have >>> been the >>> > dependencies it was relying upon (Page Object Model): >>> > >>> > http://semantic-mediawiki.org/wiki/Help:SMWWriter >>> > >>> > The size of the code is also mentioned, but I wonder whether that >>> is >>> > really a case anymore, with the growing size of the SMW core >>> library >>> > itself anyway? >>> > >>> > I could mention that RDFIO currently depends on Wiki Object >>> Model [1], >>> > rather than Page Object Model, due to better stability, but I had >>> in >>> > my plans to try to drop even that dependency if possible, as the >>> next >>> > step for RDFIO. >>> > >>> > // Samuel >>> > >>> > >>> > On 2013-10-21 15:23, Samuel Lampa wrote: >>> >> Hi all, >>> >> >>> >> What is the current status of (REST) APIs and import >>> functionality in >>> >> SMW? >>> >>> <snip> >>> >> >> ------------------------------------------------------------------------------ >> 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=60135031&iu=/4140/ostg.clktrk >> _______________________________________________ >> Semediawiki-devel mailing list >> Sem...@li... >> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >> -- Developer at www.uppmax.uu.se & www.farmbio.uu.se M: sam...@it... G: sam...@gm... S: samuellampa P: +4670-2073732 T: @smllmp B: saml.rilspace.org |
From: James HK <jam...@gm...> - 2013-10-21 15:29:10
|
On 10/21/13, Yaron Koren <ya...@wi...> wrote: > Hi Samuel, > > Perhaps a bit of background information would be helpful. What does RDFIO > do? What, if anything, do you want it do further? What did SMWWriter do? > How do POM/WOM fit into this whole thing? And how does this relate to the > RDF triplestore functionality that SMW now has? > I think, Samuel provided a proper source [1] for those interested in a particular context of SMWWriter/POM/WOM dependency. [1] http://semantic-mediawiki.org/wiki/Help:SMWWriter > -Yaron > > > On Mon, Oct 21, 2013 at 10:30 AM, Samuel Lampa > <sam...@gm...>wrote: > >> Just another note ... future work would probably need to do something >> about the RDF library dependency situation. The current state of ARC2, >> with 30 open issues [1], and no SPARQL 1.1 support, is a little worrying. >> >> Haven't got my head around EasyRDF [3] enought to say if it covers all >> the functionality of ARC2 though, so can't tell. >> >> [1] https://github.com/semsol/arc2/issues?state=open >> [2] https://github.com/semsol/arc2/issues/57 >> [3] http://www.easyrdf.org/ >> >> Best >> // Samuel >> >> On 2013-10-21 15:30, Samuel Lampa wrote: >> > To give some more background for my thoughts, I realize that the main >> > reasons for not including SMWWriter in core at the time, have been the >> > dependencies it was relying upon (Page Object Model): >> > >> > http://semantic-mediawiki.org/wiki/Help:SMWWriter >> > >> > The size of the code is also mentioned, but I wonder whether that is >> > really a case anymore, with the growing size of the SMW core library >> > itself anyway? >> > >> > I could mention that RDFIO currently depends on Wiki Object Model [1], >> > rather than Page Object Model, due to better stability, but I had in >> > my plans to try to drop even that dependency if possible, as the next >> > step for RDFIO. >> > >> > // Samuel >> > >> > >> > 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: sam...@it... >> G: sam...@gm... >> 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=60135031&iu=/4140/ostg.clktrk >> _______________________________________________ >> Semediawiki-devel mailing list >> Sem...@li... >> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >> > > > > -- > WikiWorks · MediaWiki Consulting · http://wikiworks.com > |
From: Samuel L. <sam...@gm...> - 2013-10-21 15:40:54
|
On 2013-10-21 17:28, James HK wrote: > On 10/21/13, Yaron Koren<ya...@wi...> wrote: >> >Hi Samuel, >> > >> >Perhaps a bit of background information would be helpful. What does RDFIO >> >do? What, if anything, do you want it do further? What did SMWWriter do? >> >How do POM/WOM fit into this whole thing? And how does this relate to the >> >RDF triplestore functionality that SMW now has? >> > > I think, Samuel provided a proper source [1] for those interested in a > particular context of SMWWriter/POM/WOM dependency. > > [1]http://semantic-mediawiki.org/wiki/Help:SMWWriter Yeah, that page contains very good info about that, and the wish that Denny had already at that time, to extend SMWWriter with SPARQL support. // Samuel |
From: Samuel L. <sam...@gm...> - 2013-10-21 15:39:32
|
Hmm, I see I still missed to answer a couple of your questions, so here we go: On 2013-10-21 16:53, Yaron Koren wrote: > What does RDFIO do? (Answered in last mail) > What, if anything, do you want it do further? Let it provide an extension to the MediaWiki API, to allow easier access from remote tools. > What did SMWWriter do? It did the actual writing/updating of SMW facts in wiki articles (not just updating a triple store, as most other SMW addons) > How do POM/WOM fit into this whole thing? POM provided an API to wiki content, which SMWWriter used. WOM replaced SMWWriter+POM. > And how does this relate to the RDF triplestore functionality that SMW > now has? Not very much. Triple stores is a separate thing. RDFIO is dependent on the internal MySQL based triple store that ARC2 (the PHP RDF library) uses. In theory, RDFIO could be extended to work with any external triple store as well (and is on my wish-list for the future), but for the time being, the easiest was to just use ARC2:s own triple store. // Samuel -- Developer at www.uppmax.uu.se & www.farmbio.uu.se M: sam...@it... G: sam...@gm... S: samuellampa P: +4670-2073732 T: @smllmp B: saml.rilspace.org |
From: Samuel L. <sam...@gm...> - 2013-10-22 13:18:41
|
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: sam...@it... G: sam...@gm... S: samuellampa P: +4670-2073732 T: @smllmp B: saml.rilspace.org |
From: Yaron K. <ya...@wi...> - 2013-10-22 16:36:57
|
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 <sam...@gm...>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: sam...@it... > G: sam...@gm... > 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 > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Samuel L. <sam...@gm...> - 2013-10-23 14:57:54
|
Many thanks for the feedback Yaron, I really appreciate it! I think you are very right about the template calls, and in fact, it has long been on my roadmap. I think it is possible to implement, especially for RDF data where entities are linked to an OWL class. Then one can check up which template is linked from the category page equivalent to that OWL class, and use that to add facts. I definitely agree that this is how things should optimally be done. I'm coming from the perspective of messy real-world biology though, where many users are not very skilled in whatever technology goes beyond their specific field, and generating a browseable (and editable) interface to their data is a big gain per se. ... and personally, I think that simply the ability to set up a pure PHP based SPARQL endpoint to data entered via an SMW / template / SF setup, is something attractive, and that we are now looking into using RDFIO for, in one of our projects. So, based on this background, and the fact that I'm only starting to put RDFIO into real-world usage, I might not have enough realized the critical importance of the template editing feature, for most established SMW use cases, and thus not prioritized it appropriately. But I think you have a very good point here, and this should most probably be the very next step for RDFIO, to make it useful together with much of the established use cases for SMW. So, again, thanks for your input! Best // Samuel On 2013-10-22 18:36, Yaron Koren wrote: > 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 <sam...@gm... > <mailto:sam...@gm...>> 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 <http://www.uppmax.uu.se> & > www.farmbio.uu.se <http://www.farmbio.uu.se> > M: sam...@it... <mailto:sam...@it...> > G: sam...@gm... <mailto:sam...@gm...> > S: samuellampa > P: +4670-2073732 <tel:%2B4670-2073732> > T: @smllmp > B: saml.rilspace.org <http://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 > Sem...@li... > <mailto:Sem...@li...> > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > > -- > WikiWorks · MediaWiki Consulting · http://wikiworks.com -- Developer at www.uppmax.uu.se & www.farmbio.uu.se M: sam...@it... G: sam...@gm... S: samuellampa P: +4670-2073732 T: @smllmp B: saml.rilspace.org |