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

Using timezone: Eastern Standard Time
* dbernstein leaves02:58
* dwilcox joins07:20
* dwilcox leaves07:36
* dwilcox joins07:43
* benpennell joins07:58
* benpennell leaves08:01
* benpennell joins
* dhlamb joins08:04
* benpennell leaves08:09
* apb18 joins08:29
* manez leaves08:31
* manez joins08:33
* awoods joins08:47
* manez leaves09:02
* manez joins09:05
* whikloj joins09:11
* peichman joins09:16
* yamil_ joins09:18
<whikloj>[API Alignment Standup]09:40
Finished yesterday:
- Some work on internal static URI pattern (FCREPO-2638)
- Some PR review
Working on today:
- Moving to create LDPRm interface/class (FCREPO-2643)
- Then maybe back to URI pattern
- Other duties as assigned
Blockers:
- none
<awoods>whikloj: would you have time to provide an additional review for: https://jira.duraspace.org/browse/FCREPO-2639 ?09:46
<peichman>[API Alignment Standup]
Finished yesterday:
Working on today:
{ticket titles and associated JIRA links}
{and/or brief textual description}
Blockers:
{brief textual description}
[API Alignment Standup]09:47
Finished yesterday:
N/A (attending the DC FUG)
Working on today:
adding fedora:VersionedResource to the ontology (https://jira.duraspace.org/browse/FCREPO-2640)
Blockers:
none
(apologies for the double post, my IRC client hates me)
* benpennell joins09:48
<awoods>whikloj: there is a whole list of LDPRm tickets... if you would be interested in: 1. targeting them, 2. helping farm out LDPRm tasks to others.
* benpennell leaves
* benpennell1 joins09:49
<awoods>peichman: no worries ;)
* yinlin joins09:51
[API Alignment Standup]09:53
Finished yesterday:
Finish https://jira.duraspace.org/browse/FCREPO-2641
Working on today:09:54
https://jira.duraspace.org/browse/FCREPO-2606
Blockers:
None, except tree meetings today
three
<whikloj>awoods: I did have a look at FCREPO-2369 this morning, just the one comment09:55
https://github.com/fcrepo4/fcrepo4/pull/1252#discussion_r142933138
<awoods>[API Alignment Standup]
Finished yesterday:
- Reviewed: Add support for Want-Digest header to external content
** https://jira.duraspace.org/browse/FCREPO-2587
- Reviewed: Create LDPCv resource
** https://jira.duraspace.org/browse/FCREPO-2639
Working on today:
- More reviews
- 5 meetings :(
Blockers:
- None
<whikloj>awoods: I am looking at the initial LDPRm ticket, to get a Memento class ready. But now I think that might be a bad idea, as a Memento could be either a LDP-RS or LDP-NR.09:57
awoods: So unless we want the Memento to be a pointer to an actual copy of the resource, maybe the LDPRm is just some LDPR without special designation? Just an additional rdf:type and snapshot datetime property09:58
<awoods>whikloj: I need to jump into my first meeting...09:59
whikloj: Would you be interested in taking a step back and thinking through a design from REST API down to model classes? It seems that we need a defined plan.
<peichman>is the fedora: namespace changing from "http://fedora.info/definitions/v4/repository#" to "http://fedora.info/definitions/fcrepo#"? I noticed in https://jira.duraspace.org/browse/FCREPO-2640 and the spec it uses the latter, but all the existing classes and properties in the fcrepo4/ontology use the former.
* mohideen joins
<whikloj>awoods: I'll give that a try10:00
peichman: fedora is internal to our impl, fcrepo is api specific
<awoods>peichman: no. Let me find my answer to dbernstein from yesterday.
<peichman>awoods, whikloj: okay
<whikloj>peichman: rather "repository" is the modeshape impl, and "fcrepo" is from the API spec
<yinlin>awoods: About https://jira.duraspace.org/browse/FCREPO-2641. Do you want me to change "@deprecated As of release 5.0.0" to "@deprecated" only?10:01
<awoods>peichman: http://irclogs.fcrepo.org/2017-10-04.html @14:13
<peichman>awoods: got it10:02
awoods: should the new fcrepo API-related terms get their own ontology file, distinct from repository.rdf?
* awoods on a call
peichman: Fedora-specific terms should go in the existing ontology... then we will release it with a bumped version.10:03
yinlin: yes
<yinlin>awoods: ok. thx10:04
* rotated8 joins10:11
[API Alignment Standup]10:12
Finished yesterday:
* lsitu joins
<rotated8> More CRUD testing
Clarified scope of testing
Working on today:
Putting results on the wiki
(And more testing)10:13
Blockers:
None
<awoods>rotated8++10:14
<lsitu>[API Alignment Standup]10:25
Finished yesterday:
Create LDPCv resource: https://jira.duraspace.org/browse/FCREPO-2639
Worked on Example credentials to be URIs: https://jira.duraspace.org/browse/FCREPO-2642. Explore the ways to escape URI in the user configuration file jetty-users.properties. It seems like that there is an issue with escapeing character colon (:), which is used as a delimiter in jetty-users.properties.
Working on today:
Work on walk around solution for Example credentials to be URIs: https://jira.duraspace.org/browse/FCREPO-2642?
Delete a LDPCv: https://jira.duraspace.org/browse/FCREPO-262110:26
Blockers:
Configure jetty-users.properties to escape special character colon (:) in the example user URI.
<awoods>lsitu: would you please work with whikloj on the design of timegate/memento/REST-interaction?10:28
<lsitu>awoods: Sure.10:30
* apb18 leaves10:50
<whikloj>lsitu: I'm trying to figure out how or if we should indicate that a Memento is a Memento (like with another RDF type) or if we just count all children of a LDPCv MUST be Mementos
lsitu: Also, some other questions I've got. https://wiki.duraspace.org/display/FF/Versioning+-+Authorization+Design#Versioning-AuthorizationDesign-RESTInteractionquestions10:51
<lsitu>whikloj: What else could be placed inside the LDPCv other than the Memento, something like a global WebAC?10:56
<whikloj>lsitu: Not sure, I guess the only things would be Mementos and (if applicable) a WebAC that covers all the Mementos.10:57
<awoods>whikloj/lsitu: hmm... I would assume that only mementos could exist in the LDPCv10:58
* yinlin leaves10:59
<whikloj>awoods: So the WebAC for Mementos reside where? Also I think we said there was a WebAC for the LDPCv to and one for the LDPRv. So 3 possible WebACs
* dbernstein joins11:00
<whikloj>awoods/lsitu: We can put our WebACs anywhere normally. So a confusing interaction is how you add a WebAC to Mementos, because you can't change them. That linking seems to needs to be deterministic11:01
oops
* whikloj calling in
<dbernstein>here
<benpennell1>i'm here
* ylchen joins
* apb18 joins
<awoods>whikloj: I believe one ACL will rule all mementos in the LDPCv
https://wiki.duraspace.org/display/FF/2017-10-05+-+Fedora+Tech+Meeting11:02
<whikloj>awoods: right but how do you add that ACL, that is what I can't figure out
<peichman>awoods: I'm here, but my mic is acting up11:03
<whikloj>peichman++11:05
<apb18>Update the ACL to the LDPCv to disable writes?11:10
Yeah, it seems to me that the link header would be retained11:14
<peichman>versionable = has timemap11:15
not neccessarily that you can create versions
* rotated8 leaves11:16
<apb18>Presumably the acl would also apply for auto-versions? behaves "as if that user interacted with the LDPCv"?
* github-ff joins11:18
[fcrepo4] yinlinchen opened pull request #1255: Deprecate MOVE and COPY. (4.7-maintenance...4.7-FCREPO-2641) https://git.io/vdRfS
* github-ff leaves
<peichman>we have the user delegation ability in the webac module
fedoraAdmin can act as a non-superuser11:19
<apb18>whikloj: that (the server as a user) could make sense too11:20
for audit purposes, it might be nice to distinguish11:21
(i.e. fedoraAdmin from system)11:22
<whikloj>apb18: good point
<peichman>read-only LDPCv++
<apb18>it's a header, not property - right?11:25
i.e. not necessarily a triple
<awoods>apb18:yes
<dbernstein>oh - good to know.
VersionableResource NOT appear as a triple on the resource?11:29
<whikloj>dbernstein: correct
dbernstein: https://wiki.duraspace.org/display/FF/Versioning+-+Authorization+Design#Versioning-AuthorizationDesign-CheckifaresourceisversionableanddiscovertheTimeMap/LDPCv11:30
<dbernstein>or are y’all saying it MUST appear as a header and if it appears as a triple as well, no problem.
okay - thanks whikloj.
<whikloj>dbernstein: I would say it can't appear as a triple as it is not part of the resource. But others might feel differently11:31
<peichman>forward++
<apb18>forward, put it!
<whikloj>move along11:32
<apb18>I'd like to understand the use case. I think always-on webac + permissive root acl should be sufficient?11:34
<whikloj>apb18: I think webac ON forces AuthN11:35
<peichman>apb18: what whikloj said
<apb18>It would be necessary to use a web.xml that disables authn11:37
(plus a component that has a "assume a default user" if none is provided)11:38
<whikloj>apb18: right which means you get away from a "simple" deploy time switch
<apb18>I suppose so :\
authn makes things 3x harder
* bseeger joins11:40
<peichman>can you provide a different web.xml at deploy time? even with an unexploded WAR?11:45
<awoods>dbernstein^^11:48
<apb18> peichman: Yes, you can provide a separate web.xml, depends on the servlet container on exacely how to do it11:49
<peichman>apb18: I had trouble finding a way to do it in Tomcat11:51
<apb18>whikloj: fedora 4 ought to be able to be deployed on the internet. Can it not be used to put open linked data on the web?11:52
<whikloj>apb18: ok I think I'm starting to understand this, we need somewhere in the WebAC code to have a default case (if system property FOO is enabled) then user principal "Anonymous" is assumed11:57
is that correct?
<apb18>I added a comment on lsitu's ticket, URIs are not compatible with basic auth
i.e. they're forbidden by the RFC because of colon11:58
<lsitu>apb18 ++
<peichman>is there an escape mecahnism in basic auth?11:59
<apb18>https://jira.duraspace.org/browse/FCREPO-264212:00
<whikloj>apb18++
* ylchen leaves
<apb18>whikloj, Yes exacely. Opt-in to enable a Default case anonymous
I'd be OK hosting12:01
<awoods>apb18++
<whikloj>apb18++ # For all things
* ylchen joins12:02
* ylchen leaves12:03
* ylchen joins
<mohideen>whikloj: which issues are available for me to grab?
<whikloj>mohideen: currently we have a couple questions that need answers, lsitu and I are looking in. You are more than welcome to join.12:05
mohideen/lsitu: I've been writing my thoughts down here:12:06
https://wiki.duraspace.org/display/FF/Versioning+-+Authorization+Design#Versioning-AuthorizationDesign-RESTInteractionquestions
<mohideen>whikloj: sure
<peichman>quoth RFC 7617: "User-ids containing colons cannot be encoded in user-pass strings." https://tools.ietf.org/html/rfc7617#page-5
<bseeger>awoods, abp18, dwilcox: I'm here sort of, but my hangouts session just died…12:07
<whikloj>mohideen/lsitu: Please feel free to alter/edit/comment on them if you have ideas, or if you feel I might be over-thinking any of this
peichman: Which mean URIs and Basic Auth are incompatible...right?12:08
* benpennell1 leaves12:19
* rotated8 joins12:27
<lsitu>whikloj: WebAC could appear in both Memento and LDPCv, right? That is, both Memento and LDPCv could have their own WebAC for access control. It looks like it is missing from https://wiki.duraspace.org/display/FF/Versioning+-+Authorization+Design#Versioning-AuthorizationDesign-RESTInteractionquestions .12:37
* lsitu leaves12:42
* lsitu joins
whikloj: I am wondering how WebAC looks like for a Memento.12:47
* mcritchlow joins12:50
<whikloj>lsitu: oh yeah....you're right I haven't included that at all.12:53
* dhlamb leaves
<whikloj>lsitu: For a WebAC for Memento. I think it defines who can see the past versions of that resource. But that is all because they are already read-only12:55
lsitu: I'll add what I think the WebAC interaction is for both LDPCv and LDPRm to that section.12:56
<lsitu>whikloj ++
<whikloj>lsitu++ # thanks for pointing that out.12:57
<lsitu>whikloj: https://github.com/fcrepo4/fcrepo4/pull/1252#pullrequestreview-67368534?13:01
* bseeger1 joins13:03
<whikloj>lsitu: sorry, lost that in the shuffle.
<lsitu>whikjol: No problem.13:04
* bseeger leaves13:05
* github-ff joins
[fcrepo4] whikloj pushed 1 new commit to memento-versioning: https://git.io/vdRGb
fcrepo4/memento-versioning e7028eb lsitu: Create LDPCv resource for TimeMap. (#1252)...
* github-ff leaves
<peichman>whikloj: yep, no URIs for user ids in Basic Auth
<whikloj>peichman: as apb18 said earlier I'd be interested in how the SOLID folks are doing this.13:06
<peichman>whikloj: me too13:07
<apb18>https://github.com/solid/solid-platform#servers13:10
* ylchen leaves
<apb18>I've looked at 'gold' before (a golang implementation of LDP for SOLID), but it has been a while.13:11
If I remember correctly, it was un-authenticated out of the box?
<whikloj>So in effect, possibly they haven't dealt with this13:12
<apb18>Dunno. I think they align with WebID-TLS, but it has some sort of un-authenticated mode for demonstration purposes
hm, they have a Dockerfile..13:13
* benpennell joins13:18
* travis-ci joins13:21
fcrepo4/fcrepo4#5209 (memento-versioning - e7028eb : lsitu): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/d09d92d57f8c...e7028eb97051
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/283797501
* travis-ci leaves
<apb18>whikloj: LOL, 'gold' some sort of ssl cert auth out of the box now. Can't really figure out how to get curl to play nice with it.13:33
<whikloj>apb18: hahaha
* apb18 backs away slowly and seeks lunch13:34
<lsitu>whikloj: I just looking at ticket https://jira.duraspace.org/browse/FCREPO-2623(Support HEAD / GET on LDPCv). It looks like it depends on https://jira.duraspace.org/browse/FCREPO-2643 as well since we need to generating the Memento list in the Timpmap.13:37
<whikloj>lsitu: right, can you link it?13:38
* ylchen joins13:40
<lsitu>whikloj: I tried to link it twice but it’s in different format as address link so I deleted it.13:41
* apb18 leaves13:42
<lsitu>whikloj: I’ve linked it. I think I didn’t choose the issue type previously that’s why it’s showing up differently.13:45
<whikloj>lsitu++
* github-ff joins
[ontology] peichman-umd opened pull request #44: Added fcrepo:VersionedResource to ontology. (master...FCREPO-2640) https://git.io/vdRl8
* github-ff leaves
* ylchen leaves13:47
* ylchen joins13:48
<peichman>whikloj, apb18: for future implementation of URIs in HTTP Basic Auth, how perverse would it be to URI percent encode the URI user id before concatenation with the password? e.g. base64("http%3A//example.com/username:secret")13:49
apb18: if you are using curl on Mac OS X and trying to get SSL client cert auth to work, the short answer is it doesn't
<mohideen>Does anyone know where the memento ontology terms are defined? I see the waybackmachine project use these: observedOver Period Memento mementoFor end start TimeGate OriginalResource TimeBundle TimeMap (Prefixed with: http://www.mementoweb.org/terms/tb/)
<peichman>apb18: Mac broke it (silently!) when they switched from OpenSSL to their own proprietary SSL libs13:50
<whikloj>mohideen: they might not have a published ontology
<mohideen>whikloj: thanks13:51
<peichman>apb18: https://curl.haxx.se/mail/archive-2013-10/0036.html
* benpennell leaves
* ylchen leaves13:52
* ylchen joins13:53
* bseeger1 leaves13:54
<whikloj>mohideen: Which ontology terms are you looking for? They only define two HTTP Headers and no ontologies...I think13:55
* bseeger joins
* dhlamb joins13:57
* ylchen leaves
<mohideen>whikloj: I was looking for the ontology prefix for the rdf type of the Memento.
<whikloj>mohideen: I don't know if they defined an RDF type of Memento.13:58
<awoods>mohideen/whikloj: nope, no RDF type or any Memento ontology that I have ever seen14:01
* bryjbrown joins14:02
<whikloj>lsitu: I added some WebAC stuff as I think it might work and I'll draw your attention to "(GET/HEAD w Accept-Datetime: header) → LDPRv" we check 3 ACLs to get the result.14:20
https://wiki.duraspace.org/display/FF/Versioning+-+Authorization+Design
not sure if that is the best way
<bseeger>whikloj, mohideen: fyi — https://groups.google.com/forum/#!topic/memento-dev/xNHUXDxPxaQ14:22
I asked the memento list about ontologies… apparently no one has done this (yet)
<whikloj>bseeger: yeah I saw your email there
<mohideen>bseeger++14:23
* apb18 joins14:29
* mohideen leaves
<lsitu>whikloj: Thanks. I see it there now.14:32
<whikloj>What is the userid and password for the WebAC in 5.0.0?14:41
* ylchen joins15:01
* ylchen leaves15:02
* benpennell joins15:06
* mohideen joins15:14
<apb18>yeech. SOLID's 'gold' is almost unusable, at least from the perspective of someone used to Fedora. I figured out how to run it without TLS auth, so it allows anonymous access. It's totally weird, though. For example, it looks like you need to use PUT to create binaries...15:22
<whikloj>weird15:24
* benpennell leaves
<apb18>anyway, I'm pretty sure the SOLID people do not use basic auth. They seem firmly aligned with WebID-TLS.15:31
<dbernstein>awoods or lsitu or anyone interested: I’m running into an issue with my integration test for enabling versioning on a binary resource. My code works for non binary nodes.15:35
Here’s what I’m seeing: “javax.jcr.nodetype.ConstraintViolationException: Unable to add child 'TimeMap' with primary type 'nt:folder' to parent at /testxxx14 with primary type 'nt:file' and mixins '{fedora:NonRdfSourceDescription,fedora:Resource}' in workspace 'default' of repository 'repo' because:
- child's name 'TimeMap' does not satisfy parent's child definition: nt:file/jcr:content (required primary types = [nt:base])”
<awoods>dbernstein: I'm on a call15:36
<dbernstein>Can anyone help me decode this error. I’m having trouble understanding the root issue.
<apb18>dbernstein: I know little about Modeshape, but it looks like binaries are nt:file, and it doesn't like it to have nt:folder children15:37
<dbernstein>The thing is I’m trying to add the timemap to the binary node description.15:38
<apb18>Unfortunately, I'm not sure what the solution would be. i.e. interpreting the " does not satisfy parent's child definition" part
<dbernstein>I suspect there was some magic involved in nesting /rest/item1234/fcr:metada under the binary /rest/item123415:39
* benpennell joins15:40
<lsitu>dbernsterin: The error showing that you are trying to add nt:folder(TimeMap) to nt:file. Should we add TiMap to its parent folder?
<whikloj>dbernstein: what about the fcr:metadata node, can you operate there for Binaries?
<lsitu>dbernsterin: We should have an nt:folder created before adding the file. Right?15:42
<dbernstein>I was attempting to operate on resource.getDescription().findOrCreateTimeMap()15:43
I’m not sure I understand modeshape well enough to answer your question lsitu.15:44
<whikloj>dbernstein: that seems like it should be correct. resource.getDescription() should return the LDP-RS attached to the binary15:46
<dbernstein>right - that was my thinking too.
The line where the failure is occurring is FedoraResourceImpl.java:379: ldpcvNode = findOrCreateChild(getNode(), LDPCV_TIME_MAP, NT_FOLDER);15:48
I suppose this makes sense. You shouldn’t be able to create a child under fcr:metadata.15:49
<whikloj>dbernstein: yeah, can you see what the difference is between the results of the getNode() call for FedoraBinary versus FedoraResource
dbernstein: why not?
<dbernstein>getNode()? It doesn’t appear that getNode() is overridden in FedoraBinaryImpl.java15:51
Isn’t fcr:metadata a file node?15:52
<whikloj>no15:54
<dbernstein>oh - I see - you’re talking about FedoraBinaryImpl.getDescription()
<whikloj>dbernstein: yeah, the description is a NonRdfSourceDescriptionImpl15:55
which is
[fedora:NonRdfSourceDescription] > fedora:Resource mixin
Maybe we need alter that type... lsitu can you see why that type won't allow a child?15:56
<dbernstein>So the fcr:metadata is the parent of the binary resource ? ie the jcr representation is opposite of what is appears to be from the path - ie /mytime/fcr:metadata?15:57
<lsitu>whikloj: I see an issue with binary. I seems like weshould create a TimeMap for each.
<whikloj>lsitu: a timemap for NonRdf and Rdf and keep them separate?15:58
* benpennell leaves16:00
<dbernstein>Since this may be a separate issue to deal with - I propose the following: I will @Ignore the failing integration test and create a new jira to address this bug.
<whikloj>dbernstein: so the RDFSource stuff works, but the Binary is not correct?16:01
<dbernstein>that’s right.
Otherwise, I’m ready to issue the PR.
on fcrepo-2624
<whikloj>dbernstein: sounds fine to me
<dbernstein>okay. I’ll make a note of the ignored failing integration test in the jira.16:02
<whikloj>dbernstein++
<lsitu>whikloj: It’ll be a little complcate. Suppose we have several binary created in the root, how are we going to keek versions for each file along with its technical metadata?16:06
<whikloj>lsitu: how are the Binary and the description linked? It appears they might be created beside each other?16:07
* benpennell joins16:09
<lsitu>whikloj: The problem I see is we’ll have multiple versions of those files (technical metadata and binary content) mix in the same TimeMap if we don’t seperate them.16:13
<whikloj>lsitu: right, but we can set the same datetime property on both the binary and metadata, then we will be able to grab them both.16:14
lsitu: or perhaps we look at having NonRdfSource's inside the fcr:metadata Container and mimic that structure inside the LDPCv?16:15
* yinlin joins16:24
* yinlin leaves16:27
<lsitu>whikloj: Do you mean create a fcr:metadata Container inside a TimeMap or the resource container? But having all NonRdfSource's inside the fcr:metadata container might not solve the mix binary resources versions issue.16:31
<whikloj>lsitu: When I create a Container A, and then create a Binary B inside A (A/B). Where does the metadata container C get built in Modeshape? (A/C)??16:32
* bseeger leaves16:36
<lsitu>whikloj: I was under the wrong image that there is a folder for binary. But it looks like both the properties and the bianry content are in the same node. And the binary content is just a property jcr:data that binds to the binary node.16:42
<whikloj>lsitu: ahhhhh ok, so we have a problem there.
<dbernstein>my belated standup report: sorry16:43
[API Alignment Standup]
Finished yesterday:
Resolve remaining conflicts on https://jira.duraspace.org/browse/FCREPO-2586
Working on today:
https://jira.duraspace.org/browse/FCREPO-2624:
Enable versioning on new LDPR
https://jira.duraspace.org/browse/FCREPO-2625
Enable versioning on existing LDPR.
Resolve remaining conflicts on outstanding sprint 1 PRs.
Blockers:
None
* github-ff joins16:47
[fcrepo4] dbernstein opened pull request #1256: Enable Versioning on a new LDPR (memento-versioning...fcrepo-2624) https://git.io/vdR1S
* github-ff leaves
<mohideen>whikloj/lsitu: For clarification, the problem is that the NonRdfSourceDescription and the binary file is represented by a single JCR node of type nt:file that cannot have child nodes?
<whikloj>mohideen: that is my understanding yes.
So...this Fedora 5.0.0 should we move the metadata or figure out a new place to put the LDPCv?16:48
* rotated8 leaves16:49
<dbernstein>By the way - I”ve added https://jira.duraspace.org/browse/FCREPO-264416:50
* bryjbrown_ joins16:51
<apb18>Just out of curiosity, what is being done for ACLs, i.e. if a binary has its own acl?
.. and could LDPCv's use the same pattern?16:53
<dbernstein>Can we make the NonRdfSourceDescription an nt:folder and have the binary and ldpcv live under it as children?
* bryjbrown leaves16:54
<mohideen>whikloj/dbernstein: I was thinking of the same approach.
<whikloj>apb18: ACLs are placed where ever you want in the repo, and follows the acl:accessControl triple. Or the ACL of a parent
mohideen/dbernstein: That is what I was wondering about since this is 5.0.0. It would be a large change.16:55
<lsitu>whikloj: It looks like it’ll be the same issue if using a new place to put the LDPCv. So it looks like we could consider create one folder for each binary under TimeMap. But placing the ACL for binaries (one for each) is still an issue though.16:57
<whikloj>lsitu: We are not storing an ACL per Memento, I understood the plan to be a single ACL that controls access to all Mementos.16:58
<awoods>Since all of the mementos have the same ACL...16:59
Do we need to create an ACL for each?
<mohideen>lsitu: I agree that we need to create a nt:folder containing the metadata which would in turn contain the nt:file for each memento.17:00
<awoods>I was thinking that the TimeMap would have an ACL that has a policy defined for mementos.
<apb18>https://fcrepo.github.io/fcrepo-specification/#link-rel-acl
<awoods>And by using the "look at my parent" algorithm, the memento policy on the TimeMap would apply to the mementos.17:01
<apb18>.. suggests that they MUST at least have an acl link header?
<awoods>apb18: agreed. But that does not mean it needs to point to a resource that is nested under each memento.17:02
<apb18>Correct.
<awoods>apb18: for mementos, the acl link header could point to the ACL of the TimeMap
<whikloj>awoods: that's is fine except that we will allow Read/Write on the LDPCv but you can't Write to a LDPRm
<mohideen>awoods: Yes, we said we will have single acl for all the mementos, but I guess it cannot be same as the acl of the TimeMap / LDPCv17:03
<awoods>whikloj: right, it requires a policy specific to mementos (accessToClass)
<apb18>but... going back to discussion on "where to put LDPCvs", any resource MUST have an acl rel. What does _that_ point to? I'm guessing it'd follow the same implementation pattern as for LDPCvs.
<whikloj>awoods: So are we using hash Uris in our ACLs to define what part of the RDF is for the LDPCv and what is for the LDPRm?
* bryjbrown__ joins17:04
<whikloj>apb18: yeah, that kinda seems crazy. It now means that before you get see a resource, we have to find the correct ACL by possibly traversing the tree to the root and return that URI as a header17:05
<awoods>whikloj: We could hash-uris. The point is that ACLs can include multiple policies.
* yamil_ leaves
<awoods>whikloj: actually, the discussion has been that there is a location relative to a resource that is where the default ACL for that resource will live... it may not already exist.17:06
in other words, Link:acl can point to non-existent resources
<apb18>whikloj: Crazy, perhaps, but as awoods says, it'd be a 404 if it doesn't exist; a user can PUT to it to create such an ACL
.. and would _that_ follow the same implementation pattern as LDPCvs17:07
<whikloj>awoods: right but if there is an ACL up the tree that acts on the resource I would assume that you must return that URI and not some other one.
* bryjbrown_ leaves
<apb18>i..e if we're considering refactoring so that LDPCvs can be children of some sort of NonRDFSource node, would the ACL also be a child of that same node?
.. and the link header point to its path?
<whikloj>awoods/apb18: So I create A and make an ACL inside it. Then I create A/B, B should be controlled by the ACL on A. But viewing B would say the ACL is B/acl (for example)?17:08
<apb18>B's acl would be empty
<whikloj>apb18: right and not the actual ACL controlling B
which you'd never know
<apb18>You know it's not controlling B by discovering it's a 40417:09
.. and you can PUT a policy there if you want one for B
ACL policy enforcement would use the "find the parent algorithm" as usual. "no acl for B, now look at the parent.."
There's a spec issue that plays out that scenario17:10
unfortunately, I need to pick up the kids. Maybe awoods can fifnd it and link to the conversatiojn?
* awoods looking17:11
<whikloj>That seems wrong. Yes there is an ACL, but you can't find it. So create a new one.
<apb18>well, there is no acl for B
it is controlled by a policy that goes "if no acl for B, start looking at parents"
so a 404 of B's acl resource shows that there is no local ACL for B17:12
if B had an ACL, then it overrides anything from the parents
you'd PUT to that URI if you wanted to give B one
anyway. kids
have a good evening!
<whikloj>apb18: cheers
<awoods>https://github.com/fcrepo/fcrepo-specification/pull/214
<apb18>soty for brevity
* apb18 leaves17:13
<awoods>This one is better: https://github.com/fcrepo/fcrepo-specification/issues/176
* bryjbrown__ leaves17:16
<whikloj>So essentially if you GET a resource, it has a Link header type="acl". If that is a 404, then if you want to know what permissions are allowed you need to traverse the tree as the client checking each ACL.17:19
<awoods>whikloj: rather, I would expect that a client would make a request on the resource, and the Link:acl will tell them which ACL as applied.17:23
whikloj: The response when a resource is created will include a Link:acl header will point at a relative resource that may not exist.17:24
<whikloj>awoods: Right but after that when viewing a resource we may have to traverse the tree to find the correct ACL, so we can return the correct Link:acl, yes?
<awoods>whikloj: "we" being the server, yes.17:25
<whikloj>awoods: yes the server
<awoods>whikloj: the server, yes
<whikloj>awoods: I am concerned about performance in that situation
<awoods>whikloj: hmm... that is the current situation, no?17:26
<whikloj>awoods: Hmmm, yeah I guess so.17:27
awoods: But what we don't do is #2 under the SOLID ACL Inheritance
#2. Otherwise, look for authorizations to inherit from the ACL of the document's container. If those are found, stop here.
<awoods>whikloj: not that that should alleviate concerns.
whikloj: ??, that is simply saying "walk up the container tree"17:28
<whikloj>awoods: I don't think so, that starts at step #3
awoods: https://github.com/solid/web-access-control-spec#acl-inheritance-algorithm
<awoods>#1: look are resource's acl17:29
#2 look at resource's container's acl
#3: look at resource's container's container's acl
<whikloj>awoods: ok, if thats it then good
<awoods>whikloj: that is my reading17:30
whikloj: what is another interpretation?
<whikloj>awoods: the wording was unclear, the use of the terms document and container both for "nodes" in the tree
awoods: I didn't have one, it just seemed like our current process was #1 -> #3 -> #4 -> #5. I guess the wording just confused me17:32
<awoods>whikloj: Maybe my interpretation is biased
whikloj: however, I am not sure of an alternate interpretation of #217:33
<whikloj>awoods: If you say it is what we are doing, that is good by me
<awoods>whikloj: can we avoid creating acls for each memento?17:34
<whikloj>awoods: oh yes, I was never suggesting that. In my mind the ACL is for viewing the mementos because they are immutable anyways.17:35
<mohideen>whikloj/awoods: Considering node A has acl x and contains B, C. Say, B and C are mementos and they have a specific rdf:type, then acl x can define policies specific to A and then separate policies for B and C using accessToClass targetting the rdf:type of B and C, right?
<awoods>mohideen: correct17:36
<whikloj>mohideen/awoods: Is acl:accessToClass not being deprecated? It is not mentioned in the SOLID spec.
<awoods>whikloj: https://github.com/fcrepo/fcrepo-specification/issues/165#issuecomment-33067812617:37
<whikloj>awoods: yeah just found that issue, reading17:38
<awoods>whikloj: may as well skip to the bottom
<whikloj>awoods: ok, so accessToClass is a MUST17:40
<awoods>indeed
whikloj: I think we still have the issue of where to create TimeMaps for Binary resources17:43
<whikloj>awoods: yes, yes we do.17:44
<awoods>whikloj: It would be nice if the same approach worked for containers and binaries
<whikloj>awoods: So do we want Binaries now to be a Container (fcr:metadata) with a Binary inside? The the LDPCv can also go inside the Container?17:45
<awoods>whikloj: I would be a little nervous about refactoring our approach to binaries and their descriptions... bugs
<whikloj>awoods: yeah, but otherwise we have to stick them outside the actual Binary and (I guess) do some sort of internal linking. Which could lead to the same orphan versions Modeshape created.17:46
<awoods>whikloj: that is certainly one approach... which we would want to view with great caution
whikloj: agreed
:(
<whikloj>no easy solutions to that one.17:47
<awoods>whikloj: we could create an experimental branch for turning fcr:metadata into a container, that contains an nt:file node for the binary
<whikloj>awoods: yeah, fork the current memento-versioning. Maybe we should look at merging dbernstein's work on Containers first, then fork17:48
<awoods>whikloj: I need to do some reviews
<whikloj>awoods++17:49
* github-ff joins17:55
[fcrepo4] awoods closed pull request #1255: Deprecate MOVE and COPY. (4.7-maintenance...4.7-FCREPO-2641) https://git.io/vdRfS
* github-ff leaves
* github-ff joins
[fcrepo4] awoods closed pull request #1254: Deprecate MOVE and COPY. (master...FCREPO-2641) https://git.io/vdBUK
* github-ff leaves
* whikloj leaves17:57
* benpennell leaves17:59
* github-ff joins18:01
[fcrepo4] awoods pushed 1 new commit to master: https://git.io/vdRdY
fcrepo4/master 2f2aca3 Aaron Birkland: Upgrade JQuery to 1.12.4...
* github-ff leaves
* peichman leaves
* travis-ci joins18:10
fcrepo4/fcrepo4#5212 (master - e65d94a : Yinlin Chen): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/0bb3da2a59f6...e65d94a01ea3
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/283919488
* travis-ci leaves
* travis-ci joins18:12
fcrepo4/fcrepo4#5211 (4.7-maintenance - a2eb41b : Yinlin Chen): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/7e8967643bb2...a2eb41b87b91
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/283919465
* travis-ci leaves
* travis-ci joins18:17
fcrepo4/fcrepo4#5213 (master - 2f2aca3 : Aaron Birkland): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/e65d94a01ea3...2f2aca337139
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/283922243
* travis-ci leaves
* mohideen leaves18:25
* dhlamb leaves18:27
* dbernstein leaves18:29
* dbernstein joins18:30
* mohideen joins18:31
* dbernstein leaves18:32
* mcritchlow leaves18:35
* mohideen leaves19:02
* mohideen joins19:11
* mohideen leaves19:32
* mohideen joins19:44
* mohideen leaves20:18
* dwilcox leaves20:28
* github-ff joins20:36
[fcrepo4] lsitu opened pull request #1257: Create TimeMap LDPCv for binary resource. (memento-versioning...feature/ldpcv_binary) https://git.io/vd0TL
* github-ff leaves
* anarchivist leaves22:12
* anarchivist joins22:13
* awoods leaves22:18
* benpennell joins23:10
* benpennell leaves23:38
* lsitu leaves00:06

Generated by Sualtam