Log of the #duraspace-ff channel on chat.freenode.net

Using timezone: Eastern Standard Time
* kaarefc joins00:54
* kaarefc leaves01:00
<bljenkins>Project fcrepo-kitchen-sink build #248: FAILURE in 12 hr: http://ci.projectblacklight.org/jenkins/job/fcrepo-kitchen-sink/248/01:15
* nbanks joins01:16
<bljenkins>Yippie, build fixed!01:24
Project fcrepo-kitchen-sink build #249: FIXED in 8 min 44 sec: http://ci.projectblacklight.org/jenkins/job/fcrepo-kitchen-sink/249/
* kaarefc joins02:21
* kaarefc leaves02:24
* eddies leaves05:07
* eddies joins05:16
* eddies leaves
* eddies joins
* fasseg joins05:27
* kaarefc joins05:35
* fasseg leaves05:45
* fasseg joins06:00
* eddies leaves07:31
* eddies joins07:45
* eddies leaves
* eddies joins
* github-ff joins08:06
[fcrepo4] fasseg created tx-workspaces (+1 new commit): http://git.io/d3RhTw
fcrepo4/tx-workspaces a0b190d fasseg: added Resource and a simple test for crud operations on workspaces. Still unbale to delete a workspace, and merge hast still to be tested with some new nodes added or old ones removed
* github-ff leaves
<fasseg>hmm In this green box of the modeshape documentation it says the modeshape impl of the Session interface is thread-safe, so we might yet be able to just wrap a transaction around a session object...08:27
<bljenkins>Project fcrepo-kitchen-sink build #250: SUCCESS in 6 min 41 sec: http://ci.projectblacklight.org/jenkins/job/fcrepo-kitchen-sink/250/08:29
* github-ff joins08:52
[fcrepo4] fasseg pushed 1 new commit to tx-workspaces: http://git.io/9afavg
fcrepo4/tx-workspaces 0076fa4 fasseg: added method to check if a workspace is accessible by a session, since deletion seems no to remove the possibility to use Repository.login to a deleted workspace
* github-ff leaves
* github-ff joins08:58
[fcrepo4] fasseg pushed 1 new commit to tx-workspaces: http://git.io/5zG7lg
fcrepo4/tx-workspaces c16c3f3 fasseg: removed unnecessary calls to session.save() since operation on the Workspace interface are dispatched immediately
* github-ff leaves
* gregjansen joins09:01
* kaarefc leaves09:15
* ajs6f joins09:29
<bljenkins>Project fcrepo4 build #536: UNSTABLE in 17 min: http://ci.projectblacklight.org/jenkins/job/fcrepo4/536/
* kaarefc joins09:32
<fasseg>ajs6f: I read here (in the first green box) that modeshape's Session impl is thread-safe: https://docs.jboss.org/author/display/MODE/ModeShape+in+Java+applications09:34
<ajs6f>And that's what rhauch told cbeer and myself ysterday.09:35
<fasseg>so just wrapping the session in a tx might yet work
* kaarefc leaves09:36
* awoods__ joins09:59
* awoods leaves10:02
* kaarefc joins10:10
* kaarefc leaves
<cbeer>fasseg: excuse the bad formatting, but here's our discussion with rhauch yesterday: https://www.pivotaltracker.com/story/show/4935152910:29
<pivotal-bot>chore: run transactions idea by rhauch (accepted) / owner: Chris Beer
so ill stop the workspace impl idea for the time being ;)10:34
* nbanks_ joins10:37
* nbanks leaves10:39
<cbeer>fasseg: i'd be sure to stash the code somewhere though, either for multitenancy or if sessions don't pan out10:40
<fasseg>it's on the tx-workspace branch atm10:41
<pivotal-bot>A. "Reticulated" Soroka finished "Propose a straw-man relationship management API" https://www.pivotaltracker.com/story/show/4906084510:46
<cbeer>ajs6f: "Firstly, identifiers could be constructed from the UUIDs of JCR Nodes that support individual resources. " <-- i think having full sparql/update support may make that not-too-unpleasant10:51
assuming we put a triple in for <uuid> <same-as> <http location>
<ajs6f>cbeer: No, perhaps not for management. I was thinking more about publishing out LD or integration to other services.
cbeer: And the fact that moving a resource inside the repo would10:52
require extra updating behavior.
cbeer: But nothing we couldn't do if we decide to do it.
<fasseg>arg im unable to join the hangout atm...10:59
<cbeer>awoods eddies gregjansen?11:01
<awoods>I will be in the steering call today
<eddies>hey, awoods and i have the sg call
<pivotal-bot>Hello, gregjansen
<eddies>cbeer: can you carry on in our absence or should we try and postpone standup for an hour?
I can't make it in an hour, but I don't have that much to contrubute.
<cbeer>sure, let's carry on.
quick standups are good
<pivotal-bot>feature: Ensure REST API supports workspace identifier prefixes by adding tests (started) / owner: Nigel Banks
<ajs6f>Are we doing standup?11:08
<gregjansen>In case it isn't obvious, we unc folk have been absent from this sprint.. I am doing a code/project overview for the rest of our team this week. Unfortunately I'll be away during sprint end/start next week.11:10
<ajs6f>I'm in the Hangout. Are you people talking, because I'm not hearing anything.
<cbeer>ajs6f: i was talking. and asked 2 questions to you
<pivotal-bot>Frank Asseg added "Implement a transaction example as suggested by randal" https://www.pivotaltracker.com/story/show/49418225
<ajs6f>I'll reload the page and see if that helps.
<pivotal-bot>Frank Asseg started "Implement a transaction example as suggested by randal" https://www.pivotaltracker.com/story/show/4941822511:11
eddies: unless fasseg solves the problem for me, can you look at that ^ pull request and look at the error?11:19
<pivotal-bot>Chris Beer added comment: "http://fcrepo4.fcrepo.org/fcrepo/rest/objects/2669fb85-7560-4a96-9ef1-0b53e8c5f5e911:21
http://fcrepo4.fcrepo.org/..." https://www.pivotaltracker.com/story/show/49064877
Chris Beer edited "Implement a transaction example as suggested by rhauch" https://www.pivotaltracker.com/story/show/49418225
Chris Beer estimated "Propose a straw-man relationship management API" as 3 points https://www.pivotaltracker.com/story/show/4906084511:23
Chris Beer delivered "Propose a straw-man relationship management API" https://www.pivotaltracker.com/story/show/49060845
Chris Beer added "Implement fcr:graph management API " https://www.pivotaltracker.com/story/show/4941946511:24
Chris Beer estimated "Implement fcr:graph management API " as 3 points https://www.pivotaltracker.com/story/show/49419465
Chris Beer started "Implement fcr:graph management API " https://www.pivotaltracker.com/story/show/49419465
Chris Beer edited "Implement fcr:graph management API " https://www.pivotaltracker.com/story/show/49419465
Chris Beer edited "Implement fcr:graph management API " https://www.pivotaltracker.com/story/show/4941946511:25
<cbeer>ajs6f: so, from your doc, are we assuming the triples will be serialized into jcr properties (or have some impact on the state of the object)? or are there other triples that need to get serialized somewhere else?11:26
<ajs6f>cbeer: No assumption made, because I was (not joking) really intending only to define the API. eddies wanted the triples to get serialized into a hidden node, and any triple where the Subject is the same as the resource in question to also get stored as JCR props.11:28
I think we _could_ store them all as JCR props, but blank nodes and URIs that aren't Fedora resources would get a little hairy.
<cbeer>ah, right. blank nodes definitely requires some magic.
<ajs6f>We _have_ the ability to mint UUID-only nodes.11:29
<cbeer>(of course, nothing's stopping us from adding a binary property.. fedora:triples or something.. to all of our fedora objects)
<ajs6f>That's what eddies suggested, w/ the addition of parsing out a special subgraph, as described.
<fasseg>cbeer: hmm possibly two grizzly instances might be started, because of an additional @ContextConfiguration in the tests...can you remove the contextconfig location there since it's already on abstractresourceit..
<ajs6f>I don't like the idea of "stashing" the RDF opaquely, but admittedly, parsing it fully into JCR could be nasty, as well.11:30
<cbeer>can and will do.
<fasseg>this spins up a second grizzly as defined in test-conatiner.xml
The most dangerous animal in Yellowstone Park.
cbeer: In your pull, is the default store defined explicitly, or implicitly by the DEFAULT_STRATEGY_HINT?11:32
<cbeer>ajs6f: every CompositeBinaryStore is required (by schema and #start()) to have a named binary store with the key "default"11:33
<ajs6f>cbeer: Ah, that's cool. Might want to comment on that, or maybe you did and I missed it.
<cbeer>i think i did, but i'll double check
<ajs6f>cbeer: Other than that, looks fantastic to me.
<cbeer>thanks ajs6f. i'll do that thing and get them to take a pass at it11:34
<ajs6f>Policy-driven storage has lift-off!
* ses7404 joins11:37
* ses7404 leaves11:38
<cbeer>ajs6f: hm.. i wonder if we could/should kill off the fcrepo-generator-rdf now that we're baking rdf into core?11:44
<ajs6f>cbeer: I totally agree with that. RDF for me has always been a first-class concern in the framework.11:45
<cbeer>and i guess generator-dc just hangs around as a way to mimic fcrepo 3 concepts11:46
<ajs6f>cbeer: Yes. The only thing that they were doing that we're not now doing differently is the "well-known datastream" generation, which, frankly, I never liked anyway. Too much like the infamous DC and RELS-* morass.11:47
cbeer: For migration from fcrepo3, we should just collapse DC and RELS-* into properties.
<cbeer>works for me11:49
<ajs6f>Down with magic datastreams!
<cbeer>especially since we've given up any pretense of looking anything like fcrepo3
<ajs6f>Well, that's an interesting question— just how serious are we about the legacy-api module?11:50
<cbeer>and we better do it soon, so awoods can blame that rogue eddies for encouraging such behavior
<ajs6f>And how "big bang" are we going to force migration to be?
<cbeer>ajs6f: imo, as big-bang as we want, as long as people still migrate.11:51
that's the MVP way, after all
not going to fly with the steering group, but..11:52
* github-ff joins
[fcrepo4] cbeer force-pushed integrate-object-serialization from 4e143bb to 0041d4d: http://git.io/ZpJobw
fcrepo4/integrate-object-serialization 0041d4d Chris Beer: integrate fcrepo-object-serialization into the default REST API
* github-ff leaves
<ajs6f>But we are no longer meeting w/ the steering group directly, so NO PROBLEM!11:53
<cbeer>ah ha!
slight wrinkle in that, though.
* github-ff joins11:55
[fcrepo4] cbeer pushed 1 new commit to master: http://git.io/-KTj4w
fcrepo4/master 5c4bfe2 Chris Beer: Merge pull request #55 from futures/integrate-object-serialization...
* github-ff leaves
<ajs6f>Well, if we can offer a smooth semi-automated content-migration, then I think that's 80% of the job.11:56
<eddies>ok, off the sg call12:02
scratch, that, just got pulled into another call
<ajs6f>Nice to see you, eddies. Stop in again sometime.12:03
<pivotal-bot>Chris Beer added "fix up fcrepo-bagit-object-serialization module" https://www.pivotaltracker.com/story/show/4942361112:12
Chris Beer started "fix up fcrepo-bagit-object-serialization module" https://www.pivotaltracker.com/story/show/49423611
<bljenkins>Yippie, build fixed!12:13
Project fcrepo4 build #537: FIXED in 20 min: http://ci.projectblacklight.org/jenkins/job/fcrepo4/537/
<eddies>cbeer: did fasseg sort out that PR? i see it's closed now
<cbeer>eddies: yes.
<pivotal-bot>Chris Beer accepted "fix up fcrepo-bagit-object-serialization module" https://www.pivotaltracker.com/story/show/4942361112:21
* github-ff joins
[fcrepo-bagit-object-serialization] cbeer pushed 1 new commit to master: http://git.io/SjH3lw
fcrepo-bagit-object-serialization/master d1d0e74 Chris Beer: fix up bagit serialization after serialization moved into core
* github-ff leaves
<pivotal-bot>Chris Beer added comment: "https://github.com/futures/fcrepo-bagit-object-serialization/commit/d1d0e74b617bb912c5f28eec60fcb206daf7aafc" https://www.pivotaltracker.com/story/show/49423611
* travis-ci joins
[travis-ci] futures/fcrepo4#475 (master - 5c4bfe2 : Chris Beer): The build passed.
[travis-ci] Change view : https://github.com/futures/fcrepo4/compare/9cf9aa38bca4...5c4bfe230ff9
[travis-ci] Build details : http://travis-ci.org/futures/fcrepo4/builds/6961516
* travis-ci leaves
<bljenkins>Yippie, build fixed!12:24
Project fcrepo-bagit-object-serialization build #10: FIXED in 3 min 34 sec: http://ci.projectblacklight.org/jenkins/job/fcrepo-bagit-object-serialization/10/
<pivotal-bot>Chris Beer added comment: "passing jenkins build: http://ci.projectblacklight.org/jenkins/job/fcrepo-bagit-object-serialization/10/" https://www.pivotaltracker.com/story/show/4942361112:25
<cbeer>ajs6f/fasseg: oh, i remember the other question i had for you guys -- what's the story on mode-1710?12:27
<bljenkins>Project fcrepo-kitchen-sink build #251: SUCCESS in 5 min 48 sec: http://ci.projectblacklight.org/jenkins/job/fcrepo-kitchen-sink/251/12:40
<pivotal-bot>Chris Beer added comment: "subsumed by https://www.pivotaltracker.com/story/show/49419465" https://www.pivotaltracker.com/story/show/4902583912:43
Chris Beer deleted "PUT /rest/{path} endpoint" https://www.pivotaltracker.com/story/show/49025839
* ajs6f leaves12:44
<pivotal-bot>Chris Beer edited ""Branch" a subset of the repository into a workspace for CRUD" https://www.pivotaltracker.com/story/show/4930307512:50
Chris Beer edited ""Branch" a subset of the repository into a workspace for CRUD" https://www.pivotaltracker.com/story/show/49303075
* ajs6f joins
<pivotal-bot>Chris Beer edited "REST API getChildren should use a JAX-B model" https://www.pivotaltracker.com/story/show/48818029
Chris Beer delivered "Make a HTTP path-reference request return a "describe" response" https://www.pivotaltracker.com/story/show/4906487712:51
Chris Beer delivered "Update LowLevelStorageService to be CompositeBinaryStore aware" https://www.pivotaltracker.com/story/show/48835251
<ajs6f>cbeer: does https://www.pivotaltracker.com/story/show/49064877 mean that "fcr:describe" is gone?
<pivotal-bot>feature: Make a HTTP path-reference request return a "describe" response (delivered) / owner: Chris Beer
<cbeer>ajs6f: yes.
<ajs6f>+1 to that!
<pivotal-bot>Chris Beer added comment: "e.g.: http://fcrepo4.fcrepo.org/fcrepo/rest/objects/2669fb85-7560-4a96-9ef1-0b53e8c5f5e9/12:52
<dsStor..." https://www.pivotaltracker.com/story/show/49057421
Chris Beer added comment: "or http://fcrepo4.fcrepo.org/fcrepo/rest/objects/1d5d892d-6088-47ab-925f-b7601c51f0f612:53
default/org...." https://www.pivotaltracker.com/story/show/49057421
Chris Beer added "Figure out ISPN low level cache entries" https://www.pivotaltracker.com/story/show/4942688512:54
Chris Beer delivered "Update fixity and datastream location information for composite stores configurations" https://www.pivotaltracker.com/story/show/49057421
Chris Beer added comment: "e.g. http://fcrepo4.fcrepo.org/fcrepo/rest/objects/aa5c3653-f8fc-483b-b4aa-073e3ba61cd9/fcr:export" https://www.pivotaltracker.com/story/show/4891115312:55
<eddies>cbeer: that's awesome13:00
(referring to http://fcrepo4.fcrepo.org/fcrepo/rest/objects/2669fb85-7560-4a96-9ef1-0b53e8c5f5e9/)13:01
down w/ describe
<ajs6f>cbeer is a REST machine!
eddies: do you buy the idea that "describe" (now no longer using a special term) endpoints should incorporate RDF (named graph) data?13:02
<eddies>ajs6f: depends on what you mean by incorporate…you mean a subset of the named graph data or everything?13:03
<ajs6f>eddies: Open question. maybe just "properties" and/or in-repo relationships?13:04
<eddies>and the expectation would be that you could PUT updates to that same "describe" endpoint, right?13:06
<ajs6f>Also an open question.
but that would be "REST"ful.
<eddies>and if we are taking some subset of the triples in the named graph and making them into jcr properties that we expose on describe, and we allow PUTs to describe to update those same properties, we probably need to update the named graph as well13:08
<eddies>which sounds a little messy, but doable
<ajs6f>The stpred graph is the authoratative store, right?
<eddies>except where it isn't. i think we're still talking about have jcr properties that aren't in the named graph13:09
ah you mean just for where the props and the graph overlap
then yes
<ajs6f>yeah- but the problem you mention is real. We could get into all kinds of update nastiness.13:10
<eddies>hmm. i'm not having any brilliant insights into resolving that13:14
<ajs6f>Maybe we commit to resolving the named graphs into JCR, instead of storing them opaquely?13:15
<eddies>you mean, transforming the named graph into jcr nodes?13:16
<eddies>i'm not really confident in that panning out...
<ajs6f>Or admitting that the graph is a second-class citizen.
I don't want to wite an RDF store in JCR, either.13:17
But I'm less clear on what we are supporting with this named graph idea if we aren't actually parsing it.
<eddies>i think making a graph fit into the jcr tree is going to make for some … interesting workarounds
<ajs6f>Yes, it will. I'm just trying to get at the fundamental tension here.
Which, to me, is— is the graph a central abstraction or not?13:18
<eddies>it's like everything that sucks about rdf/xml realized in jcr ;-)
<ajs6f>If we constrain ourselves back down to "properties", then this all goes away.
Such a constrained graph goes smoothly into JCR.
No named graph business needed.
("properties" including relationships.)13:19
But if we want to manage full-on RDF in the repo, we're going to find ourselves forced to provide the functions that any RDF management service will have to provide.13:20
Or we'll have to subcontract it out to an extension service. (See Resource Index, fcrepo3)
<cbeer>as a first pass, let's constrain to properties of the node... and, i guess, relationships that are implicit in the JCR hierarchy13:22
and worry about the rest later?
<eddies>so, i think properties-only (by which i mean any triple whose subject is the node in question) satisfies the 80/20 rule for what folks want to express
and it gives us "native" jcr query support
<ajs6f>I'm not sure that's true, eddies, but I also think that doing more in the kernel/core is not a great idea for the reasons we just went through.13:23
<eddies>and we can provide rdf/linked data representations of the node as part describe
<ajs6f>So properties-only, and a property (as is supported by JCR) can be a relationship directly to another JCR node.
<eddies>ajs6f: you mean you're not sure about 80/20 or not sure about something else?
<ajs6f>80/20— I think there's a surprising amount of desire out there for more sophisticated descriptive RDF. But I _don't_ think that should make us write a quadstore in JCR.13:24
That's a problem for an asynch extension service.
_If_ it's a problem.13:25
So I'll rewrite the strawman API to constrain the scope, right?
<cbeer>ajs6f: let me take a first pass at implementation today13:26
see if that raises any other issues
<ajs6f>cbeer: Sure thing. That's a good idea.
<eddies>ajs6f: properties-only. but i'd like to be able to support *any* relation. i was thinking we just require properties to be expressed in NTriple or Turtle like syntax13:27
that way it's syntactically clear if the property refers to a uri or a literal (or datatyped literal, for that matter)13:28
<ajs6f>eddies: What do you mean by any relation? Resource-to-any-URI?
<eddies>does that make sense?
any uri or literal
<ajs6f>If we force expression in some RDF format, sure. But what about more granular endpoints? Or do we discard them?13:29
<eddies>what do you mean by more granular endpoints?
<cbeer>the more granular endpoints are there for people who don't want to parse RDF?
<ajs6f>Endpoints that address a single property.
And if we have only RDF formats?
How do we do deletions/updates?13:30
SPARQL Update?
<cbeer>i'd vote ditch them for now. sparql-update ALL THE THINGS
because it's really not a bad little protocol
<ajs6f>So a Sparql update endpoint, and then RDF format endpoints?
<cbeer>which may be one and the same, no?
<ajs6f>PUT to one, POST/GET on the other?
Yeah, I guess we choose by MIME type.13:31
That would simplify the API, which is good.
But there is one small downside.
<eddies>ok, can we take this to a quick hangout session w/ a google doc? i think i need to see some example requests
<ajs6f>My example request is to take this to a Hangout.
I request that.
* awoods leaves13:40
* awoods joins13:41
<cbeer>looks like the jcr query language has some clever logic around reference properties: https://community.jboss.org/thread/20675313:57
<ajs6f>So getting paths out of nodes in results in no worse than PATH(node)13:58
* fasseg leaves14:11
<cbeer>heading to the office.14:13
<pivotal-bot>A. "Bupholutac" Soroka started "Propose a straw-man relationship management API" https://www.pivotaltracker.com/story/show/4906084514:15
* ajs6f leaves15:08
<cbeer>hm. i'm confused how to add properties dynamically.15:27
* ajs6f joins16:16
<cbeer>ajs6f: looks like jcr properties are more limited than we thought.16:41
i guess there's no such thing as a multi-valued reference property?
<ajs6f>But isn't that just what the abovelinked web page (linked by you) refers to?
<cbeer>yeah, that's what i thought too16:42
<ajs6f>BUt no?
* github-ff joins
[fcrepo4] cbeer force-pushed rdf-all-the-things from 019eb83 to 8e9b8f5: http://git.io/cMpL6w
fcrepo4/rdf-all-the-things 8e9b8f5 Chris Beer: poke object graph through the REST API
* github-ff leaves
<cbeer>oh, wait. i'm looking in the wrong place
ah, so. jcr.Value has no concept of references16:43
and when you have a multivalued property, all you can do is get Value[] back16:44
<ajs6f>SO you can't go to a Property if it's a Reference, you got to get the target from some other source?16:45
<cbeer>no, i think it's just single-valued properties have a nice accessor to go from a reference to a node16:46
and multivalued properties.. don't
<ajs6f>If you get the Value[] for the Property, and choose a single one, can't you get a target from that?
Oh, wait, you already said not.16:47
Value can't produce a Node.
That makes a horrible sense.
Value is an immutable thing.
<bljenkins>Project fcrepo4 build #539: UNSTABLE in 13 min: http://ci.projectblacklight.org/jenkins/job/fcrepo4/539/16:55
* github-ff joins17:17
[fcrepo4] cbeer force-pushed rdf-all-the-things from 8e9b8f5 to f2ae11b: http://git.io/cMpL6w
fcrepo4/rdf-all-the-things f2ae11b Chris Beer: poke object graph through the REST API
* github-ff leaves
* nbanks_ leaves17:19
* nbanks joins
* gregjansen leaves17:33
* github-ff joins17:39
[fcrepo4] cbeer force-pushed rdf-all-the-things from f2ae11b to 41b571a: http://git.io/cMpL6w
fcrepo4/rdf-all-the-things 41b571a Chris Beer: poke object graph through the REST API
* github-ff leaves
* ajs6f leaves17:42
<bljenkins>Yippie, build fixed!17:54
Project fcrepo4 build #541: FIXED in 14 min: http://ci.projectblacklight.org/jenkins/job/fcrepo4/541/
<nbanks>Anyone still around?18:03
* github-ff joins18:59
[fcrepo4] cbeer force-pushed rdf-all-the-things from 41b571a to 067b982: http://git.io/cMpL6w
fcrepo4/rdf-all-the-things 067b982 Chris Beer: poke object graph through the REST API
* github-ff leaves
* nbanks leaves19:50
* nbanks joins
* nbanks leaves20:18
* nbanks joins21:14
* nbanks leaves21:22
* awoods leaves22:54
* nbanks joins23:19
* github-ff joins23:20
[fcrepo4] cbeer force-pushed rdf-all-the-things from 067b982 to 1121558: http://git.io/cMpL6w
fcrepo4/rdf-all-the-things 1121558 Chris Beer: poke object graph through the REST API
* github-ff leaves
* nbanks leaves23:24

Generated by Sualtam