Members present: julunggul, westei, tkurz, sschaffert, jfrank, Wikier ---------------- Meeting summary: ----------------
1. Preface 2. ldcache 3. RDF 1.1 4. cache 5. RDF1.1 e. http://www.w3.org/TR/2013/WD-rdf11-concepts-20130115/ (sschaffert, 5) 6. branding >. Wikier creates a Jira issue based on the requirements collected on the mailing list (sschaffert, 6) >. sschaffert will together with the designer attach the collection of images to this issue (sschaffert, 6) 7. aob -------- Actions: -------- - Wikier creates a Jira issue based on the requirements collected on the mailing list (sschaffert, 09:27:30) - sschaffert will together with the designer attach the collection of images to this issue (sschaffert, 09:27:54) IRC log follows: # 1. Preface # 09:02:40 [sschaffert]: my topic: ldcache 09:02:40 [Wikier]: let's try to do it in 10 min 09:03:02 [jfrank]: my topic: rdf1.1 09:03:19 [sschaffert]: another topic: logo/branding 09:03:27 [Wikier]: yes 09:03:34 [Wikier]: and that's it, I think 09:03:42 [Wikier]: sschaffert: proceed 09:03:43 [sschaffert]: ok # 2. ldcache # 09:03:58 [sschaffert]: a quick report 09:04:19 [sschaffert]: I started with modularizing the ldcache code from the old lmf-ldcache module 09:04:21 [sschaffert]: this part is mostly done 09:04:34 [sschaffert]: but now I still need to implement different backends 09:04:52 [sschaffert]: because I want the linked data caching to be useful even outside the Marmotta context 09:05:12 [Wikier]: sure 09:05:12 [sschaffert]: I am thinking therefore about different backends: 09:05:27 [sschaffert]: - based on the KiWi triplestore, allows storing cache entries in the database 09:05:52 [sschaffert]: - based on EHCache and Sesame, allows storing cache entries in an EHCache cache (persistent, in-memory, or distributed) 09:06:07 [sschaffert]: both I'd like to finish today 09:06:35 [Wikier]: ok 09:06:36 [sschaffert]: just as a short explanation: linked data caching has two persistent components 09:06:55 [Wikier]: what I reported 09:06:55 [Wikier]: MARMOTTA-38 09:06:55 [sschaffert]: - the cache entry, which stores metadata about the caching process (e.g. expiry time for a resource) 09:07:02 [Wikier]: would be for the future 09:07:10 [sschaffert]: - the triple cache, which stores the actual triples 09:07:25 [sschaffert]: both aspects can be different depending on backends 09:07:40 [sschaffert]: the approach for the LMF will now be: 09:07:47 [sschaffert]: - cache entries via JDBC (or EHCache) 09:08:10 [sschaffert]: - triples in the common triple store identified with a special context (as described in MARMOTTA-38) 09:08:40 [sschaffert]: but the backend is purely LMF specific and easy to change in case we would like to use a different context 09:09:25 [sschaffert]: I will use a Sesame ContextAwareRepositoryConnection to wrap the triple store with a defined context, so all accesses by the caching component go through this context 09:09:40 [sschaffert]: and that's it 09:09:40 [Wikier]: cool 09:09:40 [sschaffert]: for now 09:09:42 [sschaffert]: more tomorrow 09:09:47 [Wikier]: :-) # 3. RDF 1.1 # 09:10:02 [julunggul]: is the context propagated via transaction ? (like in JPA) 09:10:19 [Wikier]: ups, julunggul has some questions 09:10:25 [sschaffert]: we are talking about a different context here, context as in "named graph" # 4. cache # 09:10:32 [sschaffert]: not as in JPA 09:11:17 [sschaffert]: there is no relation to transactions 09:11:17 [Wikier]: julunggul: context are named graphs in lmf/marmotta 09:11:32 [Wikier]: we deprecated the old "knowledge spaces" term 09:11:32 [sschaffert]: well, actually in Sesame, we just took over the name from there 09:11:47 [Wikier]: and then aligned with sesame naming 09:12:17 [sschaffert]: in official W3C documents it is called "named graph" (e.g. in SPARQL) 09:12:32 [Wikier]: yes 09:12:32 [sschaffert]: but there are different ways of implementing it 09:12:48 [sschaffert]: - Sesame uses quadruples with a fourth resource called "context" 09:12:54 [julunggul]: ok, I got it now 09:13:02 [sschaffert]: - Jena uses distinct graphs as containers 09:13:19 [sschaffert]: mathematically equivalent, but implementation-wise different 09:13:32 [sschaffert]: ok # 5. RDF1.1 # 09:13:41 [sschaffert]: jfrank? 09:13:47 [Wikier]: jena uses "dataset" for it 09:13:47 [Wikier]: rdf 1.1 09:13:50 [Wikier]: nice topic 09:14:19 [sschaffert]: #link http://www.w3.org/TR/2013/WD-rdf11-concepts-20130115/ 09:14:32 [jfrank]: just realized over the weekend that in rdf1.1 literals are slightly different 09:14:47 [jfrank]: (and some other things) 09:15:10 [jfrank]: no more untyped literals -> xsd:string as default 09:15:10 [Wikier]: the wg is trying to address some old issues, yes 09:15:10 [sschaffert]: yes, finally they took over what we always had: language literals with datatype!" 09:15:17 [Wikier]: such this 09:15:40 [jfrank]: not really... there is only ONE datatype for language literals: rdf:langString 09:15:55 [sschaffert]: this is what we also had :) 09:16:02 [sschaffert]: well, we used xsd:string 09:16:32 [sschaffert]: ok, this is again a bit crazy 09:16:40 [sschaffert]: why only string? 09:16:55 [sschaffert]: but not our issue to solve 09:16:56 [jfrank]: true 09:16:58 [sschaffert]: what is your question, then? 09:17:47 [jfrank]: no real question: FYI: i'll close MARMOTTA-34 and open an new issue for RDF1.1 Literals. 09:17:55 [sschaffert]: ok 09:17:56 [Wikier]: +1 09:18:10 [sschaffert]: my suggestion is: implement the new langString type for literals 09:18:17 [jfrank]: sure 09:18:26 [sschaffert]: it does not hurt backwards compatibility anyways 09:18:32 [jfrank]: should i also fix "wrong" types? 09:18:40 [sschaffert]: if we have "wrong" types ... 09:18:47 [jfrank]: eg. xsd:int with languag-tag 09:19:02 [sschaffert]: probably, since they don't allow it 09:19:09 [jfrank]: or ist this "not our problem" 09:19:10 [tkurz]: I think it is not the work of a triplestore to correct wrong data 09:19:25 [sschaffert]: true 09:19:25 [sschaffert]: and actually 09:19:40 [sschaffert]: it is no longer possible to create an int with a language tag 09:19:42 [sschaffert]: through the API 09:19:55 [sschaffert]: it was possible in plain KIWI 09:20:02 [sschaffert]: but Sesame does not allow it 09:20:47 [sschaffert]: so don't fix wrong types 09:20:49 [westei]: cd .. 09:20:56 [sschaffert]: ls :) 09:21:32 [jfrank]: no fixing. ok 09:21:40 [sschaffert]: ok, more to discuss here? 09:21:42 [Wikier]: #task jfrank should clarify how rdf 1.1 lang literal would be implemented # 6. branding # 09:21:55 [Wikier]: shortly 09:21:56 [sschaffert]: ok, short report 09:22:02 [sschaffert]: logo: 09:22:04 [Wikier]: - awaiting for infra to publish the website 09:22:17 [Wikier]: - we can proceed with the logo 09:22:25 [sschaffert]: Daniela needs clear specifications for the logo sizes and formats 09:22:34 [sschaffert]: clear meaning more-or-less exact pixel sizes 09:22:39 [Wikier]: as soon as it is added by a committer to jira or send it to the mailing list 09:22:39 [Wikier]: that's enough 09:22:49 [sschaffert]: yes, once we know the formats 09:23:04 [sschaffert]: I will send together with Daniela an attachment to Jira with all the logos 09:23:17 [Wikier]: well, actually that's derived work 09:23:25 [sschaffert]: not completely 09:23:26 [Wikier]: so yes, I called for requirements at dev@ 09:23:32 [Wikier]: we got some 09:23:33 [Wikier]: but not actul sizes 09:23:40 [Wikier]: s/actul/actual 09:23:55 [sschaffert]: so we need to define them based on the requirements and typical sizes found on the web 09:24:10 [sschaffert]: e.g. favicon, banner, button, ... 09:24:32 [sschaffert]: of course we can always get more later, but now we should define a reasonable set 09:24:40 [Wikier]: monochrome would important for merchandising, for instance 09:24:47 [sschaffert]: maybe we can document this in a Jira issue 09:25:17 [Wikier]: yes 09:25:25 [Wikier]: I'll collect all requirements submitted to dev@ 09:25:25 [sschaffert]: ok 09:25:26 [tkurz]: I think if we have a vector graphic, size doesn't matter anymore. 09:25:32 [Wikier]: and then we can add the sizes 09:25:40 [sschaffert]: tkurz: not true :) 09:25:47 [Wikier]: tkurz: exactly, svg + psd/xcf 09:25:47 [sschaffert]: according to Daniela size still matters 09:25:56 [Wikier]: but with some limitations 09:26:09 [sschaffert]: for smaller sizes, you need to emphasise the basic features 09:26:09 [Wikier]: probably she has in mind some changes for really small resolutions 09:26:25 [tkurz]: that's true for tiny ;) 09:26:39 [sschaffert]: probably even for banner or button 09:26:46 [sschaffert]: but not my expertise 09:26:47 [jfrank]: and also for huge ;-) 09:26:53 [sschaffert]: I let her decide this :) 09:27:00 [tkurz]: okay. maybe Daniela as an expert should decide this 09:27:09 [sschaffert]: so 09:27:30 [sschaffert]: #action Wikier creates a Jira issue based on the requirements collected on the mailing list 09:27:45 [Wikier]: actually append to the current one 09:27:45 [Wikier]: but ok 09:27:54 [sschaffert]: #action sschaffert will together with the designer attach the collection of images to this issue 09:27:59 [sschaffert]: ok 09:28:14 [sschaffert]: next topic? 09:28:46 [sschaffert]: any other business? 09:29:07 [Wikier]: nothing from my side 09:29:09 [sschaffert]: who will be working on what? # 7. aob # 09:29:40 [Wikier]: ongoing tasks? 09:29:52 [sschaffert]: maybe we can quickly summarize ongoing tasks per person 09:29:52 [sschaffert]: one-liner 09:30:07 [sschaffert]: what we are working on right now until tomorrow 09:30:16 [Wikier]: for my side: some old bugs to fixe, plus ldp draft implementation 09:30:22 [tkurz]: I will refactor sparql service, sparql ui's + skosjs 09:30:37 [sschaffert]: I'll work on ldcache this afternoon and hopefully manage to replace the old lmf-ldcache module by tomorrow 09:31:09 [jfrank]: ACTION RDF1.1 literals and search/indexing... 09:31:09 [sschaffert]: jfrank? 09:31:16 [sschaffert]: ok :) 09:31:24 [Wikier]: we should try with new features not later than wednesday 09:31:45 [Wikier]: then quality assurance and so on 09:31:45 [sschaffert]: I would not add any new features, just fix old ones 09:32:00 [sschaffert]: on my task list left are: versioning, reasoning, and maybe SPARQL backend 09:32:07 [Wikier]: well, I consider major refactorizations new features ;-) 09:32:17 [sschaffert]: yes, me too 09:32:52 [sschaffert]: the only exception that is open is the reasoning 09:32:52 [Wikier]: ok, we have a lot to do :-) 09:33:00 [Wikier]: 32 mins 09:33:00 [sschaffert]: the rest I will finish until Wednesday 09:33:01 [sschaffert]: yes 09:33:02 [Wikier]: this is a record 09:33:08 [Wikier]: but far away from 10 xD 09:33:22 [sschaffert]: in 10 we can only do the summary of tasks 09:33:24 [sschaffert]: maybe we should try this next time 09:33:30 [Wikier]: thx everybody 09:33:38 [Wikier]: sschaffert: jfrank was suggesting to collect in advance 09:33:45 [Wikier]: maybe it could work 09:33:46 [Wikier]: next time 09:33:52 [sschaffert]: ok
