Log of the #fcrepo channel on chat.freenode.net

Using timezone: Eastern Standard Time
* escowles leaves02:38
* escowles joins02:39
* escowles leaves03:42
* escowles joins
* dwilcox joins07:43
* acoburn joins08:54
* jrgriffiniii joins08:56
* whikloj joins08:57
* escowles leaves08:58
<ruebot>awoods: here is a weird one -- https://gist.github.com/ruebot/ac39d8aa5d1cb84c59e2 -- has me stuck on fcrepo-transform, which means i can't move on to webapp-plus.09:03
* github-ff joins09:17
[fcrepo-module-auth-rbacl] escowles pushed 1 new commit to master: https://git.io/vzazM
fcrepo-module-auth-rbacl/master d328d0f Esmé Cowles: Merge branch 'rc-4.5.0'
* github-ff leaves
* escowles joins
<ruebot>escowles: i'm stuck on a weird error with transform. but talked it out with whikloj in skype.09:18
escowles: so we need to decide whether to wait for awoods (who iirc is away today), or fix the pom.xml and continue moving forward.09:19
<escowles>ruebot: i'm just getting started (i saw your convo with awoods last night and merged the RC branch into fcrepo-auth-module-rbacl to bump the version numbers on master to 4.5.1-SNAPSHOT)09:20
<ruebot>escowles: ah, cool
escowles: ...and there goes my mental note :-)
<escowles>ruebot: yeah, my mental notes usually come back to me right after the person i was supposed to remind remembers on their own
* osmandin joins09:22
* travis-ci joins09:25
fcrepo4/fcrepo-module-auth-rbacl#46 (master - d328d0f : Esmé Cowles): The build passed.
Change view : https://github.com/fcrepo4/fcrepo-module-auth-rbacl/compare/2a046ebabe71...d328d0fc1240
Build details : https://travis-ci.org/fcrepo4/fcrepo-module-auth-rbacl/builds/104101076
* travis-ci leaves
<awoods>ruebot: fcrepo-transform needs a scm block: https://github.com/fcrepo4-exts/fcrepo-transform/blob/master/pom.xml09:27
ruebot: like: https://github.com/fcrepo4-exts/fcrepo-audit/blob/master/pom.xml#L56-L6309:28
ruebot: I'm out
* github-ff joins09:32
[fcrepo-module-auth-xacml] escowles created release-4.5.0 (+3 new commits): https://git.io/vzaaz
fcrepo-module-auth-xacml/release-4.5.0 44bc180 Esmé Cowles: Revert "Prepare 4.5.0-RC"...
fcrepo-module-auth-xacml/release-4.5.0 69693cb Esmé Cowles: [maven-release-plugin] prepare release fcrepo-module-auth-xacml-4.5.0
fcrepo-module-auth-xacml/release-4.5.0 0d3f376 Esmé Cowles: [maven-release-plugin] prepare for next development iteration
* github-ff leaves
* travis-ci joins09:38
fcrepo4/fcrepo-module-auth-xacml#94 (release-4.5.0 - 0d3f376 : Esmé Cowles): The build has errored.
Change view : https://github.com/fcrepo4/fcrepo-module-auth-xacml/compare/44bc18063ac9^...0d3f3762c370
Build details : https://travis-ci.org/fcrepo4/fcrepo-module-auth-xacml/builds/104104332
* travis-ci leaves
* travis-ci joins09:40
fcrepo4/fcrepo-module-auth-xacml#95 (fcrepo-module-auth-xacml-4.5.0 - 69693cb : Esmé Cowles): The build passed.
Change view : https://github.com/fcrepo4/fcrepo-module-auth-xacml/compare/fcrepo-module-auth-xacml-4.5.0
Build details : https://travis-ci.org/fcrepo4/fcrepo-module-auth-xacml/builds/104104350
* travis-ci leaves
* dhlamb joins09:41
<ruebot>escowles, whikloj: updated pom.xml and new error is here -- https://gist.github.com/ruebot/6b33ba39f7eec4733e94#file-gistfile1-txt
<whikloj>ruebot: looks like you need to define the <jersey.version>2.13</jersey.version> and <spring.version>4.1.1.RELEASE</spring.version> in the fcrepo-transform pom.xml09:43
they were in the fcrepo4/fcrepo4/pom.xml but not in the fcrepo4/fcrepo-parent/pom.xml
<ruebot>whikloj: cool. those would go in <dependencies>?09:46
<whikloj>ruebot: no in <properties>
<whikloj>considering this debacle is probably my fault, if this works we'll call it whikloj==
<ruebot>whikloj: hahaha -- getting this again: [ERROR] fcrepo4/fcrepo4.git/fcrepo-transform is not a valid repository name09:48
* github-ff joins
[fcrepo-module-auth-xacml] escowles pushed 1 new commit to gh-pages: https://git.io/vzawb
fcrepo-module-auth-xacml/gh-pages 959295e Esmé Cowles: Creating site for fcrepo-module-auth-xacml, 4.5.0
* github-ff leaves
<whikloj>ruebot: my zero release knowledge is not giving me the answer. Does it need a rebuild?09:51
<ruebot>whikloj: oh! i'll do a mvn clean install09:52
<whikloj>ruebot++ # Why not, it's like "have you tried turning it off and back on again?"09:53
<ruebot>whikloj: https://gist.github.com/ruebot/6b33ba39f7eec4733e94#file-gistfile1-txt -- another error. glassfish/grizzly is failing09:58
<whikloj>ruebot: I'm gonna pull down the fcrepo-transform release and see if I can build it10:00
<ruebot>whikloj: it built fine on it's own, i ran into all the problems when i got to this step in the release: mvn release:perform -DperformRelease -Dgoals=deploy10:01
* github-ff joins10:02
[fcrepo-module-auth-xacml] escowles pushed 1 new commit to master: https://git.io/vzaKG
fcrepo-module-auth-xacml/master 34db77a Esmé Cowles: Merge branch 'rc-4.5.0'
* github-ff leaves
<acoburn>ruebot: the "not a valid repository" issue is something I've seen before
ruebot: I believe it is b/c the module is missing an SCM section in pom.xml10:03
<ruebot>acoburn: i added that per awoods rec -- https://gist.github.com/ruebot/6b33ba39f7eec4733e94#file-pom-xml
acoburn: that's the current status of the pom.xml after adding awoods & whikloj suggestions10:04
<whikloj>ruebot: So it builds and runs the tests fine with "mvn clean install" but when you goto do the release it fails on the tests?10:06
<ruebot>whikloj: yeah
<acoburn>ruebot: isn't there a mvn prepare-release command (or smth like that)?10:07
<whikloj>ruebot: do you need to push your changes out to the repo before you release? Is it cloning a fresh version to "release"?
<acoburn>ruebot: I think it creates a file that caches the repo location
* travis-ci joins
fcrepo4/fcrepo-module-auth-xacml#96 (master - 34db77a : Esmé Cowles): The build passed.
Change view : https://github.com/fcrepo4/fcrepo-module-auth-xacml/compare/852896d66b9c...34db77ac0555
Build details : https://travis-ci.org/fcrepo4/fcrepo-module-auth-xacml/builds/104110676
* travis-ci leaves
<acoburn>ruebot: so if you've changed the pom.xml after that release-cache file is made, you may still be pulling the old value
ruebot: I'd grep for that file — you can either manually fix it or just start the process over again10:08
* bseeger joins
<acoburn>ruebot: I'm going from memory here, and this particular memory is ~ 6mos old
<whikloj>acoburn/ruebot: going from no knowledge I found this which indicates there is a mvn release:prepare command10:10
old that it is
<escowles>i'm having trouble with fcrepo-module-auth-webac-4.5.0 -- "mvn release:clean" doesn't work with or without reverting the last commit, and a clean build of master doesn't work either10:11
the error it's giving me is: "[FATAL] Non-resolvable parent POM for org.fcrepo:fcrepo-module-auth-webac:[unknown-version]: Could not find artifact org.fcrepo:fcrepo:pom:4.4.1-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 3, column 11 "
<ruebot>acoburn, whikloj: https://gist.github.com/ruebot/060154057d918828d2d4 -- that's the basic steps10:12
escowles: oh, i had to build fcrepo from an earlier commit last night for another component10:13
<escowles>ruebot: do i need to checkout an older repo to get 4.4.1-SNAPSHOT?
<ruebot>escowles: yeah, i cloned fcrepo4, git co 03adc0b85166c2e16c280fd183b2b97252210a7c10:14
escowles: then mvn clean install, then went back and the other component built fine once those jars were in my ~/.m2/repository10:15
<escowles>ruebot: ok, that makes sense -- i've got that commit of fcrepo4 building now
<ruebot>escowles: cool.10:16
<whikloj>ruebot: so what creates the branch fcrepo-4.5.0, according to that gist it's already there (ie. not a git checkout -b)10:20
<ruebot>whikloj: that's the tag, created by mvn release:prepare
* github-ff joins10:21
[fcrepo-module-auth-webac] escowles created release-4.5.0 (+3 new commits): https://git.io/vzaPN
fcrepo-module-auth-webac/release-4.5.0 4de628b Esmé Cowles: Revert "Prepare 4.5.0-RC"...
fcrepo-module-auth-webac/release-4.5.0 ecbeb40 Esmé Cowles: [maven-release-plugin] prepare release fcrepo-module-auth-webac-4.5.0
fcrepo-module-auth-webac/release-4.5.0 4b2e55b Esmé Cowles: [maven-release-plugin] prepare for next development iteration
* github-ff leaves
<whikloj>ruebot: okay so then did you push the pom file changes back to the release branch on origin?10:22
<ruebot>whikloj: git push origin rc-4.5.0:release-4.5.010:24
<whikloj>ruebot: right but did you do that after you solved all those issues and the build was working?
sorry I'm learning the process as we go along here
<ruebot>whikloj: you push there before you do the release preform, and that's when i started having the problems.10:25
whikloj: no worries!
whikloj: so, mvn updates the pom in the process as you can see here: https://github.com/fcrepo4-exts/fcrepo-transform/tree/release-4.5.0
whikloj: then when i'm done (with sonatype), i merge that into master10:26
<whikloj>ruebot: that is not updated with fcrepo-parent, properties or scm block?
<ruebot>whikloj: not now. i haven't pushed that since it hasn't built on my end.10:27
* esm_ joins10:28
The SSWAP website leaves much to be desired.10:29
* esm_ grumbles
* github-ff joins10:31
[fcrepo-module-auth-webac] escowles pushed 1 new commit to gh-pages: https://git.io/vza1x
fcrepo-module-auth-webac/gh-pages a8cf5f7 Esmé Cowles: Creating site for fcrepo-module-auth-webac, 4.5.0
* github-ff leaves
* travis-ci joins10:32
fcrepo4/fcrepo-module-auth-webac#87 (fcrepo-module-auth-webac-4.5.0 - ecbeb40 : Esmé Cowles): The build passed.
Change view : https://github.com/fcrepo4/fcrepo-module-auth-webac/compare/fcrepo-module-auth-webac-4.5.0
Build details : https://travis-ci.org/fcrepo4/fcrepo-module-auth-webac/builds/104115198
* travis-ci leaves
<ruebot>escowles: did you catch how awoods said to do the index.html for ghpages branch yesterday?10:33
<escowles>ruebot: no -- is that the "doc index.html" column?
<ruebot>escowles: yeah
escowles: it's basically opening up, and looking for the pattern, and doing something like this https://github.com/fcrepo4/fcrepo4/commit/4c0daa006fa41845d5b12d9bdbd8488f59821d2f10:34
* travis-ci joins
fcrepo4/fcrepo-module-auth-webac#86 (release-4.5.0 - 4b2e55b : Esmé Cowles): The build has errored.
Change view : https://github.com/fcrepo4/fcrepo-module-auth-webac/compare/4de628ba7275^...4b2e55b5fb68
Build details : https://travis-ci.org/fcrepo4/fcrepo-module-auth-webac/builds/104115163
* travis-ci leaves
<escowles>ruebot: ok -- that commit looks like it's doing the 3 modules i released yesterday and today10:36
ruebot: so can i just mark those as done? or is there something i need to do for each module's gh-pages?10:41
meanwhile, i'll do the ontologies, which is just tagging them
<ruebot>escowles: i'll double check10:45
escowles++ #for doing the ontologies
* github-ff joins10:47
[ontology] escowles tagged ontology-4.5.0 at 4b1646b: https://git.io/vzayo
* github-ff leaves
<ruebot>escowles: those don't have index.html pages, so i think we're cool there.
escowles: ...yep! "Update index.html pages in branch "gh-pages" for releases projects: fcrepo4, and fcrepo-camel-toolbox"
escowles: i'll make those grey.10:48
<escowles>ruebot: excellent
* github-ff joins10:49
[ontology] escowles tagged fcrepo-ontology-4.5.0 at ontology-4.5.0: https://git.io/vzaSf
* github-ff leaves
<escowles>i wonder if fcrepo4/ontology should actually be fcrepo4/fcrepo-ontology to match the naming of the other projects10:51
* dwilcox leaves
<escowles>ruebot: i made an updated version of your textfile with variables and a few notes: https://gist.github.com/escowles/e462e663b3a5d807d5ad10:54
* dhlamb leaves10:57
* dhlamb joins
<ruebot>escowles: want to just add to this? https://wiki.duraspace.org/display/FF/Fedora+Release+Process
<escowles>ruebot: i was dithering about how to add it -- i found the existing release process page very busy and hard to follow, so the stripped-down version seems much more usable to me10:58
<ruebot>escowles: totally agree!
* acoburn leaves
<escowles>ruebot: so, maybe i'll add the stripped-down version at the top of the page, and then see how much of the old content needs to stay around as "notes" or something10:59
* mohamedar joins11:00
<ruebot>escowles: that sounds good
* jrgriffiniii leaves
<ruebot>escowles: ...and for transform. should we just hold off until awoods is back around?11:02
<escowles>ruebot: yeah, that's probably for the best11:03
<ruebot>escowles: ...then i can finish the remaining three, transform, webapp-plus, and vagrant.
* dwilcox joins11:06
* mohamedar leaves11:10
* bseeger leaves11:15
<escowles>ruebot: https://wiki.duraspace.org/display/FF/Fedora+Release+Process#FedoraReleaseProcess-ReleaseDay(Brief)11:17
i'm going to go get an early lunch and i'll tackle cleaning up the old release instructions after11:18
<ruebot>escowles: sounds good. reviewing what you have up now.11:19
* mohamedar joins11:21
* jrgriffiniii joins11:41
* dhlamb leaves11:44
* dhlamb joins11:49
* bseeger joins
* mohamedar leaves11:51
* esm_ leaves11:56
* esm_ joins12:04
* esm__ joins12:09
* acoburn joins
* esm_ leaves12:10
<esm__>^^^ existential issues12:12
* bseeger leaves12:28
* dhlamb_ joins12:30
* dhlamb leaves12:32
* peichman joins13:08
* peichman leaves13:17
<jrgriffiniii>Hello everyone. We've been exploring a Docker-based approach to deploying fcrepo4 at our institution. Has there been any successor to what has been released by Yinlin Chen at https://github.com/yinlinchen/fcrepo4-docker?13:32
* bseeger joins13:33
* jgpawletko joins13:43
* acoburn leaves13:45
* ajs6f joins13:47
esm__: ping13:51
<esm__>ajs6f: pong13:52
(sorry heads-down prepping for the api-x call)13:53
<ajs6f>esm__: yeah, exactly— I may be in and out on the call (SNOW CRAZY SNOW HAPPENING) so if I drop, acoburn agreed to talk SSWAP
esm__: just so you know
esm__: But generally, what you just said on the wiki sounds good to me13:54
* ddavis joins13:59
* ajs6f is on the call14:00
<bseeger>*is on the call, too*
* acoburn joins14:02
* rdfloyd joins
* esm__ leaves14:16
* mohamedar joins14:27
<bseeger>is it just me, or is the connection to @acoburn very quiet?14:31
<ajs6f>it is a bit quiet, but then acoburn has a very quiet voice.
<acoburn>I'll speak up then!14:32
<bseeger>:) thanks @acoburn - your quieter then usual.
* bseeger leaves14:56
* bseeger joins
<ajs6f>acoburn is quiet like a ninja15:04
<bseeger>*wants some snow, please*15:07
* esm_ joins15:10
* esm_ still processing the api-x call15:11
<ajs6f>esm__: See, if we had only used machine-actionable vocabularies on that call, you could hand off all that troublesome reasoning to a computer!
Yeah I'm trying to tease apart the different things we discussed.
So for example, on https://wiki.duraspace.org/display/FF/Use+Cases+Summary+-+API+Extension+Architecture there has been some analysis for patterns that have appeared across different use cases.15:13
this page is old and probably not complete. but one of the items is titled: "Selection and Filtering of Fedora resources or requests" and described as: "A pattern that allows for selecting Fedora resources and/or requests by some criteria"15:14
And as I understand it, to this point the api-x group has proposed satisfying this requirement by using the rdf:type of the resources in Fedora.15:15
This appears in acoburn's SD&B proposal concretely as '"supportsType" : ["fedora:Resource"]'15:16
<ajs6f>esm__: yes, that's how I understood it— the question is whether static nominal typing like that is actually sufficient. My argument from experience is that it becomes extremely messy at scale.15:17
<esm_>And one of the positions/arguments in today's discussion is that this is not sufficient because one ends up with type hierarchy so deep as to narrow down the objects that can be operated on by a service.
* mohamedar leaves
<esm_>e.g. Thumbnail16by16WebImage
* mohamedar joins15:18
* mohamedar leaves
<esm_>Ok good. I just wanted to confirm that I'm understanding at least one of the issues.
* mohamedar joins
<ajs6f>esm__: and you have to declare every single type on every single thing in advance, and you have to make sure that every single piece of software that interacts with the repo redeclares any types that are affected by any other changes it made toa resource.
esm__: So if a client adds a new delivarble to the thing that was formerly a Thumbnail16by16WebImage, it better know how to alter the types on that thing, and it better do it correctly, or SD & B stops working.15:19
afk for shoveling bbl15:20
<esm_>Ok. So a separate, but perhaps related issue, is invoking the services advertised by SD&B. Specifically, the use of a machine-readable interface definition language to describe the service(s) advertised by SD&B.15:21
Simply providing  " "hasEndpoint" : ["http://host-1/foo/rest", "http://host-2/foo/rest"]" and ""supportsType" : ["fedora:Resource"]," isn't sufficient.15:22
<acoburn>esm_ what about using HTTP Options?15:23
esm_ e.g. on the service itself or on the API-X based proxy to that service15:24
<esm_>acoburn: sorry, you mean in the context of supplying an interface description?15:25
<acoburn>esm_ I mean in terms of the client interaction with the service
<esm_>There were lots of threads on the call so I'm just trying to separate in my mind the different threads and the positions that were presented.15:26
<acoburn>esm_ if a client needs to find out what a given service can _do_, there are two basic mechanisms: OPTIONS and Link headers
<esm_>acoburn: yes, gotcha.
<acoburn>esm_ if a client wants to find out _about_ the service, that would be in the RDF describing the service, e.g. via the registry15:27
* esm_ nods15:28
<acoburn>esm_ clearly, there was a desire to make that description more extensive, but my point in the PoC was simply that there needs to exist some kind of description
* ksclarke leaves
<acoburn>esm_ as for what that description needs, I'll leave that to the larger group; the triples I described seems to suffice for _my_ use cases15:29
<esm_>so in terms of your SD&B proposal, regarding the description of a service, can we just offer the OPTIONS/Link headers approach as a mechanism for retrieving the description but say that specifying the description itself is out of scope?
<acoburn>I'm happy to say that the content of that description is out of scope
what's in scope is that there _is_ a description and that it is discoverable
e.g. Link: <uri>; rel="describedby"15:30
<esm_>Right, that makes sense to me.
As far as the issue of rdf:type is concerned, is that an issue for API-X to solve?15:31
<acoburn>There needs to be some mechanism for dynamically binding a service to a particular resource
rdf:type was just a convenient shorthand15:32
<esm_>That is, if we don't want "hard code" types in service descriptions by specifying an rdf:type a priori, then that seems to point to some form inferencing on the content in the repository.
<acoburn>yes, some form of inference makes a lot of sense
<esm_>Ok. But that seems to not be under the purview of api-x, no?15:33
<acoburn>well, it seems to be under the purview of the implementation of a SD&B component, which seems to be under API-X
<esm_>Hm. So what would that entail (no pun intended) of users of API-X? Would that mean that they have to use a triple store that performs inferencing? Or would the API-X framework perform inferencing?15:35
<acoburn>That's the part I'm not entirely clear on. It would be _really easy_ to implement what I suggested (basic rdf:type matching). Adding inferencing would involve the use of some additional machinery15:37
…but ajs6f has more experience working with jena that I. I suspect there would be a facility to implement this sort of "simple" inference
<esm_>Yeah my experience with inferencing is also limited but I don't think requiring it is something to be taken lightly.15:38
<acoburn>either way, I wouldn't expect API-X to require an underlying triplestore; that seems overkill15:39
<esm_>But to me that is what inferencing would imply.
<bseeger>I do wonder how many systems would have a triplestore anyways. Seems like most want one - so maybe requiring one isn't all that bad?15:40
though it could totally be overkill
<esm_>Right, but beyond a triple store, inferencing implies ongoing evaluation of entailed triples.
Consider when a new "type" is added or modified. Entailed triples have to be re-calculated.15:41
<esm_>And, the performance of Jena in this regard is not very good, compared to other triplestores.
<acoburn>esm_ I'd think the entailed graph would need to be precalculated, rather than doing this on the fly
<esm_>acoburn can you say more about that?15:42
<acoburn>esm_ the assumption is that the ontologies driving the inferencing don't change very much
esm_ so if Foo < Bar < Baz in the class hierarchy, then you cache that data in memory15:43
* ksclarke joins
<acoburn>esm_ then, when matching on rdf:type, you do a set intersection on the larger (in memory) set
<esm_>Ok I'm not sure I fully understand but I think that's my shortcoming and not your explanation :)15:44
<acoburn>esm_ basically, if you have a resource of type Foo (subclassOf Bar -> subclassOf Baz) and a service that operates on resources of type Baz15:45
<esm_>If I have a repository of objects, and I somehow indicate to the system that objects with predicates foo:bar and foo:biz should be considered members of class Baz, then what would be pre-calculated in that scenario?15:46
<acoburn>esm_ I was thinking of simple rdfs entailment. I will have no part of anything that's more complex
<esm_>the triple 'object rdf:type Baz' isn't explicit in any object, it would be an entailment from an inferencing operation15:47
<acoburn>esm_ right, but if SD&B knows that Foo implies Bar and Baz, then it would be a match15:48
* dwilcox leaves
<ajs6f>esm__:: acoburn: Hold on. Hold on. "Inferencing" != RDFS or OWL entailment.
esm__:acoburn: Inferencing can just be matching between sets of property-value pairs.
esm__:acoburn: E.g. Resource hasProp1 value1 ; hasProp2 value2 match with service needsProp1 anyVal, that kind of thing.15:49
<acoburn>ajs6f: I had been thinking specifically of entailment here
<ajs6f>acoburn: I know, and see where it gets you?
esm__:acoburn: Graph entailment is mighty powerful medicine.15:50
<esm_>Ok, cool. So the SD&B proposal could be modified pretty easily to allow matching on property-value pairs, and an initial prototype could just implement/support rdf:type as a property (for example).15:51
<ajs6f>esm__ : acoburn: What's more, you can do a lot of inferencing with _RDF_ entailment (Skolemization into prenamed things)
esm__ : acoburn: And that is dead cheap .
esm__: Yeah, the important point here is to give people a mechanism to describe things on which SD & B acts directly, instead of forcing them to preinfer via static named types.15:52
<acoburn>esm_ ajs6f: that works for me.15:53
* esm_ nods
<ajs6f>esm__: How powerful does that mechanism need to be? OWL Full is probably too much. {grin} Seriously, we need use cases to understand the real need.
<esm_>Of course, yeah +1 to use cases.
<acoburn>+1 to use cases
<esm_>ok, good discussion. my understanding evolves (in a positive direction).
<ajs6f>esm__:acoburn: E.g. how about matching resource hasChild _:foo . _foo mimetype image/jp2k with service name "IIIF viewer", that kind of thing.15:54
esm__:acoburn: Just graph entailment there. No fancy pants. Just plain pants. Well, maybe a bit of flare for flair.
<esm_>There may be some use cases that are amenable to being updated, such as https://wiki.duraspace.org/x/7ZQpB15:55
<acoburn>ajs6f: as long as the relevant graph can be easily retrieved from fedora, that works for me. Once we start needing to use an external triplestore, I get nervous15:56
<ajs6f>acoburn: I hear you. Maybe it's time to add an architectural constraint " SD & B requires no datastore other than Fedora".15:57
<acoburn>ajs6f: yes, I think that's a really important constraint
<ajs6f>acoburn: Then it should be explicit. I may have missed it tho'.15:58
<acoburn>ajs6f: I don't think that has been spelled out. I would not be against any sort of embedded database, just as long as additional external systems aren't required15:59
<ajs6f>acoburn: Keeping it in the repo is keeping it real. If you need something more sopjhisticaed than the repo, you may be making assumptions about universal use cases you don't want to make. Assuming only the repo guarantees than everyone already shares the assumptions about what the data store must be capable of.16:00
<esm_>as an aside, has anyone seen this exception: http://pastebin.com/Zp4eBVFr16:03
Happens on 4.4.0, seemingly at random but under load, when depositing resources with blank nodes.16:04
Just thought I'd ask- gonna take a deeper dive into this later...
<ajs6f>esm__: https://wiki.duraspace.org/x/7ZQpB could totally be written to you pattern-matching based binding16:05
<esm_>ajs6f: exactly. rdf:type (myns:Image) isn't sufficient in this case.16:07
<ajs6f>esm__: but the varous kinds of image resources are going to have property graphs that distinguish them easily16:08
* jgpawletko leaves16:09
<ajs6f>acoburn: This has a kind of common flavor with https://jira.duraspace.org/browse/FCREPO-161116:11
<acoburn>ajs6f: are you thinking that's the responsibility of the repo?16:14
ajs6f: I saw LDF as a good candidate for an external system
<ajs6f>acoburn: i'm thinking that answering BGPs for aresource might be.
* apb18 joins16:15
<ajs6f>acoburn: answering BGPs might enable a lot for very little work, an future impls could reasonably do it16:16
acoburn: just thinking out loud
<acoburn>ajs6f: it's definitely easy to implement
<ajs6f>acoburn: it buys pattern matching for a number of purposes. it's cheap to execute.16:18
* esm_ leaves16:23
* rdfloyd leaves16:28
<ajs6f>out for the day, and possibly for some time
* ajs6f leaves
<apb18>Elliot pointed out this post-meeting conversation - I think it makes sense to link to it from the meeting minutes.16:30
* dwilcox joins16:32
* bseeger leaves16:37
* jgpawletko joins16:39
* dwilcox leaves16:46
* acoburn leaves16:50
<osmandin>ajs6f: enjoy the snow16:51
* osmandin leaves
* whikloj leaves17:00
* jrgriffiniii leaves17:09
* dwilcox joins17:13
* jgpawletko leaves17:36
* dwilcox leaves17:45
* dhlamb_ leaves18:17
* mohamedar leaves18:28
* dhlamb joins18:39
* mohamedar joins19:47
* jgpawletko joins20:08
* mohamedar leaves20:13
* mohamedar joins20:18
* apb18 leaves20:24
* mohamedar leaves21:04
* dhlamb leaves22:02
* ksclarke leaves22:14
* f4jenkins joins23:17
* peichman leaves23:21