Summary of IRC meeting in #apachemarmotta, Mon Jan 28 09:02:25 2013

[ASF IRC Services <as...@wilderness.apache.org>]

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