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

Using timezone: Eastern Standard Time
* mohideen joins06:39
* mohideen leaves06:44
* mohideen joins06:45
* mohideen leaves
* mohideen joins07:30
* benpennell joins07:38
* mohideen leaves07:39
* mohideen joins07:47
* awoods joins08:17
* benpennell leaves08:22
* apb18 joins08:43
* dhlamb_ joins08:45
* lsitu joins08:56
* rotated8 joins08:57
* dbernstein joins09:00
* apb18_ joins09:06
* apb18 leaves09:07
* whikloj joins09:08
awoods: I've got to be on the road in 15, so I might be unable to talk after that09:09
* benpennell joins09:13
* peichman joins09:18
*is here*09:19
* whikloj stepping out, try to get back on shortly09:21
* whikloj leaves
<mohideen>awoods: yes
<dhlamb_>i'm retrying now, i may have derped and forgotten the 'clean'09:29
<rotated8>yes, I'm gonna wok on that today
* yamil_ joins09:36
* dwilcox joins09:41
<dhlamb_>awoods, build success. i did not run 'clean' after pulling from master. sry for the confusion09:45
* whikloj joins09:47
* whikloj back
apb18_: agreed
ugh forgot about the web.xml09:48
probably outside the scope of this sprint09:51
* dwilcox leaves09:56
<peichman>apb18_: we are also interested in a Shib principal provider (eventually)10:00
maybe include in build, but require a deploy-time system property or config var to turn it on?10:03
* dhlamb_ leaves10:04
<apb18_>peichman++ deploy time!
<whikloj>awoods: make it work first, then turn it off ++10:06
<whikloj>epic link https://jira.duraspace.org/projects/FCREPO/issues/FCREPO-2582?filter=allopenissues10:08
* dhlamb joins
sry, power flickered for me and i lost internet and had to reset my router, etc...10:10
* kestlund joins10:12
<whikloj>not using modeshape makes a possible replacement of modeshape an attainable goal
* kestlund leaves10:13
<dhlamb>we can re-use fcr:versions elbow to minimize impact10:18
<peichman>awoods: with you10:22
<mohideen>awoods: with you
<dhlamb>afk for a sec10:23
<peichman>separate versioning branch++10:28
sure, authz sounds good10:33
awoods, sounds like a good achievable goal10:34
<rotated8>sounds good to me!10:37
I think I understand it
<whikloj>awoods: did we also discuss possible impacts on the HTML-UI yesterday? Maybe rotated8 can note any issues there too?10:39
<dbernstein>I just added this jira related to webac toggling : https://jira.duraspace.org/browse/FCREPO-263010:46
<peichman>sounds good to me10:49
<whikloj>its the twilight zone!!!10:56
mohideen/lsitu: To confirm are you, good to jump on this line at 10 ET tomorrow and see if we can flesh out some of the design decisions?10:57
<mohideen>whikloj++ awoods++
<whikloj>dbernstein: web.xml and repository.json10:59
* whikloj leaves11:03
<awoods>rotated8: please let me know how attempting to build the fcrepo4 codebase goes, and that you can create Jira tickets.11:10
dbernstein/dhlamb/lsitu/mohideen/peichman/rotated8/whikloj: I am going to create a new wiki documentation space for 5.x since we will probably want to keep the 4.x documentation space for bleeding-edge of the 4.7-maintenance work.11:18
<awoods>dbernstein: can you create another Jira ticket for "Enable WebAC by default" that will come in advance of:11:20
* lsitu leaves11:38
* lsitu joins
* rotated8 leaves11:43
* whikloj joins11:49
lsitu/mohideen: I realize in my rush this morning I suggested 10 ET tomorrow but I would probably be late to that call.11:57
* peichman leaves
<whikloj>Can we reschedule to after the tech call (12:00 ET) or push up to 10:30 or you two can start and I'll hope on once I get in to work?
<mohideen>whikloj: either time will work for me.11:59
<lsitu>whikloj: I am fine to reschedule it.
<awoods>whikloj/mohideen/lsitu: rescheduled to 12pm ET12:02
<whikloj>mohideen/lsitu/awoods: that is best! thanks all12:03
<whikloj>benpennell: ping12:18
* rotated8 joins12:46
* bseeger joins12:55
* peichman joins13:01
<dbernstein>awoods: I split those tickets up - https://jira.duraspace.org/browse/FCREPO-263113:04
* benpennell leaves13:10
* benpennell joins
<dbernstein>awoods / dhlamb: just wanted to run my approach to https://jira.duraspace.org/browse/FCREPO-2631: basically the task is to copy the maven profile and configuration dependencies from fcrepo-webapp-plus into fcrepo-webapp (not enabled by default so that integration tests work). Then https://jira.duraspace.org/browse/FCREPO-2630 will remove the webac profile and provide a command line option for toggling webac.13:18
<awoods>dbernstein: I think fcrepo-2631 should "Enable WebAC by default", which will include updating the integration tests.13:20
<dbernstein>okay - fair enough.
<awoods>dbernstein: Then fcrepo-2630 would introduce a system-property for toggling webac off at deploy-time. I am not sure what you meant by "a command line option".13:21
<benpennell>whikloj: you rang?13:22
<dbernstein>awoods: yes - system property (delivered as a java opt)13:23
<whikloj>benpennell: oh I just pinged you on the ticket (https://jira.duraspace.org/browse/FCREPO-2624), just wondering why an LDPCv should not be a child of the LDPRv?
<benpennell>whikloj: that's from the specification in this section https://fcrepo.github.io/fcrepo-specification/#general-3 "An implementation must not allow the creation of an https://fcrepo.github.io/fcrepo-specification/#dfn-ldpcv that is https://fcrepo.github.io/fcrepo-specification/#dfn-ldp-contained by its associated https://fcrepo.github.io/fcrepo-specification/#dfn-ldprv."13:26
i don't know the original discussion that led to that. but this only disallows <LDPRv> ldp:contains <LDPCv>. You can still have a ldprv/fcr:versions path since that is not (currently) a containment relation13:27
<whikloj>benpennell: Ah ok, we could implement under the covers but maybe that is a question for the API editors.
awoods: thoughts ^^?
<bseeger>that does beg the question — if a LDPRv is deleted, should the LDPCv stick around?
"there was once this object..."
* rotated8 leaves13:28
<bseeger>and by LDPRv - I mean the LDPR itself
<benpennell>bseeger: i would agree that would be valuable, but i think previous discussion ended up with deleting a ldprv causing the ldpcv to be deleted as well.
<bseeger>benpennell — to be clear though, that's an implementation choice (as it's not explicit in the spec)13:29
<benpennell>yes i agree
<awoods>whikloj: As long as the implementation does not create an ldp:contains relationship, the nesting of JCR nodes can be whatever is most appropriate/efficient.13:30
<whikloj>awoods: agreed13:35
* peichman leaves
<whikloj>bseeger/benpennell: What I find confusing is the second sentence in section 4.3.2 HTTP DELETE of the Fedora API13:36
<bseeger>whikloj: how so?13:37
<whikloj>bseeger/benpennell: Why do we specify the delete if supported should supported on the LDPCv and LDPRv, but in the section for LDPCv and NOT in then there is no DELETE under LDPRv13:38
and then there is NOT a DELETE section under LDPRv
<bseeger>whikloj: note that the LDPRv is equal to the LDPR - so you can delete the LDPRv by a delete to the LDPR
<whikloj>bseeger: so when does the note about deleting a LDPCv also mentions LDPRv?13:40
<bseeger>whikloj: if you delete the LDPCv, you're deleting the LDPCv, the mementos and the versioning model from the LDPRv (making it a plain LDPR again).
whikloj: so the LDPR still remains
whikloj: it just has no versioning interaction model anymore.13:41
<whikloj>bseeger: So we have to make an LDPR to an LDPRv, but if you delete the LDPCv it also changes the LDPRv
acronym bingo!!
bseeger: ok I think I get what you are saying13:42
<bseeger>whikloj - yeah, essentially. So a LDPRv is just an LDPR that has a versioning interaction model turned on.
<whikloj>bseeger/benpennell/awoods: So I think this comes down to an implementation decision as to whether an LDPCv should be made under the LDPRv. As long as we do it without LDP containment (which is prohibited by the Spec).13:43
<awoods>whikloj: yes, I think the implementation choice is wide open.13:44
<bseeger>whikloj: ^^ what he said. :)
<whikloj>right right, except we want to narrow that down WRT the Modeshape impl13:45
<bseeger>whikloj: but how do you create something under something w/o it being contained by it?
<whikloj>bseeger: no idea, direct in Modeshape I'm guessing. I'm not really a Java programmer :)
<bseeger>whikloj: yeah, I don't know modeshape well enough either. One thought I had was like how the webac stuff works (separate container w/ all LDPCvs). or the LDPCv as a 'hidden' sibling to the LDPRv.13:47
whikloj: they may be terrible ideas. :)
<whikloj>bseeger: those are also options, I am wondering if the ldp:contains is a generated triple in which case we might be able to just not generate for LDPCv and LDPRm13:48
bseeger: that might also be a horrible idea
<awoods>whikloj: here is where ldp:contains is created: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-modeshape/src/main/java/org/fcrepo/kernel/modeshape/rdf/impl/ChildrenRdfContext.java#L5713:49
<whikloj>ok so conceivably we could filter out the LDPCvs from that stream, but we would need some sort of property to identify a LDPCv.13:50
<bseeger>whikloj: there was talk of a way to identify them: https://github.com/fcrepo/fcrepo-specification/issues/23313:52
whikloj: but you might come up with a different / better internal way to represent them.13:53
It appears that we already filter out the pairtree nodes in FedoraResourceImpl.getChildren()13:55
* peichman joins13:56
* peichman1 joins13:57
* peichman leaves
* peichman1 leaves14:02
* peichman joins14:03
* peichman1 joins14:04
* rotated8 joins14:07
* peichman leaves
<whikloj>bseeger/benpennell: What is your understanding of the Memento-Datetime on LDPCv (POST/PUT) is the the start-date of the version and the end-date is either the start-date of the next version or the current resource?14:09
OR is the end-date of the version and the start-date is the end-date of the previous version.
<benpennell>start date
of the version being created14:10
<bseeger>yeah, that's my take on it as well.
<whikloj>benpennell: ok so if you cut a single version what is the end-date of that version?14:11
would it be the current LDPRv?
<benpennell>yes, if they are different
<whikloj>benpennell: so we need to compare with the current resource to tell if the end-date has been set on the LDPRm14:12
<benpennell>whikloj: has the implementation group decided to compute end dates for LDPRms? I don't think they are required by the specification, although herbert seemed to favor them14:14
<whikloj>benpennell: no I'm just trying to think through how we could (if we decide to)
see I think the Memento-Datetime set when creating a version indicates the last date it was valid for.14:15
So if I create a resource <foo> with createdDate "today"14:16
2 years later I make a Memento
Is that version can't be changed but (as you point out) its only valid until someone edits the LDPRv now
hmmm I'm making the opposite case14:17
So a Memento-Datetime indicates the start-date of that version, but the next PUT/POST/PATCH to the LDPRv would indicate that the end-date for that version needs to be set as the state of the LDPRv has changed14:18
<peichman1>fyi, I am taking a crack at cleaning up the https://wiki.duraspace.org/display/FEDORA4x/Authentication+and+Authorization wiki page14:19
<benpennell>whikloj: if i'm following correctly, then yes. setting an end date would require amending one previously existing ldprm to add an end date. and it could be any memento since you could create a new one in the past using the Memento-Datetime parameter on your POST request to the LDPCv14:20
I would guess that you could interprete the memento-datetime as either the start or the end date. all its really guaranteeing is that at the time the memento was created, this was the state of the original resource14:22
<awoods>piechman1: it may make sense to wait for the 5.x doc space
<whikloj>benpennell: does it seem crazy to set the end-date on the last LDPRm to the datetime of next change on the source LDPRv? Or should we just wait for someone to create a new LDPRm14:23
<awoods>peichman1: it may make sense to wait for the 5.x doc space
<benpennell>whikloj: the specification leaves datetime negotiation up to the implementation. our recommendation was that for fedora the memento-datetime would be treated as the start time, and negotatied accordingly
<awoods>peichman1: unless your updates also apply to 4.x
<peichman1>awoods: I am starting with the deprecation of XACML and RBACL
<bseeger>whikloj: some of this depends on whether or not you're doing client or server managed versioning.14:24
if server managed, then everytime a POST/PUT happens a new version would be created
<whikloj>benpennell: right, my question is more around the end-date of a single LDPRm. I could create a LDPRm on 2017-09-27, then edit the document multiple times. So what is the end-date
<awoods>peichman1: once you have finished with 4.x-related updates, I will copy over to the new 5.x space.
<awoods>peichman1: Please keep me posted
<benpennell>whikloj: maintaining that datetime on every modification of the LDPRv does seem crazy to me, but I think the end time for the LDPRm should be the last modified time of the ldprv if it is the most recent ldprm
<peichman1>awoods: will do
<bseeger>whikloj: but, I think that's all fedora does is server managed … versioning… not sure really. If it allows the client to choose when something is versioned, then that's more complicated (versus it being versioned on a PUT/POSt).14:25
<benpennell>whikloj: I also don't necessarily feel like we need to store an end time (it could be computed as needed, or not included)
<bseeger>whikloj: because if you created a LDPRm and then change the LDPR, but don't version it, and then change it again and then version it… what is the end date?
<whikloj>bseeger: I think 5.0 was going to be client managed
bseeger: EXACTLY!
<bseeger>whikloj _ that's where I'd advocate for the server to allow clients to choose which LDPR's are versioned, but not when / how they are versioned.14:26
<awoods>whikloj: correct, 5.0 will continue to be client-managed versioning
<whikloj>benpennell: my concern is just that if we do provide an end-date (which maybe we shouldn't) what responsibility do we have for the accuracy of that end-date
<awoods>whikloj: I agree with benpennell, that the end date should be "discoverable"14:27
<benpennell>whikloj: the end date can be determined by the client by looking at the timemap in chronological order. if we provided one explicitly I would say it should be accurate, but i also don't think a client will make too many decisions based off the end date14:28
<bseeger>awoods, benpennell: the discoverable doesn't work in the above scenario - ie, once the LDPRv has changed, but has not been re-versioned…14:30
<whikloj>benpennell: I think you have the heart of my concern, if a user makes a version A and (as bseeger said) makes multiple edits, then makes a version B. It is actually incorrect to say that the end-date of version A is version B, but am I being to ornery
should we say that it is up to the client to handle that?
<bseeger>awoods: is 5.0 only going to be client-managed versioning?14:32
<whikloj>bseeger: yes
<awoods>bseeger: yes... same as it has been
<bseeger>whikloj: then there are things like PUT / POST on a LDPRv that may not make sense… as I think that is more for server managed versioning.
(I'm thinking of the versioning page that we put together.14:33
<benpennell>whikloj: a memento is a snapshot rather than a change history. if the client didn't consider the intervening edit to A to be worth creating a version of, I don't think it is up to a client managed versioning server to decide that version A ended when that edit was made
<whikloj>benpennell: right, so then the snapshot is valid for the date Memento-Datetime. End date seems like a useless construct14:34
<benpennell>whikloj: i'm not sure how it would be used to be honest other than being more readible for a human14:35
<whikloj>bseeger: No I think you need to turn on versioning, unless we are automatically a) making all LDPR(s) into LDPRv(s) and b) constructing LDPCv for every LDPR(s)
benpennell: yeah so maybe we just track start-date and display those
start-date == Memento-Datetime
<bseeger>whikloj - you're right - I was thinking of something else.14:36
<benpennell>whikloj: can't remember if its linked on one of the tickets, but https://wiki.duraspace.org/pages/viewpage.action?pageId=90964556 "Accept-Datetime Negotiation Example" explains the way that we were thinking datetime negotiation would work, under the assumption it was using memento-datetime as a start date
<whikloj>benpennell: yeah, I think it will. that is still correct, my blathering is really all about what the end-date is. I don't know that we need to use it for negotiation14:38
more for the timemap listing
<peichman1>awoods: I am done with my initial cleanup of the AuthNZ docs (mostly deprecation warnings and reorderings of content to emphasize our more recent practices)15:03
<awoods>peichman1++ thanks. I will make 5.x once off the current call15:04
* mohideen leaves15:08
* github-ff joins15:12
[fcrepo-specification] barmintor pushed 2 new commits to master: https://git.io/vdmyD
fcrepo-specification/master 455c16d bbpennel: Remove section defining PUT operations for LDPRv's in favor of POST to LDPCv for memento creation
fcrepo-specification/master ea57f2e Benjamin Armintor: Merge pull request #225 from bbpennel/215_remove_ldprv_put...
* github-ff leaves
* peichman1 leaves15:14
* github-ff joins
[fcrepo-specification] escowles closed pull request #232: Clarifying optionality of server-managed versioning for LDPRv (master...server-managed-versioning) https://git.io/vdfbU
* github-ff leaves
* peichman joins15:16
* mohideen joins
* mohideen leaves15:20
* mohideen1 joins
* mohideen joins15:22
* mohideen1 leaves
* mohideen leaves15:27
* github-ff joins15:35
[fcrepo-specification] barmintor pushed 2 new commits to master: https://git.io/vdmHL
fcrepo-specification/master e006bab Simeon Warner: Declare the two namespace prefixes we use
fcrepo-specification/master 70ced59 Benjamin Armintor: Merge pull request #213 from zimeon/declare-namespace-prefixes...
* github-ff leaves
<bseeger>@awoods - do you have the dataset you used for the OR presentation on the Import / Export tool?15:37
* github-ff joins15:41
[fcrepo-specification] escowles pushed 1 new commit to master: https://git.io/vdmHQ
fcrepo-specification/master 60f266c Ben Pennell: Added LDPRv PUT section for restoring a previous LDPRm (#226)...
* github-ff leaves
<rotated8>awoods: I have (finally) successfully built the repo15:56
<awoods>rotated8: nice15:57
rotated8: the easiest way to run fedora if you have the source code is:
mvn jetty:run -pl fcrepo-webapp
<rotated8>awoods: ok, got that working16:15
<awoods>rotated8: great, now you should be in a position to walk-through/verify https://wiki.duraspace.org/display/FEDORAAPI/Fedora+API+Delta+Document16:16
<rotated8>awoods: ok. thank you!16:17
<awoods>rotated8: That wiki page may not be the most transparent... please ask questions about how to test specific line-items.
<rotated8>awoods: will do.16:18
* peichman leaves16:38
* peichman joins16:39
* dbernstein leaves16:52
* dbernstein joins
* bseeger leaves17:13
* benpennell leaves17:14
* apb18_ leaves17:17
* rotated8 leaves17:28
* peichman leaves17:33
* travis-ci joins17:44
ualbertalib/fcrepo4-oaiprovider#117 (issue_14_OAI_ORE_support_v2 - 70e9038 : Jeffery Antoniuk): The build passed.
Change view : https://github.com/ualbertalib/fcrepo4-oaiprovider/compare/18ee1ebd7b05...70e9038de6a0
Build details : https://travis-ci.org/ualbertalib/fcrepo4-oaiprovider/builds/280625697
* travis-ci leaves
* whikloj leaves18:00
* dhlamb leaves18:31
* yamil_ leaves18:39
* dwilcox joins18:51
* dwilcox leaves18:56
* apb18_ joins21:25
* apb18_ leaves21:26
* awoods leaves22:58
* lsitu leaves23:03
* lsitu joins23:04
* lsitu leaves23:13
* lsitu joins23:14

Generated by Sualtam