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

Using timezone: Eastern Standard Time
* dhlamb leaves00:12
* dbernstein leaves03:04
* dwilcox joins07:39
* awoods joins08:09
* dwilcox leaves08:12
* jjtuttle leaves08:17
* dwilcox joins08:18
* jjtuttle joins08:20
* dhlamb joins08:43
* kefo joins08:53
* apb18 joins09:03
* bseeger joins09:05
dhlamb: ping
<dhlamb>bseeger, pong
<bseeger>dhlamb: morning - I was just looking at your response to kefo and thinking that the PUT _should_ overwrite the record, right?09:06
dhlamb: his 3rd step, for context
<dhlamb>bseeger, PUT should override the binary. but fcr:metadata shouldn't get wiped
bseeger, hang on, re-reading email
<bseeger>dhlamb: oooohhh, I see the distinction now. A put on the resource doesn't change what you've applied to the fcr:metadata. Okay, that makes sense.09:07
<dhlamb>bseeger, yes. PUT'ing the binary will replace the contents, but not affect metadata other than server managed triples
bseeger, i think so. the use case kefo has is a pretty common one. one we'll have in islandora, too. but we'll have to take care of it in our respective applications. if someone did something distinctly non-pcdm-ish, like putting descriptive MD right on the binary, i'd hate to wipe that on them unexpectedly.09:11
<kefo>dhlamb: You last sentence there is why I find it all rather grey.09:12
One question that I do have, after reading the responses, is whether there is any (substantial?) documentation about the fcr:metadata resource in general.09:13
Such as a list of the server-managed triples associated with fcr:metadata.09:14
<dhlamb>kefo, that's a good question. i know some basics get made, but i don't know if i've seen an exhaustive list
<kefo>There's no mention of fcr:metadata in the specification either. That seems weird, but maybe I'm missing something.
(It wouldnt be the first time or the last.)
<dhlamb>kefo, i think the spec is purposefully silent on it09:15
kefo, i think the understanding is that you could name that resource anything. it doesn't have to be fcr:metadata.
<kefo>dhlamb: Agreed, but if one of the ideas behind the spec is so that others can build their own compliant implementation, with the assumption that those varies conformant implementation's would be functionally interchangeable with each other, it seems that fcr:metadata is one of those things that exists, that people rely on, and therefore about which there should be some guidelines.09:17
<dhlamb>kefo, i'd wager that get'll wrapped up in a link header, and the client will be expected to identify and follow it09:18
kefo, if i were a gambling man
* acoburn joins09:20
<kefo>dhlamb: Yeah, that would likely be the formal way. I've enjoyed the convenience of knowing where to look for metadata related to the binary without having to fuss with Link headers.09:21
<acoburn>kefo: that may be convenient, but a client shouldn't depend on that resource being there09:23
kefo: for instance, if you have another implementation of Fedora, you can be pretty sure that the "/fcr:metadata" location won't be there
* yamil joins09:24
* peichman joins
* whikloj joins09:25
* dbernstein joins09:32
<awoods>kefo: The Fedora spec is silent on the LDP-RS that describes LDP-NRs because that is covered in the LDP spec.09:35
kefo: and as acoburn mentioned, relying on the magic suffix '/fcr:metadata' is not recommended... using the Link:describedby is recommended.09:36
<acoburn>awoods: the impl I'm working on certainly doesn't have `/fcr:metadata` URIs
<awoods>acoburn: naturally
<acoburn>awoods: but there is a LDP-RS for every LDP-NR that can be discovered via Link header09:37
awoods: as per the LDP spec
<awoods>acoburn: I think we are saying the same thing09:38
<acoburn>awoods: we are saying exactly the same thing
<awoods>acoburn: it is like a beautiful song09:39
<apb18>kefo: Also, the Fedora spec is notably silent on the *content* of server-managed triples. As written, it would be fine for the impl to create a completely empty LDP-RS describing an LDP-NR, and never update it.
<acoburn>apb18: in fact, that's pretty much what I'm doing — I don't have any concept of "server managed triples"
* osmandin joins09:40
<acoburn>apb18: all that data is pushed into HTTP headers
<apb18>I'm hoping the delta doc will highlight existing behaviour as "stuff the current impl is allowed to do, but is outside the spec and others are free to do it differently"
<acoburn>apb18: or simply removed
apb18: yes, I've got a list I've been working on09:41
<apb18>acoburn: Excellent! It'll be an important aspect to communicate, in my opinion09:43
<acoburn>apb18: it has been a very informative process for me, and has raised some interesting questions, especially around PUT-on-create09:45
<apb18>acoburn: Good to hear; is your PUT observations related to https://github.com/fcrepo/fcrepo-specification/issues/20?09:48
<acoburn>apb18: no, that's actually a separate issue09:49
apb18: it's more about the notion of containment
<apb18>"is your put observations".. oh my
acoburn: Ah, I see
<acoburn>apb18: there are good arguments on both sides for whether to add containment links09:50
apb18: e.g. say you have an LDPC at /container and you PUT a resource at /container/resource09:51
apb18: does /container include a ldp:contains triple pointing at /container/resource?
apb18: and what if the PUT is to /container/a/b/c/resource and none of the intermediate resources exist?
<apb18>Yes, exactly. I've worried about that topic too. The thing that worries me about using POST strictly for creating contained members is its non-idempotency09:52
So PUT is attractive in some ways09:53
<acoburn>apb18: I'm sort of leaning toward this type of impl pattern:
if you PUT to create a resource that is nested directly in a LDPC, a ldp:contains triple will be materialized09:54
if you PUT to create a resource that is nested in a non-container LDP-RS, the request is rejected
if you PUT to create a resource that is nested in a non-existing resource, the request is rejected09:55
apb18: at least that's what my thinking is at this moment (it may change tomorrow)
apb18: it will probably be a few months before I actually need to impl that logic, though, so I have some time to think about it09:56
apb18: another interesting question is whether it is possible to retrieve a Memento of a deleted resource09:57
apb18: my design so far would support that
apb18: but I haven't decided whether that's actually desirable or not
<apb18>acoburn: I think it would be nice for the spec to say something about PUT in relation to containment. The problem is that that the correspondence between URI path segments and resources is merely a suggested best practice.09:59
<acoburn>apb18: I agree10:00
<apb18>or at least, that's the sticking point for me... but I haven't decided if that's being too pedantic
<acoburn>apb18: my worry about creating disjoint portions of the graph is that discoverability becomes really problematic
apb18: but one could also see that as a feature
<apb18>Ha, true that one could see that as a feature10:02
* apb18 plans on diving back into spec work later in the afternoon, ponders in the meantime10:05
apb18: awoods: FYI https://github.com/trellis-ldp/trellis/wiki10:20
<awoods>acoburn: thanks10:21
* ajs6f joins10:25
<apb18>acoburn: Nice, it's a good read
<acoburn>apb18: given that much of what is described is "design" rather than "implementation", it's also more about my intention10:26
apb18: though quite a bit of this has actually already been implemented
<apb18>acoburn: Great! Out of idle curiosity, does your impl intend to skolemize blank nodes, or place constraints on the subjects of triples in an LDP-RS?10:32
<acoburn>apb18: yes, there are constraints on subjects, and I haven't figured out what to do with BNodes10:33
* github-ff joins
[fcrepo4] bseeger closed pull request #1171: Update pom.xml configuration for release (master...fcrepo-2394) https://git.io/vDlSf
* github-ff leaves
<acoburn>apb18: basically, I've designed this so that all constraint-related rules are part of a separate module, so one could, in principle, change the rules if they wanted to
* github-ff joins
[fcrepo4] bseeger pushed 1 new commit to master: https://git.io/vD4Bk
fcrepo4/master b60d4eb Andrew Woods: Add in needed sonatype repo information. (#1164) (#1171)...
* github-ff leaves
<acoburn>apb18: https://github.com/trellis-ldp/trellis-constraint-rules10:34
apb18: so by the rules implemented there, BNodes would not be allowed10:35
apb18: but I suspect that I'd skolemize them in the HTTP layer (or something like that)
<apb18>acoburn: So such constraints are policy-driven rather than technology-driven?
<acoburn>apb18: yes
apb18: I want to keep business logic out of the core implementation10:36
<apb18>acoburn: Wonderful
Apropors of nothing a fun read.
acoburn: when you talk about the max cardinality of membership triples of the "upwards" pattern being 1, is that something new that you are bringing to the table for Trellis, to keep things simple and impl-able?10:49
* travis-ci joins
fcrepo4/fcrepo4#4941 (master - b60d4eb : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/da9334686547...b60d4eb3deb0
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/199259073
* travis-ci leaves
<acoburn>ajs6f: yes, that is something new10:50
ajs6f: some of that logic is already embedded in fcrepo4, but in trellis it's made explicit
ajs6f: also, for things like acl:accessControl in the current fcrepo-module-auth-webac module, you get weird behavior with cardinality > 110:52
<kefo>The following should result in the addition/replacement of any non-managed-triples of an fcr:metadata resource, yes?10:53
curl -X PUT -H "Content-type: application/turtle" -H "Prefer: handling=lenient; received=\"minimal\"" -i --data-binary @add_title3.ttl "http://host:port/fcrepo/rest/a/binary/fcr:metadata"
<acoburn>ajs6f: i.e. you get a warning and then some nice non-deterministic behavior: https://github.com/fcrepo4/fcrepo-module-auth-webac/blob/master/src/main/java/org/fcrepo/auth/webac/WebACRolesProvider.java#L432-L434
<kefo>It does for a regular RDF resource, of course.10:54
* osmandin leaves11:16
<ajs6f>acoburn: I feel like that could be our API spec right there: " you get a warning and then some nice non-deterministic behavior"11:29
<awoods>kefo: are you seeing something different?11:38
<bseeger>awoods: thanks for closing 2394 - I didn't think to do that step when I merged it.11:48
<awoods>bseeger: np... It is all you next time ;)
<bseeger>awoods: but you close bugs so well, I wouldn't want to take that away from you. ;)11:49
<awoods>bseeger: you are too kind
<kefo>awoods: I get a 204 (expected) but my shiny triples are not present in the output.11:51
<awoods>kefo: you are saying that your new title is not added to the binary description?11:54
<kefo>awoods: That's what I'm saying. The fcr:metadata resource is not updated with the content of add_title3.ttl.11:56
<awoods>kefo: that is odd... it works for me.12:01
kefo: my steps:12:02
create a binary resource
GET its properties from /fcr:metadata
change the downloaded properties to just include a new title
PUT the updated ttl to /fcr:metadata
* dbernstein leaves
* dbernstein joins12:10
<kefo>awoods: What happens when you try this? https://gist.github.com/kefo/40ddf654ef96edce523b2559dae26c1a12:16
awoods: Looking at your steps, I'm not GETting the properties and (re-)PUTtin them. I'm using the Prefer: handling=lenient header.12:17
* awoods giving the gist a spin12:18
kefo: your script only works as expected if you use the full path to the binary resource (</fcrepo/rest/prod/uuid>) in the ttl file instead of the <> placeholder.12:32
* barmintor joins12:42
<kefo>awoods: OK...
awoods: I added a PATCH test to the gist. It sends to the 'fcr:metadata' endpoint and works as expected.12:43
awoods: It seems that a PUT to 'binary/fcr:metadata' fails to update the fcr:metadata resource when using the <> placeholder, but a PATCH to the same 'binary/fcr:metadata' endpoint using the <> placeholder succeeds.12:44
awoods: That seems inconsistent at best.
<awoods>kefo: agreed
kefo: would you mind filing a bug with your scripts included?12:45
<kefo>awoods: Sure.
awoods: I personally feel the PUT is incorrect and the PATCH is. Is that your take too?12:46
<awoods>kefo: the schizophrenic nature of /fcr:metadata (its subject is a different resource) has always been troubling. But under the circumstances, I agree that the use of <> when updating the description of a binary is the desired behavior.12:49
<barmintor>it's weird. I'm smpathetic to the argument that <> at xyz/fcr:metadata should be <xyz/fcr:metadata>12:50
it's a LDP-RS that has statements about another resource, but <> has a meaning independent of that12:51
but regardless, it's inconsistent in the behavior kefo notes12:53
<awoods>barmintor: the issue is that the LDP-RS is never referenced directly.
barmintor: meaning, all of its triples have the subject of the LDP-NR12:54
<barmintor>well, it's the context URI for the request, right?
I know, I recognize how annoying it is to humans at keyboards. I''m just saying that resolving <> to not-the-context-uri is a departure12:55
<awoods>barmintor: the choice is: what does <> mean when you are requesting against /fcr:metadata... given the fact that no triples have /fcr:metadata as a subject.12:56
* bseeger leaves
<awoods>^^ no actual choice offered12:57
<barmintor>awoods: if you say "it means the LDP-NR", then the client has to know that there's a special behavior for this LDP-RS that's different from other LDP-RS's
awoods: you drive a hard bargain!
* bseeger joins12:58
<awoods>barmintor: I am suggesting the <> means the LDP-NR when requesting against the LDP-RS in this case.
<barmintor>awoods: I know, I follow you. I am just observing that it's a departure from practice.12:59
<acoburn>awoods: to be clear, though, this behavior is not defined in the Fedora spec, correct?
awoods: personally, I'd have the subject of the LDP-RS be the LDP-RS (not the LDP-NR)13:00
<awoods>barmintor: there have been endless discussions on how to handle LDP-RSs as they relate to the auto-created LDP-RSs... and this is the best we could do. There are inherent contradictions.
<barmintor>awoods: I am sympathetic. I'm just saying, you don't *have* to use the context URI pattern, and making this change makes that pattern different for some LDP-RSs13:01
<awoods>acoburn: it is not in the spec, correct.13:03
* dbernstein leaves13:04
<barmintor>awoods: I am looking at the turtle spec; can you remind me if we advertise "@base" in our serializations?13:05
basically I am asking if there is a way we can explicate, in both directions, what the relative URI base is13:07
awoods: LDP servers must assign the default base-URI for [RFC3987] relative-URI resolution to be the HTTP Request-URI when the resource already exists, and to the URI of the created resource when the request results in the creation of a new resource.13:08
that seems to suggest the annoying answer13:09
* dwilcox leaves13:33
* ajs6f leaves13:35
* dwilcox joins13:52
* peichman leaves14:02
<awoods>barmintor: does provide some concrete guidance... but the question remains: how do we describe the LDP-NR from the auto-created LDP-RS?14:05
<acoburn>awoods: you already are via the link header "describes"14:08
<awoods>acoburn: what is the subject of the triples in the LDP-RS?
<acoburn>awoods: the LDP-RS
* peichman joins14:09
<awoods>acoburn: with the implicit understanding that the "real subject" is the LDP-NR?
<acoburn>awoods: the "real subject" is the LDP-RS, but the LDP-RS describes the LDP-NR14:10
<awoods>acoburn: I will put it on this week's tech call... this could be a simplifying move if there is general agreement.14:12
barmintor: what is your opinion ^^14:18
<kefo>awoods: Let's put it on the agenda, but if I am following this correctly, I agree with acoburn. The LDP-RS is the LDP-RS.14:19
<awoods>thanks, kefo14:20
<barmintor>awoods: I feel like is pretty clear; "real subject" is an interpretive matter. I find it useful to think of "describes" as a kind of "extends whatever you found at X", but that's ancillary
<awoods>barmintor: good to hear, thanks.14:22
* dhlamb leaves14:31
* ajs6f joins14:45
<kefo>awoods: Bug reported. I marked it as "Major" but change as you see fit. It feels somewhere between the two options. https://jira.duraspace.org/browse/FCREPO-2396
* peichman leaves15:47
* peichman joins15:54
<apb18>acoburn: I've been thinking a little bit about our earlier IRC conversation regarding the relationship between containment and PUTs that create resources.15:57
<acoburn>apb18: oh good, I am curious to know what you think
<apb18>I think it would logical for the spec to address that issue for creating members of existing containers, but remain silent for arbitrary PUTs.15:59
<acoburn>and what if /a exists and you put /a/b/c/d but then you later add /a/b and /a/b/c?16:00
<apb18>I think it would be reasonable for the spec to be silent about that.
i.e. only deal explicitly with the case where you PUT /a/b to an existing /a
<acoburn>and what do you think the spec should say about that?16:01
<apb18>*If* the server allows that PUT, then /a/b MUST be contained in /a, or something along those lines16:02
<acoburn>apb18: that makes sense to me
<apb18>Yeah. The language would need to be more precise, but I can see creating an issue and seeing what others think16:03
<apb18>One exercise I'd like to do is scour the LDP working group mailing list archives to see if this issue has come up, and why it was not dealt with in the LDP spec as published.16:06
* acoburn leaves16:32
* bseeger leaves16:36
* github-ff joins16:37
[fcrepo4] emetsger opened pull request #1172: WebApplicationExceptionMapper adds entity bodies on 304 responses (master...entity-body) https://git.io/vDBax
* github-ff leaves
* yamil leaves16:42
<ajs6f>apb18: No no no16:45
apb18: I do not like that at all.
<apb18>ajs6f: Cool, what are your thoughts?16:47
<ajs6f>apb18: PUT should create uncontained resources. (For example, multitenancy becomes just a set of un-LDP-connected regions within a server.)16:48
In fact, I would like to (I thought we did) REQUIRE support for PUT, and REQUIRE that it create uncontained resoruces.16:50
<apb18>ajs6f: Should the spec broach the topic of containment with PUT, or leave it unaddressed and up to the impl
<ajs6f>apb18: Um, is that not what I just wrote?
apb18 At the very least impls SHOULD create uncontained resources, and I would prefer that they MUST.16:51
apb18: And that they MUST support PUT.
<apb18>ah, yes. I was typing at the same time. So you're in favor of addressing containment with PUT in the spec, though with the opposite conclusion.
<ajs6f>apb18: Yep.16:52
apb18: Althoght I think barmintor might agree with you.
Can't remember
got to run, talk more tomorrow16:53
<apb18>in any case, I totally agree that it ought to be addressed at the spec level. I can see both sides to it, so some discussion would be great
* ajs6f leaves16:54
<barmintor>apb18: I haven't thought about it in a while, but I was/am anti-PUT-to-create, so the containment issue is more academic.
but I think we also had no consensus, and so punted16:55
<apb18>barmintor: Hm, so it would seem 1.4.3 in the current spec ("An implementation MUST accept HTTP PUT to create resources") ought to be revisited for lots of reasons!16:57
I have to run and pick up the kids, but if someone hasn't created an issue related to PUT before I get back in front of github, I'd be happy to create one!16:59
<barmintor>well, maybe. I have a different notion of how a spec like this should work than some of the other editors, which is generally (I think) more conditional.
* apb18 leaves
* whikloj leaves17:00
* travis-ci joins17:17
ualbertalib/fcrepo4-oaiprovider#58 (fcrepo4-oaiprovider-4.2.0_1 - a6ce95d : Piyapong Charoenwattana): The build passed.
Change view : https://github.com/ualbertalib/fcrepo4-oaiprovider/compare/fcrepo4-oaiprovider-4.2.0_1
Build details : https://travis-ci.org/ualbertalib/fcrepo4-oaiprovider/builds/199403883
* travis-ci leaves
* kefo leaves17:46
* peichman leaves18:04
* dwilcox leaves20:55
* peichman joins22:15
* dhlamb joins22:38
* peichman leaves22:42
* awoods leaves23:14

Generated by Sualtam