Members present: westei, tkurz, sschaffert, jfrank, Wikier ---------------- Meeting summary: ----------------
1. Preface 2. triplestore ?. http://www.openrdf.org/doc/sesame2/2.7.0-beta1/users/ch08.html (sschaffert, 2) 3. linked data client library 4. ldp ?. http://docs.api.talis.com/getting-started/changesets (sschaffert, 4) ?. http://conferences.idealliance.org/extreme/html/2005/Schaffert01/EML2005Schaffert01.html (sschaffert, 4) 5. other dev topics 6. aob -------- Actions: -------- - all of us, check the compatibility of all modules with the new triple store (Wikier, 09:15:13) - Wikier proposes Talis Changesets for updates in the LDP working group (sschaffert, 09:49:18) - request the wiki to infra (Wikier, 09:50:54) IRC log follows: # 1. Preface # 09:04:45 [Wikier]: ok, let's start 09:04:51 [sschaffert]: ok, my topics: 09:04:53 [Wikier]: what topics do we have for today? 09:04:58 [sschaffert]: - triple store migration 09:05:06 [sschaffert]: - linked data client library 09:05:21 [sschaffert]: (no more topics from me) 09:05:51 [Wikier]: for me mainly ldp-related stuff, but some minor dev things 09:06:00 [Wikier]: anyone else? 09:06:36 [tkurz]: nothing new from my side. will start to refactor webservices today. 09:06:46 [jfrank]: no topics from my side 09:07:37 [Wikier]: sschaffert: you can start 09:07:44 [sschaffert]: ok # 2. triplestore # 09:08:21 [sschaffert]: so the main message here is: I have merged back all my triplestore changes to the main branch in Mercurial 09:08:29 [sschaffert]: so you can all work on updating the respective modules 09:09:06 [sschaffert]: I have done a quick test for lmf-core and it seems to work for basic scenarios (starting, changing database, importing data, SPARQL) 09:09:13 [sschaffert]: but nothing more sophisticated 09:09:21 [sschaffert]: and this is definately a breaking change 09:09:36 [sschaffert]: so please update the components you are working on 09:09:43 [Wikier]: I'm compiling it right now ;-) 09:09:51 [tkurz]: me too ;) 09:09:51 [sschaffert]: I have for the moment disabled all modules that are currently not working 09:10:13 [Wikier]: ok 09:10:22 [sschaffert]: when you compile, do so with -DskipTests=true, because I am not sure if the old tests are really applicable anymore 09:10:36 [sschaffert]: these also need to be updated 09:10:51 [Wikier]: what about the common -Dmaven.test.skip=true 09:10:58 [sschaffert]: MARMOTTA-28 09:11:07 [sschaffert]: Wikier: I think this has a slightly different semantics 09:11:07 [Wikier]: ? 09:11:28 [Wikier]: sschaffert: yes, but I always confuse both 09:11:28 [sschaffert]: MARMOTTA-28 is the issue reminding us to update the tests 09:11:44 [sschaffert]: Wikier: they have effects in different phases 09:11:51 [Wikier]: yes 09:11:58 [sschaffert]: -DskipTests=true skips all tests 09:11:58 [Wikier]: anyway, not compiling for me: 09:11:58 [Wikier]: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.0:compile (default-compile) on project lmf-core: Compilation failure 09:11:58 [Wikier]: [ERROR] /home/sergio/projects/lmf/lmf/lmf-core/src/main/java/kiwi/core/services/triplestore/SesameServiceImpl.java:[127,17] cannot find symbol 09:11:58 [Wikier]: [ERROR] symbol : constructor KiWiStore(java.lang.String,java.lang.String,java.lang.String,java.lang.String,org.apache.marmotta.kiwi.persistence.KiWiDialect,org.openrdf.model.URI) 09:11:59 [Wikier]: [ERROR] location: class org.apache.marmotta.kiwi.sail.KiWiStore 09:12:30 [sschaffert]: while -Dmaven.test.skip=true only skips unit tests but not integration tests (I think) 09:12:31 [tkurz]: just tried a mvn clean install 09:12:36 [tkurz]: seems to work 09:13:13 [Wikier]: so I'll check why it fails for me 09:13:21 [sschaffert]: yes, please 09:13:21 [Wikier]: great work, sschaffert 09:13:36 [sschaffert]: we'll see 09:13:44 [sschaffert]: at least I have the impression it is much faster :) 09:14:06 [sschaffert]: but let's compare once all components are functional again 09:14:21 [sschaffert]: @jfrank: please check particularly the semantic search component 09:14:44 [jfrank]: i'll start asap. 09:14:45 [sschaffert]: the event mechanism for signalling transaction commits has changed a bit 09:15:13 [sschaffert]: while the TransactionData is still called TransactionData in the event, it is now a different class 09:15:13 [Wikier]: #action all of us, check the compatibility of all modules with the new triple store 09:15:58 [sschaffert]: ok, that's it mostly for the triple store; I will spend the next days improving and making compatible many of the modules, but would be good if you could all help 09:16:06 [sschaffert]: the basic workflow for accessing the triple store should now be 09:16:13 [sschaffert]: - inject the SesameService 09:16:22 [sschaffert]: - get a connection from the service 09:16:29 [sschaffert]: - call connection.begin() to start a transaction 09:16:39 [sschaffert]: - carry out your work 09:16:53 [sschaffert]: - call connection.commit() (or connection.rollback()) to finish the transaction 09:17:22 [sschaffert]: - call connection.close() to release all resources occupied by the connection (especially the JDBC connection in case of the KiWi triplestore) 09:17:51 [sschaffert]: the best pattern without Java 7 is a double try-catch-finally 09:17:58 [sschaffert]: e.g. 09:18:06 [sschaffert]: try { 09:18:22 [sschaffert]: RepositoryConnection con = sesameService.getConnection(); 09:18:29 [sschaffert]: try { 09:18:29 [sschaffert]: ... do work ... 09:18:37 [sschaffert]: con.commit(); 09:18:44 [sschaffert]: } finally { 09:18:52 [sschaffert]: con.close(); 09:18:52 [sschaffert]: } 09:18:59 [sschaffert]: } catch(RepositoryException ex) { 09:19:07 [sschaffert]: log.error(...); 09:19:07 [sschaffert]: } 09:19:22 [Wikier]: maybe something to put in the wiki 09:19:39 [sschaffert]: in the future this pattern can be simplified using Java7 try-with-resource 09:19:43 [Wikier]: we should eb careful to provide proper documenation of all this new stuff 09:19:58 [sschaffert]: this is actually plain Sesame :) 09:20:37 [sschaffert]: #link http://www.openrdf.org/doc/sesame2/2.7.0-beta1/users/ch08.html 09:20:54 [sschaffert]: section 8.2.2 09:21:21 [Wikier]: so link it somewhere ;-) 09:21:28 [sschaffert]: so that's it for the triple store 09:21:38 [Wikier]: yes # 3. linked data client library # 09:22:01 [sschaffert]: so this is my work for today and maybe even tomorrow 09:22:15 [sschaffert]: I'd like to move out the linked data client library so it can be used independently 09:22:29 [sschaffert]: as I said yesterday 09:22:43 [sschaffert]: but it proves to be a bit more work than I expected to do it properly 09:23:06 [sschaffert]: in the end, you will simply be able to say 09:23:13 [sschaffert]: LDClient ldclient = new LDClient(); 09:23:21 [sschaffert]: ldclient.retrieveResource(URI ...) 09:23:36 [sschaffert]: and you get back a Sesame in-memory Repository for now 09:23:54 [sschaffert]: there are several configuration options 09:24:00 [sschaffert]: most importantly endpoints 09:24:29 [sschaffert]: an endpoint allows to specify a configuration for a certain URL pattern, i.e. default expiry time and especially which "provider" to use 09:24:52 [sschaffert]: a fallback endpoint will be the RDF Linked Data provider that works with any Linked Data Server 09:24:53 [westei]: so that you can use a SPARQL server to retrieve tripples instead of the CoolURI? 09:24:59 [sschaffert]: yes 09:25:13 [sschaffert]: or even specialised providers 09:25:28 [sschaffert]: there is even now a provider for YouTube and a provider for Vimeo 09:26:06 [sschaffert]: if you give the URI of a video, it will use the respective APIs and convert the data to triples using the "Ontology for Media Resources" 09:26:22 [sschaffert]: this can all be a bit tricky because the data URI is often not the object URI 09:26:28 [sschaffert]: but you will see 09:26:51 [sschaffert]: the important message here is that there will be the possibility to have special configurations for special URLs 09:27:08 [sschaffert]: and the configuration includes the selection of a different data provider (parser)) 09:27:28 [Wikier]: potentially extended by custom use cases 09:27:28 [Wikier]: right 09:27:36 [sschaffert]: there will be reasonable defaults as well, so that a user does not need to explicitly configure always 09:27:45 [sschaffert]: new LDClient() should be enough for standard cases 09:28:08 [sschaffert]: and that's it for now regarding the LDClient :) 09:28:21 [westei]: In OSGI you would register LDClient instances as services and allow users to retrieve the right one based on Filter 09:28:46 [sschaffert]: westei: I am talking plain java 09:28:58 [sschaffert]: you can have as many LDClient instances as you like 09:29:01 [sschaffert]: so it works in OSGi :) 09:29:54 [westei]: Can configuration be combined (like Properties Files in Java)? 09:30:38 [sschaffert]: it is a ClientConfiguration object that you compose yourself and pass as argument to LDClient constructors 09:31:21 [sschaffert]: in OSGi you would have a separate activator that registers the services based on different configurations 09:31:36 [sschaffert]: if you really want to have different LDClients :) 09:32:06 [sschaffert]: the basic pattern is actually quite similar to how we implemented LDPath 09:32:58 [sschaffert]: ok, more questions? Maybe I can also tell you more tomorrow or on Thursday when it is finished 09:33:21 [westei]: ok 09:33:22 [sschaffert]: otherwise let's move to the next topic 09:34:21 [Wikier]: ok # 4. ldp # 09:34:53 [Wikier]: still trying to understand some ideas behind LDP-C 09:35:13 [Wikier]: at the same time I started a draft implementation at mercurial 09:35:43 [sschaffert]: LDP-C is for containers, or not? 09:35:51 [Wikier]: just the http-side, actual implementation was awaiting the new triple store api that sschaffert commented before 09:36:00 [sschaffert]: how do we map containers to the triple store, as named graphs? 09:36:09 [Wikier]: LDP-C is Linked Data Platform Containers, right 09:36:29 [Wikier]: sschaffert: that's something I'm still thinking 09:36:31 [tkurz]: in my opinion graphs and ldp-c are not the same 09:36:43 [Wikier]: and probably I agree with tkurz 09:36:51 [jfrank]: @tkurz: +1 09:37:06 [tkurz]: containers are just extended resources 09:37:13 [sschaffert]: so what is a container then? and what speaks against creating a separate context for each container? 09:37:30 [Wikier]: but at the same time both Graphs and LDP-C are both some kind of containers 09:37:43 [tkurz]: a container is a resource, a graph is a set of triples 09:37:51 [sschaffert]: a graph is also a resource 09:37:53 [Wikier]: exactly 09:38:21 [sschaffert]: and if you look at how SPARQL does it, it is actually very similar to containers 09:38:28 [Wikier]: I'll think a bit more about how to design proper backend support for it, and I'll be back with the conclusions in the following days 09:38:36 [sschaffert]: the graph can be both a resource and a container in SPARQL 09:38:43 [Wikier]: also because there are many current open issues at the WG 09:39:06 [sschaffert]: yes :) 09:39:28 [Wikier]: for instance, I'd like to clarify the relation between LDP and SPARQL 1.1 Graph Store HTTP Protocol 09:39:45 [Wikier]: which is not so clear fmpov 09:39:58 [tkurz]: like many other things 09:39:58 [Wikier]: xD 09:40:00 [Wikier]: sure 09:40:13 [tkurz]: the scond big issue is the update protocol 09:40:31 [Wikier]: you mean ldp or sparql? 09:40:43 [tkurz]: ldp. should we start using changesets? 09:40:58 [tkurz]: and HTTP PATCH 09:41:13 [tkurz]: I think this would be a clean solution 09:41:21 [jfrank]: I started with some test for PATCH... 09:41:45 [sschaffert]: but the LDP WG is not yet clear on the syntax for changesets, or is it? 09:41:57 [tkurz]: the good thing on changeset is, that it is specified and well known in the community 09:42:20 [tkurz]: no 09:42:28 [sschaffert]: yes, so this would probably be a good approach to start with 09:42:28 [jfrank]: no - for a start, i invented a simple format... 09:42:34 [Wikier]: no, it doesn't 09:42:44 [sschaffert]: don't invent something new, the Talis Changesets cover everything 09:42:49 [Wikier]: we should start to experiment with patch, right 09:42:59 [sschaffert]: #link http://docs.api.talis.com/getting-started/changesets 09:43:27 [tkurz]: +1 09:43:30 [Wikier]: +1 09:43:42 [jfrank]: no problem, it's just some other content type... 09:43:42 [sschaffert]: and actually they are easy to create using a triplestore 09:44:04 [Wikier]: how difficult would be to provide support for changeset directly at the versioning component? 09:44:12 [sschaffert]: very easy 09:44:49 [sschaffert]: we maybe cannot provide all the information, though ("reason") 09:45:04 [Wikier]: ok 09:45:27 [sschaffert]: but this is one of the next tasks for me, actually 09:45:33 [Wikier]: but that's just meta information for humans 09:45:43 [sschaffert]: MARMOTTA-22 09:46:17 [sschaffert]: yes 09:46:24 [sschaffert]: but I will do this for the versioning service 09:46:32 [sschaffert]: the issue is more the LDP update 09:46:32 [Wikier]: cool 09:47:28 [Wikier]: I've just added the reference to MARMOTTA-22 09:47:36 [sschaffert]: me too :) 09:47:43 [Wikier]: ummm 09:47:51 [Wikier]: concurrence... xD 09:47:58 [Wikier]: np, I deleted mine 09:47:58 [Wikier]: ok 09:48:12 [sschaffert]: what I can also offer is a small component that allows translating back and forth from Talis Changeset to Marmotta Version 09:48:29 [sschaffert]: maybe it is useful also for updating 09:48:34 [Wikier]: with all these pieces, I'll provide a proposal form ldp updates 09:48:41 [Wikier]: s/form/for 09:48:48 [sschaffert]: yes, good idea 09:48:48 [sschaffert]: +1 09:49:11 [tkurz]: +1 09:49:12 [jfrank]: +1 09:49:18 [sschaffert]: #action Wikier proposes Talis Changesets for updates in the LDP working group 09:49:54 [sschaffert]: for me, the changesets are a very good approach 09:50:04 [Wikier]: yes, it is 09:50:10 [sschaffert]: because they follow the typical "edit script" approach that is also used e.g. by Unix diff 09:50:25 [Wikier]: for this, it'd be nice to have the wiki working 09:50:34 [sschaffert]: I once supervised a master thesis on the topic of XML diffs and there the student investigated many such issues 09:50:54 [Wikier]: #action request the wiki to infra 09:51:32 [Wikier]: sschaffert: something useful in many scenarios, indeed 09:51:34 [Wikier]: ok 09:51:39 [sschaffert]: #link http://conferences.idealliance.org/extreme/html/2005/Schaffert01/EML2005Schaffert01.html 09:51:47 [Wikier]: I'll continue working on this 09:51:54 [Wikier]: next toppics? 09:52:56 [sschaffert]: no more topics from me, let's go programming :) # 5. other dev topics # 09:53:31 [Wikier]: I tried to completely remove the old "knowledge spaces" 09:53:41 [Wikier]: so now all name graphs will be /context/... 09:53:54 [Wikier]: please, check everything is working fine 09:53:59 [Wikier]: it should 09:54:14 [Wikier]: but I removed many hardcoded references 09:54:31 [sschaffert]: Wikier: compile error 09:54:42 [Wikier]: shit! 09:54:42 [sschaffert]: was introduced probably by merging your ContextService changes 09:54:49 [Wikier]: ups, [off] xD 09:54:57 [Wikier]: let me check 09:54:57 [sschaffert]: simple to solve but I prefer someone of you doing it because I did not create a new branch :) 09:55:06 [sschaffert]: in SesameServiceImpl 09:55:12 [tkurz]: okay I can do this 09:55:19 [sschaffert]: change 09:55:19 [sschaffert]: store = new KiWiStore("lmf", jdbcUrl, dbUser, dbPass, dialect, contextService.getDefaultContext()); 09:55:20 [sschaffert]: to 09:55:28 [sschaffert]: store = new KiWiStore("lmf", jdbcUrl, dbUser, dbPass, dialect, contextService.getDefaultContext()).stringValue(); 09:55:43 [sschaffert]: (with correct parentheses ...) 09:55:47 [Wikier]: that's my compilation error that I reported at the beginning of the meeting 09:55:48 [sschaffert]: yes 09:56:02 [Wikier]: ok 09:56:09 [Wikier]: please, push the fix 09:56:17 [jfrank]: are we now coding via irc? 09:56:18 [Wikier]: xD 09:56:32 [Wikier]: nice minutes... 09:56:39 [Wikier]: anyway, easy to fix, just merge issue 09:56:40 [Wikier]: ok # 6. aob # 09:56:49 [Wikier]: aob? 09:56:54 [sschaffert]: tkurz: can you commit this? 09:57:25 [tkurz]: yes. Just testing if it compiles now ;) 09:57:37 [Wikier]: ok 09:57:39 [jfrank]: ACTION has no other topics 09:57:46 [Wikier]: let's finish the meeting 09:57:52 [Wikier]: 1h xD 09:57:52 [jfrank]: +1
