On 20/09/2010 11:56, Alfredas Chm wrote:
> Dear All,
>
> I can completely agree with Karima. For the connection to the triple
> store (TS) we should have an interface that people can implement the way
> they want, depending on the implementation of their triple store.
> The interface Karima describes looks very similar to the SMWStore. And I
> like the idea of extending SMWStore to get things done with minimum
> rewrite.
> In case of the SparqlExtension we extend SMWStore and achieve the
> functionality with minimum effort.
> I would suggest to create an abstract class (and interface)
> SMWTripleStore to extend the SMWStore and provide a bunch of
> utility/helper methods (semanticdata_to_triples :-).
> That would take care of the writing to the TS.
+1
So far there is no explicit abstract class in my TODO section only
because I thought that it might be easier to extract this after having
implemented (imported) a first RDF store binding, and checking how many
of its methods other classes might want to use. But in the end an
intermediate class should help implementers to create new bindings.
>
> Now getting data from the TS is a different question. Also there's a
> related question of the integration with the SRF.
The SMWStore interface includes read methods. The direct read methods
(getSemanticData-based) will continue to use the DB since they are
typically used for simple small read accesses. But we can easily include
SPARQL access methods in the same interface (note that the existing SQL
store without RDF store support will not answer SPARQL, but it can still
support such an interface if it allows to return a value that indcates
"feature not supported").
Markus
>
>
>
>
> *From:* Karima Rafes <karima.ra...@bordercloud.com>
> *To:* Markus Krötzsch <mar...@semantic-mediawiki.org>
> *Cc:* semediawiki-devel@lists.sourceforge.net
> *Sent:* Mon, September 20, 2010 2:19:55 AM
> *Subject:* Re: [SMW-devel] [RDF] Discussion
>
> Hi
>
> I'm very tired so I will be short.
>
> Only 2 truths :
> 1) SMW has always raeson. The triplets in RDF of one page IS the result
> of the query select * where {<page> ?p ?v} in the triplestore.
> 2) the customer has always raeson.
>
> So :
> 1) Any extensions rdfIO or halo, etc haven't to change the graph of SMW.
> So the user can change the extension and triplestore without redevelop
> its sparql clients. One word : Interoperability.
> 2) if you keep your old triplestore with sparul or other protocol, the
> customers will choose the old or the triplestore full compliant W3C. SMW
> is a project free so if others extensions want wait the final
> recommandation, they can keep the current version of SMW and write in
> their specifications their version of smw.
>
> My proposition :
> To respect the first truth, the extension sparql need to have two things
> in SMW :
> - Hook update/insert/delete/refreshall/deleteall data of swm : call
> class inherit of InterfaceTripleStore
> - Contract InterfaceTripleStore{
> Insert($graphName,$IriPage,$arrayTriplets);
> Update($graphName,$IriPage,$arrayTriplets);
> Delete($graphName,$IriPage);
> DeleteGraph($graphName);
> }
>
> Parameters:
> $IriPage : IRI not URI. I have to have accent in the IRI (sorry I speak
> french, lol ) and replace only space by underscore. RDF cannot use IRI
> but in the recommandation sparql in the triplestore, it's one <IRI>. For
> the value, you have to insert the tag langage ie the langage of wiki.
> $arrayTurtle : one array with 3 column. one field is a IRI (again) or
> one value like define in the recommandation of sparql 1.0.
> $graphName : usually it's the domain name of wiki example :
> http://fr.wikipedia.org/wiki
>
>
> you can use my class
> http://github.com/BorderCloud/LinkedWiki/blob/master/class/SMW_LinkedWikiStore.php
> to build the parameter arrayTriplets for one first version.
> For the Hook, the code of SMW is too dark for me. Sorry.
>
> It's simple ;) ... it's one minimum. After, we can speak of the future
> architecture of SWM with a triplestore or fork SMW...
>
> To respect the second rule :
> Do nothing, the best will win. In one year, you can ask a survey and so
> you will can copy and paste the code of the best extension in the SMW.
> (Geek rule 1 : never reinvent the wheel and copy/paste is your best
> friend. )
>
> Sorry for my english,
> Bye.
> Karima
>
>
> 2010/9/19 Markus Krötzsch <mar...@semantic-mediawiki.org
> <mailto:mar...@semantic-mediawiki.org>>
>
> On 18/09/2010 18:35, Samuel Lampa wrote:
> > On 09/18/2010 03:22 PM, Markus Krötzsch wrote:
> >> On 18/09/2010 15:05, Alfredas Chm wrote:
> >>> As the first thing on the agenda, I would like to ask Markus to
> create a
> >>> page (and add permissions) on the semantic-mediawiki.org
> <http://semantic-mediawiki.org>
> > >> <http://semantic-mediawiki.org> to put the info on the separate
> >>> extensions, comparisons - to be used later as the basis for the
> discussion.
> >>
> >> Done (at least a stub):
> >>
> > > http://semantic-mediawiki.org/wiki/SPARQL_and_RDF_stores_for_SMW
> >
> > Great! Had interesting read on
> >
>
> http://semantic-mediawiki.org/wiki/SPARQL_and_RDF_stores_for_SMW#Realisation
> >
> > Especially this section drew my attention:
> >
>
> http://semantic-mediawiki.org/wiki/SPARQL_and_RDF_stores_for_SMW#Modifying_the_SMW_store_API_and_implementations_to_use_RDF_stores
> >
> > ... so let me add some inline comments (This might be aspects you
> were
> > discussing/regarding already, but just to make sure):
> >
> > Wikipage wrote:
> >> ... needs to be extended with a function that takes SPARQL
> queries and that returns SMW query result objects
> >
> > For this kind of processing SPARQL/RDF etc with PHP, I'd like to
> > highlight the huge benefit of keeping ARC2 in the picture ... it has
> > really been an amazing productivity igniter, not so much for its RDF
> > store and SPARQL Endpoint as for its super-convenient data structures
> > and methods for processing SPARQL, RDF (and its variants). I cannot
> > imagine having succeeded with RDFIO in time without all that and
> there
> > also seems to be quite some converge on ARC2 as the library-of-choice
> > for other PHP based projects as well (The upcoming Drupal 7,
> which has
> > RDF export turned on by default, etc.)
>
> The core of SMW should not be dependent on ARC2, though. The idea is to
> completely delegate SPARQL processing to the external store, and to keep
> SPARQL queries opaque to SMW. The only new SPARQL syntax processing
> required in SMW would be the processing of SPARQL query result
> documents. They are probably not so hard to parse, but one could also
> consider copying code from ARC2 to get this done. AFAIK existing
> extensions that implement RDF store bindings in this way did not require
> much extra RDF/SPARQL handling code for this approach.
>
> >
> > Though maybe that is what was thought of, with the line further
> below:
> >> Direct bindings to ARC2 (via PHP)
>
> I would appreciate to have support for using local ARC2 stores directly
> through PHP, without running it as a web service. This would also allow
> some of the RDFIO code to move to SMW Core (the SMW-SPARQL-Update
> functionality via SMWWriter would remain an extension, but could
> possibly be integrated with SMWWriter).
>
> >
> > Anyway, so next thing:
> >
> >> Generic SPARQL/SPARUL SMW store implementation that can connect
> to different RDF stores supporting these standards
> >
> > Noting though that there are currently more than one standard for
> > updating. ARC2 currently uses SPARQL+ [1], while waiting for
> > SPARQ:/Update to stabilize, and standards seem to be a bit of a
> moving
> > target still, so it'd probably be good to make things as generic as
> > possible, in order to support multiple/changing standards.
>
> Yes, and it might be necessary to do some changes to the update language
> before the recommendation is completed. In the worst case, this would
> reduce our "generic" RDF store support to one or two systems that
> support our preliminary version of the SPARQL update language. But as
> soon as SPARQL 1.1 is out, these intermediate restrictions will vanish
> (and the main architecture of SMW's SPARQL support would not be affected
> by this).
>
> >
> > In general, all these envisioned strategies seem to require
> ability to
> > run more than one store. So, is that possible today (There is the
> > $smwgDefaultStore config setting, but that only takes one store
> AFAIK, etc)?
>
> I do not plan to use multiple SMWStore objects at the same time now. The
> RDF store bindings will work like the current implementations: as
> write-through extensions of an SQL-based store (the SQL binding will be
> simpler since the query part is fully delegated to the RDF store, but
> copies of annotations will still be kept locally).
>
> Regards,
>
> Markus
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Semediawiki-devel mailing list
> Semediawiki-devel@lists.sourceforge.net
> <mailto:Semediawiki-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>
>
>
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
