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

Using timezone: Eastern Standard Time
* benpennell joins08:24
* apb18 joins08:31
* dwilcox joins08:34
* harringj joins08:50
* yamil joins09:12
* westgard joins09:16
* whikloj joins09:25
* bseeger joins09:38
* lsitu joins09:48
* peichman joins09:55
* dbernstein joins10:06
<bseeger>yes, some use cases would be great — what are people doing with this currently would be helpful as well.10:07
<escowles>yeah, it's not at all clear to me if people expect changes to a resource's current ACL to apply to old versions, or not10:09
<benpennell>bseeger: see pattern 1.2 https://tools.ietf.org/html/rfc7089#page-1810:18
<bseeger>benpennel: thx10:19
<escowles>i'm free all afternoon, so any time is good for me10:21
<bseeger>okay - 1:30 - 2:3010:22
dbernstein: https://jira.duraspace.org/issues/?filter=1430210:34
<benpennell>that might be why cameling is doing a lot more indexing than I was expecting…10:49
<escowles>IIRC, this is because inbound links are created by modeshape10:50
it's definitely a complicated and squirrely part of the modeshape impl10:53
<benpennell>it would be nice to tell the difference between the two actions in the modeshape implementation
<escowles>benpennell: if you could distinguish between them at the event-generation stage, sending different kinds of messages based on that would be great10:55
<bseeger>works for me10:58
thanks apb18!10:59
<harringj>dbernstein: shall we meet up in ~10 minutes? i need a quick break :)11:00
<dbernstein>harringj: yes. sounds good.
we can meet on my uberconference line: https://www.uberconference.com/dbernstein11:01
<bseeger>[Import/Export Standup]11:09
Finished yesterday:
Reading some specs - memento rfc3230, API spec
Working on today:
Reading some specs - memento rfc3230, API Spec, Solid WebAC spec; look at how fedora does versioning and webacl
whoops — correction to above: memento is rfc708911:10
<escowles>bseeger: also, you mean "API Alignment Standup" not "Import/Export", right?11:11
<bseeger>escowles - yup! bad cut and paste. :) :)11:12
just updated the IRC template on: https://wiki.duraspace.org/display/FF/2017+API+Alignment+Sprint+0111:13
<apb18>bseeger: Thanks!11:14
* mcritchlow joins11:19
* escowles leaves11:20
* escowles joins
* peichman leaves11:47
* bseeger leaves12:06
* westgard leaves
* westgard joins12:15
* westgard leaves12:19
* lsitu leaves12:31
* lsitu joins12:32
* bseeger joins13:12
* peichman joins13:21
<bseeger>benpennell - should we use the fedora conf line?13:30
<benpennell>bseeger: yes i think that should be okay13:31
<bseeger>okay - dialing in now
LDPR == LDPRv == URI-R13:42
so you can't have <http://localhost:8080/rest/foo> ldp:contains <http://localhost:8080/rest/foo/fcr:versions>
<benpennell>"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:44
* westgard joins
* apb18 joins late13:52
* westgard1 joins14:04
* westgard1 leaves14:08
* westgard leaves14:23
<bseeger>benpennell, escowles, apb18, westgardj: I've added the three scenarios we talked about to this page: https://wiki.duraspace.org/pages/viewpage.action?pageId=9096450714:53
<benpennell>bseeger these look good! I'm guessing that in #1 LDPRCv should be LDPRv?14:57
or maybe you mean LDPCv...14:58
<bseeger>Yes - I meant LDPCv….
<apb18>bseeger: Great. Some memento terminology is confusing, "Original Resource" in memento language would simply be the resource's URI, e.g. the LDPRv's URI. http://localhost:8080/fcrepo/rest/path/to/resource14:59
<bseeger>Should I change "Original Resource" to LDPRv?
<escowles>that's probably clearer to people who have read the spec — is this doc for us, or for pointing people to in a mailing list message?15:00
<apb18>Not necessarily, I'm just trying to map in my head memento terminology onto spec terminology to see if I understand
<bseeger>escowles - good question. I think mostly for us, though I did add that comment about Ideas and use cases welcome.15:01
<escowles>maybe say "Original Resource (LDPRv)" or something like that?15:02
<apb18>I like that...15:03
<bseeger>that sounds good to me. That sort of eases folks into the spec / mementoterminology
and I meant to have a space in there, but I kind of like how that looks. It looks complicated and tough - like the spec itself. :)15:04
<apb18>bseeger: Just to follow up on something mentioned on the call. I'm a bit worried about #1, because I'm pretty sure, at least using the "snapshot versioning" in place right now in fcrepo4, that an LDPRm could have two parents. That is to say, *two* resources could have ldp:contains that point to it15:10
I was just playing around with Fedora right now. Created containers A and A/B (A ldp:contains B)15:11
then I created a version "v1" of A15:12
<escowles>apb18: if so, then the bigger issue is that the LDP spec specifically forbids that — can you write up the example on a wiki page?
<apb18>escowles: will do
<bseeger>apb18 - I just made changes at the same time you did to the azn/versioning page. I hope I didn't lose your changes.15:14
I'm done editing for now15:15
<apb18>we'll find out :) I'm still not used to how confluence handles concurrent edits now
<bseeger>yeah, me neither. :)
apb18 - I created a container and put another container in it - when I version the top container and look at that version, I see that the child container was versioned as well.15:19
This is with 4.7.4
<apb18>Yes, exactly. That, coupled with the fact that an LDPRm ldp:contains a child LDPRm is the problem15:20
<bseeger>oh, because a memento cannot contain a memento?
<apb18>so the child LDPRm is contained by both its parent LDPRm, and by its own LDPCv
<apb18>Yeah. If, for example, a parent LDPRm linked to its child LDPRv, this wouldn't be a problem15:21
<bseeger>but, what I see fedora doing is not letting me access the version of the child container directly.15:22
Ie, I can't get to /path/a/b/fcr:versions
but I can get to /path/a/fcr:versions and see that b was indeed versioned.
so maybe the the LDPR for 'b' doesn't point to it's own version?15:23
(which you would think it should…)15:25
<benpennell>yes, in fcrepo 4.7.4 the resources within the versioned tree are not associated with the original versions of them, they are instead basically new resources with new uris (/path/a/fcr:versions/version1/b for example)15:26
<apb18>It's wierd. So A's LDPRm (http://localhost:8080/rest/A/fcr:versions/v1) links to http://localhost:8080/rest/A/fcr:versions/v1/B. Which... is neither an LDPRv, nor an LDPRm?15:27
<benpennell>its just the top resource (where the request to create the new version) that is associated directly to the version
I guess http://localhost:8080/rest/A/fcr:versions/v1/B is the LDPRm, /B is what? A child of the LDPRm? I'm not sure if we would add headers to them or not15:29
<apb18>Right. So what is the LDPRm of the top resource (A) linking to via ldp:contains? Is there any terminology in any spec that can explain what http://localhost:8080/rest/A/fcr:versions/v1/B is?
IF an A LDPRm ldp:contains a B LDPRm, then we have the "two parent" problem, since we know that B's LDPCv ldp:contains all of B's LDPRMs15:30
<bseeger>what does the spec have to say about versioning a resource and it's children? (lookign now)15:31
<apb18>It says nothing
<benpennell>does LDPCv actually ldp:contain anything? I thought it had fedora:hasVersion relations to the LDPRm's?15:32
<apb18>benpennell: https://fcrepo.github.io/fcrepo-specification/#general-3
" a version container (LDPCv) must be created that contains Memento-identified resources (LDPRm) capturing time-varying representations of the associated LDPR."15:33
so it does use the word "contains"
* github-ff joins15:34
[fcrepo4] harringj opened pull request #1228: Ensures correct response codes for creating LDP-NR (master...fcrepo-2593) https://git.io/v5D09
* github-ff leaves
<bseeger>Fedora currently uses the hasVersion, but that'll go away, I think, when we make this change. Instead /a/fcr:version will point to the timemap
<benpennell>okay, that's different than the behavior of fcr:versions in fcrepo 4
timemap being the LDPCv
* github-ff joins
[fcrepo4] escowles created interaction-model (+1 new commit): https://git.io/v5DEq
fcrepo4/interaction-model 9394550 Esmé Cowles: Use Link header to determine interaction model, instead of mime type sniffing
* github-ff leaves
<bseeger>which ldp:contains the LDPRm
<bseeger>so then we need to decide what happens when someone versions an object that has children. Sounds like those childnodes would _not_ be versioned along with it's parent15:35
or should not be versioned, otherwise we end up with the 2 parent scenario15:36
* github-ff joins
[fcrepo4] escowles opened pull request #1229: Use Link header to determine interaction model, instead of mime type sniffing (master...interaction-model) https://git.io/v5DES
* github-ff leaves
<apb18>Well, I think the two-parent problem is really brought about by having an LDPRm link to another LDPRm. If an LDPRm instead linked only to LDPRv, then this problem would go away15:37
well.. hm15:38
maybe not
<bseeger>Is this a LDP thing or memento thing?
<benpennell>i'm still trying to understand, is having /A/fcr:versions/v1/B and /A/B/fcr:versions/v1 the issue?
<bseeger>I think the issue is that you can't have a memento point to another memento… ie, /a/v1 points to /b/v1 /a/v1 should point to /b/ - not it's version.15:39
split out that last part /a/v1 should point to /b/ and not it's version.15:40
<apb18>let me think about how to express it most clearly, and put it on the wiki page.
* peichman leaves15:43
<benpennell>hmm, /a/fcr:v/v1 would ldp:contain /a/fcr:v/v1/b. that instance of b would not be a memento but would be a resource contained by a memento. it would also be distinct from /a/b or /a/b/fcr:v/v1, so it seems like it avoids multiple parents15:46
* dwilcox leaves
<apb18>benpennell, What *is* /a/fcr:v/v1/b?, as described in terms of the versioning terminology in memento, or the fedora spec?15:47
<harringj>afk 15 minutes15:48
* travis-ci joins15:50
fcrepo4/fcrepo4#5114 (interaction-model - 9394550 : Esmé Cowles): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/commit/9394550f612e
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/274750469
* travis-ci leaves
<benpennell>apb18 it is a bit strange, but i guess it is just an LDPR. similar to creating a version of a website which contains multiple html files, but with 100% more triples. i'll stop trying to process this maze for a moment and wait for the example though
* westgard1 joins15:52
<apb18>Yeah, there seems to be a broader issue of parents linking to children across versions, which is somewhat distinct from the fcrepo4 behaviour of creating these "phantom" LDPRs that aren't really versions of anything.15:54
* westgard1 leaves15:56
<bseeger>What does an LDPR and a LDPRv look - for example, if a resource (LDPR) is at example.com/a/resource/here isn't that also the LDPRv, too providing it's been versioned?16:00
I'm trying to understand section - I just wonder what it is about that PUT that says "version this"16:01
just that the "Accept-Datetime" header is present?16:02
<benpennell>bseeger: maybe? I'm confused about that. Particularly because the other way to create a version is by POSTing to the LDPRv. Why have the PUT and the POST in different places?16:04
but you may be right that it is just the presence of the Accept-Datetime on the PUT16:05
oops, i meant POSTing to the LDPCv16:07
<bseeger>I think what I'm confused about is that the LDPRv I think means that it's a LDPR that has versions. Ie, it is one in the same with the LDPR. So then a PUT or POST on the LDPRv is the same as PUT or POST on the LDPR. Is that how you read the spec?16:08
* peichman joins
<benpennell>yeah, that's my reading too16:09
<escowles>i believe POSTing to the LDPCv is the expected client-managed versioning approach — the alternative is to do a PUT/PATCH on the resource and expect the server to create a version for you16:10
i do not understand the note in (that you can include an Accept-Datetime header in a PUT as per Memento 2.1.1) — Memento does not say anything about PUT requests
<benpennell>i'm now thinking that is just intended as a bonus feature on top of the normal PUT behavior for an LDPR, it just allows you to create a memento and update the object in a single request16:11
<escowles>yes, i think that's one way to read it — but i'm a little worried about fact and are verbatim copies of the GET section above, and i want to make sure that those headers (which seem very applicable to GET and somewhat hard to reconcile with PUT) are correct16:13
<benpennell>that'd be good to clarify, but the PUT section makes even less sense if you take those two sections away16:14
it seems like an okay feature, but it would be good to find out what the intention was16:15
<bseeger>yeah, it's very unclear what about the PUT actually says "make a version"
<escowles>yes, i agree — i'm going to create a spec issue asking if the intention is to have the Accept-Datetime header in a PUT trigger version creation16:16
<benpennell>its also a little weird that you would want to provide a Datetime (for use as the memento-datetime maybe?) when creating a snapshot of the current version of the resource
it is valuable to have a way to provide the Memento-Datetime somehow when creating a memento though since that is required for importing versions16:17
ah good that is present for POSTs to LDPCv16:19
<apb18>escowles: related to this thread, I've been confused by https://fcrepo.github.io/fcrepo-specification/#vary16:21
Are there actual headers Vary-Post and Vary-Put?16:22
<escowles>Yes, the response header would literally be "Vary-Post: Memento-Datetime", etc.
<apb18>Do you happen to know where Vary-Post (the header) is defined?16:23
<bseeger>(an aside) just found this in case it's helpful (I haven't read through it yet) - https://www.w3.org/blog/2016/08/memento-at-the-w3c/16:25
<apb18>escowles: Vary is defined in RFC7231, but I hadn't been able to find where the semantics of Vary-Post are defined
<escowles>apb18: i'm not sure, i'll see if i can find it
btw, the issue i created for the PUT w/Accept-Datetime is https://github.com/fcrepo/fcrepo-specification/issues/21516:26
<bseeger>thanks escowles
<apb18>escowles: Yeah, that would be great. I couldn't find anything, but that term is hard to search for.16:27
<escowles>well, the most interesting thing i've found so far is an older version of the spec that's a little more verbose: http://fedora.info/spec/2016/05/20/resource-versioning16:28
<apb18>escowles: I'm beginning to think it's a new header defined by the fedora spec.16:29
<escowles>that is surprising, but i think i agree16:30
since i can't find it anywhere else
<benpennell>"Discourage, discourage"
that's about how i feel after reading all these specs too
<bseeger>it's not simply an abbreviate saying "A POST with vary on it"?
POST with vary header; PUT with vary header?
(if that is the case, I suggest it be spelled out in more words)16:31
<apb18>bseeger: I'm not sure Vary is defined for _requests_. It's supposed to indicate that a server will return different representations based upon requests with different values in that the header16:33
i.e. RFC7240 (defines the Prefer header) says that servers that support Prefer MUST have "Vary: Prefer"
.. to indicate that responses vary depending on the incoming Prefer value16:34
<escowles>i'm pretty sure that is meant to say that a GET or HEAD to a LDPCv should include the header "Vary-PUT: Memento-Datetime" to indicate that you can use the Memento-Datetime to specify the datetime the created version should have
because normally, Vary headers apply to GET/HEAD, not PUT/POST/PATCH16:35
* westgard1 joins
<bseeger>just trying to understand this — the Memento-Datetime header is meant to be a response header, but we are using it to help a user agent create a version with a specific date?16:45
<benpennell>bseeger: looks that way, for POSTs to LDPCv at least. For PUTs to LDPRv's it is using Accept-Datetime for the same thing16:50
<bseeger>thanks benpennel
<escowles>i think Memento-Datetime is meant to be a request header on GET/HEAD to retrieve a version from a specified datetime16:51
<benpennell>escowles: hmm, for GET requests you use Accept-Datetime, and the response contains Memento-Datetime
<bseeger>the API spec has it used this way: "If an LDPCv does accept POST with a request body, it should respect a Memento-Datetime request header for the created LDPRm. Absent this header, it must use the current time."
<escowles>benpennell: sorry, you're right16:52
<bseeger>which seems different from how it's intended to be used.
gotta run, talk to you tomorrow.16:53
* bseeger leaves16:54
<benpennell>memento doesn't seem to have anything to say about how to create versions, but i agree. memento directly says in https://tools.ietf.org/html/rfc7089#section-2.1.1 that Memento-datetime is a response header and Accept-Datetime is a request header
I wonder if that might be worth creating another specification issue?
we probably want to at least be consistent between POST and PUTs about which header is used16:55
<escowles>benpennell: i think this is going to shake out of https://github.com/fcrepo/fcrepo-specification/issues/215 — do you want to comment on the usage of the header in PUT seems different from what the Memento spec says?16:56
<apb18>I updated the versioning design page with two sections at the end: https://wiki.duraspace.org/pages/viewpage.action?pageId=9096450717:06
now to pick up the kids
* apb18 leaves17:07
* github-ff joins17:24
[fcrepo4] escowles created container-constraints (+1 new commit): https://git.io/v5DPP
fcrepo4/container-constraints e67cd38 Esmé Cowles: Add Link rel=ldp:constrainedby header for Containers
* github-ff leaves
* harringj leaves
* github-ff joins17:25
[fcrepo4] escowles opened pull request #1230: Add Link rel=ldp:constrainedby header for Containers (master...container-constraints) https://git.io/v5DPH
* github-ff leaves
* benpennell leaves17:32
* travis-ci joins17:33
fcrepo4/fcrepo4#5116 (container-constraints - e67cd38 : Esmé Cowles): The build has errored.
Change view : https://github.com/fcrepo4/fcrepo4/commit/e67cd38f5835
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/274792589
* travis-ci leaves
* yamil leaves
* whikloj leaves18:03
* mcritchlow leaves18:06
* peichman leaves18:16
* github-ff joins18:52
[fcrepo-specification] acoburn closed pull request #209: Fix typo in JSON-LD context (master...typo) https://git.io/v5VEm
* github-ff leaves
* westgard1 leaves18:58
* benpennell joins19:56
* benpennell leaves20:09
* benpennell joins20:12
* benpennell leaves20:35
* westgard1 joins20:43
* westgard1 leaves20:47
* escowles_ joins21:29
* escowles leaves21:32
* westgard1 joins21:34
* westgard1 leaves22:43
* benpennell joins23:00
* bryjbrown joins23:14
* westgard1 joins23:18
* benpennell leaves23:32
* westgard1 leaves23:38
* westgard1 joins
* bryjbrown leaves23:40
* bryjbrown joins00:09
* lsitu leaves00:13

Generated by Sualtam