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

Using timezone: Eastern Standard Time
* escowles_ joins03:46
* escowles leaves03:48
* dhlamb joins07:29
* dhlamb leaves07:40
* dhlamb joins
* dhlamb leaves07:45
* dhlamb joins08:27
<ruebot>awoods: https://github.com/blog/2111-issue-and-pull-request-templates -- might be of interest in fcrepo-land? we're considering taking advantage of it in islandora-land.08:51
<awoods>ruebot: that sounds like a great idea.08:52
* jrgriffiniii joins08:54
<awoods>ruebot/escowles_: Let's hold off on any commits until acoburn's fcrepo-1312 gets committed08:55
ruebot/escowles_: We are almost done with fixing the propagating impacts to other projects.08:56
<escowles_>awoods: sounds fine to me -- i don't want to make it any harder to get acoburn's big PR merged, and i'm happy to rebase any of my small things if needed08:57
<awoods>thanks, escowles_
<ruebot>escowles_++09:06
* github-ff joins09:11
[fcrepo-module-auth-xacml] awoods opened pull request #47: Depends on fcrepo4/fcrepo4#962 (master...fcrepo-1312) https://git.io/v2f0M
* github-ff leaves
* github-ff joins09:14
[fcrepo-module-auth-webac] awoods opened pull request #55: Updates based on proposed upstream changes (master...fcrepo-1312) https://git.io/v2fE3
* github-ff leaves
* acoburn joins09:20
* mohamedar joins09:32
* ajs6f joins09:37
* whikloj joins09:39
<acoburn>jrgriffiniii: are you still working on https://jira.duraspace.org/browse/FCREPO-1443? If you'd like to see the ticket through, that's great09:47
jrgriffiniii: otherwise, given the current focus on fcrepo-java-client as a java-based client, I would be inclined to close that ticket09:48
<jrgriffiniii>acoburn: If Esmé and Michael wouldn't object, I can certainly close this ticket09:49
acoburn: Also, if it is best to simply close this ticket and raise it for discussion during the next tech. meeting, I can address this immediately09:50
<acoburn>jrgriffiniii: I don't think escowles_ will object. We discussed this ticket at a previous tech meeting09:51
jrgriffiniii: and the consensus was that this is good work and if you'd like to see the PR through completion, that's great and we'll support that
jrgriffiniii: but, if you're not planning to work on this, then there's not much reason to put effort in that direction09:52
<escowles_>acoburn: jrgriffiniii: yep, i think everyone agreed that we should support completing work that was in progress, but generally steer people towards the new stateless java client in the future
<jrgriffiniii>acoburn: Excellent, my apologies for having been out of contact. While I would be open to seeing this through, it was my understanding that much of the client was undergoing substantial refactoring (if not being entirely rewritten)
escowles_: Thank you for this clarification, then I shall simply close this in order to direct people to the new client09:53
<acoburn>jrgriffiniii: thank you!
* github-ff joins09:55
[fcrepo4] awoods pushed 1 new commit to master: https://git.io/v2fKr
fcrepo4/master 523953d Aaron Coburn: Replace Iterator-based RdfStream with Stream-based RdfStream...
* github-ff leaves
<acoburn>jrgriffiniii: your notes from yesterday were incredible #thanks!
* github-ff joins
[fcrepo4] awoods closed pull request #962: Replace Iterator-based RdfStream with Java 8 Streams (master...fcrepo-1312) https://git.io/vR8vT
* github-ff leaves
* github-ff joins09:56
[fcrepo-audit] awoods pushed 2 new commits to master: https://git.io/v2fKF
fcrepo-audit/master e69cf1d Aaron Coburn: Modifications based on upstream changes
fcrepo-audit/master c00a95d Andrew Woods: Merge pull request #29 from acoburn/fcrepo-1312...
* github-ff leaves
* github-ff joins
[fcrepo-module-auth-xacml] awoods pushed 2 new commits to master: https://git.io/v2f6v
fcrepo-module-auth-xacml/master e474b98 Andrew Woods: Depends on fcrepo4/fcrepo4#962...
fcrepo-module-auth-xacml/master 24b74b7 Andrew Woods: Merge pull request #47 from awoods/fcrepo-1312...
* github-ff leaves
* github-ff joins09:57
[fcrepo-module-auth-webac] awoods closed pull request #55: Updates based on proposed upstream changes (master...fcrepo-1312) https://git.io/v2fE3
* github-ff leaves
* github-ff joins
[fcrepo4-client] jrgriffiniii closed pull request #34: FCREPO-1443 fcrepo-client should use Link rel="describedby" header for description (master...fcrepo-1443-jrgriffiniii) https://git.io/vltvA
* github-ff leaves
* github-ff joins
[fcrepo-transform] awoods pushed 1 new commit to master: https://git.io/v2f68
fcrepo-transform/master d386ac2 Andrew Woods: Merge pull request #8 from fcrepo4-exts/fcrepo-1312...
* github-ff leaves
<awoods>ruebot/escowles_/acoburn/ajs6f/whikloj: the gates are open for new commits. fcrepo-1312 is in.09:58
ruebot/escowles_/acoburn/ajs6f/whikloj: I need to step away for a few hours, but will be back later in the day.09:59
<acoburn>awoods++
<awoods>acoburn+++
<escowles_>awoods++ # huzzah
<awoods>cheers, team.
<ruebot>awoods++
<ajs6f>awoods is a merge-monster10:00
<jrgriffiniii>awoods++
<ajs6f>acoburn: Which is the follow-on ticket for that?
<acoburn>ajs6f: I was looking for it… I don't think it exists yet10:01
* travis-ci joins
fcrepo4-exts/fcrepo-transform#31 (master - d386ac2 : Andrew Woods): The build has errored.
Change view : https://github.com/fcrepo4-exts/fcrepo-transform/compare/863592a6896b...d386ac259490
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-transform/builds/110397240
* travis-ci leaves
* jcoyne joins10:02
<jrgriffiniii>acoburn: Thank you for bringing FCREPO-1443 to my attention, and I'm glad that the the notes were of assistance. I have closed the related PR, updated the JIRA issue, and have requested that awoods please close the JIRA issue when he has the next opportunity.
* travis-ci joins
fcrepo4-exts/fcrepo-audit#75 (master - c00a95d : Andrew Woods): The build has errored.
Change view : https://github.com/fcrepo4-exts/fcrepo-audit/compare/cc4e64c5b869...c00a95d152be
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-audit/builds/110396751
* travis-ci leaves
<ajs6f>acoburn: Okay, that's cool.
<acoburn>ajs6f: are you going to add that or shall I?
<ajs6f>acoburn: You create it, I'll read it right afterward and say anything else I think needs to be said. But I think you have a better picture in your mind right now.10:03
* travis-ci joins10:04
fcrepo4/fcrepo-module-auth-webac#101 (master - 3a6f435 : Andrew Woods): The build has errored.
Change view : https://github.com/fcrepo4/fcrepo-module-auth-webac/compare/ad8d037dea40...3a6f435e033f
Build details : https://travis-ci.org/fcrepo4/fcrepo-module-auth-webac/builds/110397184
* travis-ci leaves
* travis-ci joins10:05
fcrepo4/fcrepo-module-auth-xacml#98 (master - 24b74b7 : Andrew Woods): The build has errored.
Change view : https://github.com/fcrepo4/fcrepo-module-auth-xacml/compare/34db77ac0555...24b74b749507
Build details : https://travis-ci.org/fcrepo4/fcrepo-module-auth-xacml/builds/110396931
* travis-ci leaves
* peichman joins10:06
<acoburn>ajs6f: https://jira.duraspace.org/browse/FCREPO-192110:09
<ajs6f>acoburn++10:11
* travis-ci joins10:23
fcrepo4/fcrepo4#4284 (master - 523953d : Aaron Coburn): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/42f9c66f15fe...523953db47ff
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/110396507
* travis-ci leaves
* mcritchlow joins10:41
<ajs6f>acoburn: Just to check my head, what I think for 1921 is that you pass a type (or set of types) into getTriples (like before your PR) except we also offer a suite of proper interface types (e.g. LdpMembershipContext, FixityContext, whatever). Those are the types we expect people to be passing through that method. On the impl side, an impl chooses a mechanism by which to translate those types into actual action. That subsumes the pre-your-P10:48
<acoburn>ajs6f: yes, and I was assuming that all of those interfaces inherit from a base interface, which is what getTriples expects10:49
ajs6f: as in, a base interface called RdfContext10:50
ajs6f: or something like that
<ajs6f>acoburn: That's my first assumption, although as barmintor pointed out, you could get crafty with generics. I might have to just sketch around a bit before it becomes clear what works best.10:51
<f4jenkins>Project fcrepo4-T2 build #511: SUCCESS in 9 min 43 sec: http://jenkins.fcrepo.org/job/fcrepo4-T2/511/10:57
* escowles: Adding specific version to deprecation warning
* awoods: Replace Iterator-based RdfStream with Stream-based RdfStream
<ajs6f>acoburn: actually, it would be Class<? extends RdfContext>, to start with, because it's the type, not an instance… which feels a bit gross… hmmm...11:22
%#%%#%ing erasure.11:30
* travis-ci joins11:50
fcrepo4-exts/fcrepo-audit#75 (master - c00a95d : Andrew Woods): The build has errored.
Change view : https://github.com/fcrepo4-exts/fcrepo-audit/compare/cc4e64c5b869...c00a95d152be
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-audit/builds/110396751
* travis-ci leaves
* travis-ci joins11:51
fcrepo4/fcrepo-module-auth-webac#101 (master - 3a6f435 : Andrew Woods): The build has errored.
Change view : https://github.com/fcrepo4/fcrepo-module-auth-webac/compare/ad8d037dea40...3a6f435e033f
Build details : https://travis-ci.org/fcrepo4/fcrepo-module-auth-webac/builds/110397184
* travis-ci leaves
* tjohnson joins12:07
<barmintor>ajs6f: when I started tooling around with something Class<? extends RdfContext> was my starting point, too12:21
ajs6f: but I think ideally you would wire a provider in and have the RdfContext instance injected
<ajs6f>barmintor: I'm doing something a little different now: RdfGenerator<? extends TripleCategory>
<barmintor>sure, something like
<ajs6f>barmintot: I'm worried about the injection now, I'm just reusing what acoburn did, because we can do the inject right later. I just want to get the type system right so you and he can sanity check me.12:23
barmintor: I'm _not_ worried about the etc.12:24
<barmintor>ajs6f: yeah, fair enough. the injection is the pain point, but it's also not the actually relevant thing
stupid jaxrs
<ajs6f>barmintor: Exactly. We'll need to do it, but one thing at a time.12:25
* barmintor goes to get a lunch
<ajs6f>barmintor: Get yourself two. You deserve it.
* github-ff joins12:39
[fcrepo4-vagrant] whikloj closed pull request #36: Address FCREPO-1919 (master...FCREPO-1919) https://git.io/v2efq
* github-ff leaves
* mcritchlow leaves12:59
* mohamedar1 joins13:01
* mcritchlow joins
* mohamedar leaves13:02
<ajs6f>acoburn: Are the categories of triples of a given resource for which clients might ask a kernel orthogonal?13:11
acoburn: Or more to the point, do we want to guarantee/require that?13:12
<acoburn>ajs6f: in the current impl, that's mostly correct, but there are a few edge cases
<ajs6f>acoburn: E.g.?
<acoburn>ajs6f: like PROPERTIES and MINIMAL
ajs6f: or SERVER_MANAGED and MINIMAL13:13
<ajs6f>acoburn: I think MINIMAL is wrong— i.e. it's not really the same species of animal as the others.
<acoburn>ajs6f: I completely agree
ajs6f: the issue is that when return=minimal and properties are requested, the skolem nodes and hash uris are excluded13:14
<ajs6f>acoburn: We need to understand just what it is. Is it a quality of the others, like there could be SERVER-MANAGED AND SERVER_MANAGED WITH MINIMAL?
acoburn: Is it completely different?
<acoburn>ajs6f: it's not completely different, it's just a subset
<ajs6f>acoburn: I'm not even sure that "when return=minimal and properties are requested, the skolem nodes and hash uris are excluded" is actually correct.13:15
<acoburn>ajs6f: I agree with you there
<ajs6f>acoburn: Is it a filtering? Or do we manage to avoid generating some triples by knowing about it?
<acoburn>ajs6f: in the current impl, we know about the presence of MINIMAL13:16
<ajs6f>acoburn: Do you know if we do "when return=minimal and properties are requested, the skolem nodes and hash uris are excluded" because of actual user feedback?
acoburn: We know about it, and we use it to avoid unneeded work?
<acoburn>ajs6f: because of awoods' feedback. I don't know if it's a bug or if it's expected behavior
<ajs6f>acoburn: I'll ping awoods when he gets back. When does he get back?13:17
acoburn: It sounds to me like we have "categories" and "hints" and MINIMAL is an important example of the latter.
<acoburn>ajs6f: it seems he will be back this afternoon
<ajs6f>acoburn: Cool.
<acoburn>ajs6f: yes! MINIMAL is definitely a hint
<ajs6f>acoburn: But because of LDP, we are in fact required to respect it. Like the kind of hint one's partner sometimes gives during a dinner party conversation that some topics are inappropriate.13:18
acoburn: Well, do we widen the getTriples contract to include categories and hints?13:20
<acoburn>ajs6f: regardless of the role of MINIMAL in the PropertiesContext, it also affects the ServerManaged context
<ajs6f>acoburn: but it's doing the same thing— knocking out triples, right?
<acoburn>ajs6f: yes, exactly. In that case, it's including only the LDP Type triples (Container, IndirectContainer, etc)13:21
<ajs6f>tjohnson: You're a serious LDP-head. Would you say it's fair to decompose the Prefer header values along the two axes of "category" and "hint", as the above discussion suggests?13:22
* Guest35470 leaves13:25
* ajwagner joins13:27
<barmintor>wait, there's some static here about return"minimal" and include="ldp:MinimalContainer"13:31
* mohamedar1 leaves13:52
* jcoyne leaves13:54
* ddavis joins14:00
* mohamedar joins14:01
<ajs6f>barmintor: What?
* yinlin joins
<barmintor>ajs6f: sorry, pointing out that the term minimal is ambiguous here14:02
<ajs6f>barmintor: I understood acoburn to be referring exclusively to the header value, but I could be confused, wrong, or even just angry and frustrated.14:03
<barmintor>ajs6f: acoburn described, I think, include="ldp:PreferMinimalContainer"14:04
* mcritchlow leaves
<yinlin>The mute button in the VoIP dialer doesn't work since last week to me. Does anyone also has the same problem?
<ajs6f>barmintor: Dunno. I think he might be on the API-X call...
<acoburn>barmintor: I meant return=minimal
<barmintor>ajs6f: but the Prefer header also has return="minimal", which is diffrent
<ajs6f>barmintor: Right, that's what I thought he was talking about, and it seems that it was what he was talking about. With his fingers, on the keyboard.
<acoburn>barmintor: but that is similar to return=representation; include="ldp:PreferMinimalContainer" (are they the same? I don't know)14:05
<jrgriffiniii>yinlin: This also doesn't work for me
<barmintor>acoburn: no, they are not the same
acoburn: the return parameter is from a different spec, for one :)14:06
acoburn: I *think* escowles_ and others were advocating for return="minimal" to return only text/plain of the resource URI14:07
<ajs6f>barmintor: I'm trying to factor apart the kinds of things you could say in Prefer that partition the available triples (like "versioning" ) and those that give hints as to how to return them (like "minimality"). Are you saying that it can't be done?
<barmintor>ajs6f: no, no. I'm saying that there's more than one concept of minimal-ity in the Prefer header
<ajs6f>barmintor: Okay, that's fine by me: I would think that's probably the business of the HTTP layer, to some extent.14:08
<escowles_>barmintor: acoburn: yes, and i have a PR that does that (and returns the representation if the right prefer header is provided): https://github.com/fcrepo4/fcrepo4/pull/985
<ajs6f>barmintor: We would want to translate into something that isn't HTTP-aware for the contract of the kernel.
<escowles_>though i agree with ajs6f that there's more than one notion of minimalness, so we may want to differentiate them14:09
<ajs6f>MINIMIZE THE QUANTITY OF MINIMALITY.14:10
<barmintor>I know, I actually wanted an option that returned no body at all
<ddavis>everything in moderation especially moderation
<escowles>Prefer: even-minimal-er
<barmintor>Prefer return="nothing" omit="*"14:11
hmm
<ajs6f>Prefer: https://en.wikipedia.org/wiki/Mu_%28negative%29
<barmintor>I wonder if we should moot that to ldpnext, and maybe write it into the api spec
<escowles>Prefer: return=無
<ajs6f>Wow, I didn't know we are Unicode aware in here. This opens all sorts of opportunities for stupid IRC tricks.14:12
<barmintor>this is in the particular case of POST, in which the client thinks all the necessary information is in the headers and prefers a 0-length body
there's not really a way to express that, and for some clients it matters (lke apache-http in Java, iirc)14:13
<escowles>barmintor: i wouldn't mind new values for returning no body, and returning the URL, distinct from return=minimal
return=nothing, return=identifier?
<barmintor>escowles: I'm a nudger: the latter seems like minimal to me.14:14
<ajs6f>One thing that is clear is that minimal doesn;t have the one meaning, even in quite specific cases.14:15
<barmintor>escowles: I guess you could omit everything, but return="representation" omit="ALL THE URL VALUES" seems weird to me
ajs6f: I think it mostly does, it's just that acoburn described another thing
<escowles>barmintor: yes, a representation with everything filtered out seems like a weird way to get nothing14:16
<ajs6f>barmintor: no, you and escowles can't agree on what it means in a specific interaction
<barmintor>ajs6f: i totally agree with escowles
tooooooootally
<escowles>fer shure
<acoburn>barmintor: ajs6f: I don't think there is a way to filter out user properties at present
<barmintor>acoburn: this is a good point14:17
<ajs6f>acoburn: is that a use case?
are people asking for that?
<acoburn>ajs6f: not from me, it's just that I don't think you can filter out everything
<barmintor>ajs6f: if you're nose-following and the descriptions are big, definitely
<ajs6f>acoburn; oh, i see
<barmintor>ajs6f: it's the counterpart to small descriptions and large sets of contained resources14:18
<ajs6f>barmintor: but no one has actually asked for it. frankly, i am skeptical that descriptions get that big
* barmintor rolls up his sleeves, starts spitting out triples14:19
<ajs6f>Ooh, they're all over the floor.14:20
<barmintor>ajs6f: I would *prefer* something that just said not to include a body
get it?
I would *prefer* it
<escowles>barmintor: you may need to rinse with some XML...
<ajs6f>barmintor I. See. What. You. Did. There.
barmintor: I agree that "no body" is a good value to have, but it's not "minimal". It's something distinct. Is there a common value with that semantic?14:21
<barmintor>I guess another way you could go about it would be to say return="minimal" include="ldp:PreferContainment etc" could mean "don't include anything more than what I included"
I mean, it's all optional, one of the response headrs says whether the server paid attention to your preferences14:22
<ajs6f>barmintor: Yes, but you could also understand there to be some "baseline" or core. I'm not saying either way is better, I'm saying you are likely to have disagreement FOREVER, so I would PREFER an actual explicit value for "Don't gimme none, hon."
<barmintor>ajs6f: yeah. This seems like mayybe an ldpnext topic, though.14:23
a ldpnext
whatever.
<ajs6f>barmintor: Yes, def. But from what Rob Sanderson has said, we may be most of LDPNext.
<barmintor>this sounds like a Rob Sanderson problem is what I mean to say.
<ajs6f>barmintor: Rob Sanderson sounds like our problem.14:24
?
<escowles>looking at the spec, i think it might be better to interpret return=minimal as not wanting a body at all: https://tools.ietf.org/html/rfc7240#section-4.2
<barmintor>I wish MPOW would decide on whether I can join that interest group *sigh*14:25
<ajs6f>escowles: Yeah, there are two different suggestions there, each of which assumes no body at all.
<barmintor>escowles: yes- in which case our existing approach is flawed.
<ajs6f>barmintor: Do you guys have a W3C membership?
<barmintor>ajs6f: sort of.
<escowles>yep, so maybe we need to create a new value for returning the identifier14:26
<ajs6f>barmintor: Like you hang out at dinner parties, but you wouldn't invite each other to your kids birthdays?
<barmintor>escowles: that is restricted to plain text?
<escowles>barmintor: yes14:27
<barmintor>Hmm.
<ajs6f>return=One-and-only-one-URI-not-another-word
<barmintor>escowles: this is for clients that can't process headers?
<ajs6f>That seems like a really narrow market segment.
<escowles>barmintor: it's for command-line curl usage, really
<barmintor>yeah.
<ajs6f>escowles: For CLI curl usage for people who have not yet discovered the -v flag.14:28
<escowles>ajs6f: sure, but it happens to overlap with the developers pretty well
<barmintor>I might prefer to just commit to return=minimal -> no body
<ajs6f>escowles: Seriously? That's slightly depressing.
<escowles>ajs6f: yes, i know i could get the headers with -D-, etc.
<barmintor>ajs6f: people who don't spend a lot of time on cURL don't mess with the flags
<escowles>ajs6f: but it's easier to do "curl -X POST http://... > list-of-urls.txt"14:29
<ajs6f>barmintor: So our audience is now people who do use curl, but not much, and are comfortable with CLI tools, but not enough to try curl -h and read the options.
<barmintor>ajs6f: I wouldn't say that's our audience, I'm just noting the emails we get sometimes
<escowles>ajs6f: our audience, for this one little feature, is people who want to write shell scripts using curl and would like it to be easier to get the created URL than parsing the headers would be14:30
<ajs6f>escowles:barmintor: Okay, I'm happy for whatever. My real concern is understanding how to structure requests for triples from the kernel, and as long as what we do with prefer values can be translated into a sane structure underneath, fine.
<escowles>ajs6f: and i think i'm hearing that return=minimal should return nothing, so that should make that a little bit cleaner14:31
<barmintor>ajs6f escowles acoburn what about: return=minimal never returns triples, but if you ask for text/plain it reproduces the Location in the body
<escowles>we just need a new value for return=identifier or whatever
<barmintor>that seems really fussy
(my suggestion, not escowles )
<ajs6f>barmintor: so minimal = nothing almost all the time, unless you use one specific accept mimetype value?14:32
<barmintor>it seems fussy, but it also seems not-colliding
ajs6f: yeah
ajs6f: is it gross?
* mohamedar1 joins
<ajs6f>escowles 's return=identifier seems more understandable to me. But again, I'm thinking about what this stuff looks like down the stack.
barmintor: That may not be the important thing.14:33
<barmintor>it's a question of where you want to locate the weirdness, since return="identifier" only returns text/plain
* mohamedar leaves
<barmintor>so do you ignore the requested MIME, or do you make a sly accommodation of an edge case
<ajs6f>barmintor: Oh, no. We can really gussy this thing up beyond all purposeful effort. You could have a one-triple return for all the RDF types, an anitmated GIF of the URI for image/gif, a spreadsheet with one cell for CSV, etc.14:34
<escowles>or do we have returning just the identifier as text/plain be the default behavior if no prefer/accept headers are sent, and keep it out of the kernel altogether?
<ajs6f>escowles++ # isnt' that the use case you guys were really talking about anyway?14:35
<barmintor>ajs6f: ::sad, hurt face struggling to maintain a professional demeanor emoji::
<ajs6f>barmintor: Come to Dublin and I'll buy you a glass of bad stout with someone's initials in it.
<barmintor>escowles: so if you say return=minimal and want nothing, you specify a MIME besides text/plain?14:36
<ajs6f>barmintor: I'm serious about this: no , you could get a key-value file of the stuff we would have put in triples.
<escowles>barmintor: no, i was thinking return=minimal would return nothing, regardless of what accept headers were supplied (or none)14:37
<barmintor>escowles: Oh, I see. No prefer headers.14:38
ajs6f: I was talked out of this by the (IMO) very convincing case that the one triple forms would be completely idiosyncratic without a big specification14:39
<ajs6f>barmintor:escowles: Why would your prospective newbie be unsure of how to read headers in a response, but perfectly happy using them in a request? This "don't ask for anything specific, get the URI in the body" thing is actually the ergonomics you were discussing.
barmintor: One triple form is the natural evolution of Bruce Lee's one inch punch.
<escowles>ajs6f: right: no accept/prefer = return the uri, prefer minimal = get nothing at all
<barmintor>ajs6f: I think escowles use case of for f in `ls`; do ./post.sh $f >> log.txt; done is convinging14:40
ajs6f: or at least not unnatural
<ajs6f>escowles: Right. That seems like least surprise.
<escowles>and it's the current behavior, so it's nice to preserve that
<barmintor>escowles++ I think that's the least intrusive
<ajs6f>barmintor: I'm saying fine, but let's do it in the least disruptive and most useful way, which is (I think) what escowles most recently suggested.
"no accept/prefer = return the uri, prefer minimal = get nothing at all"++14:41
<barmintor>yeah
<escowles>i always prefer to minimally disruptive
<ajs6f>escowles: It's why you are welcome anywhere.
* barmintor arches an eyebrow at escowles
maybe.
I'm not sure that would stand up to a quick search of emails from escowles, but maybe.14:42
<escowles>barmintor: well, as minimally disruptive as i can be?14:43
<barmintor>now you're thinking like a w3c spec!
* escowles *sobs*
<ajs6f>escowles: Isn't that the very definition of "minimal" for which we've been searching?14:44
minimal = as minimal as one can be = maximally minimal.
<escowles>ajs6f: maximally minimal - is that like bauhaus design?
Prefer: return=baroque14:45
<ajs6f>escowles: No, Bauhaus minimizes the comfort and humanity.
* ddavis leaves14:48
<ajs6f>barmintor:escowles: So from the POV of FCREPO-1921, this discussion comes to "We're not going to change anything about the current behavior, and minimal means nothing."14:50
<escowles>ajs6f: having minimal mean return nothing would change the current behavior, right?14:52
<ajs6f>escowles; This is why I asked the question. Actually, I forgot to phrase it in the form of a question. Sorry, Alex.
<escowles>ajs6f: right now, return=minimal returns a list of namespaces for me when i do a GET14:53
so that at least would be different
<ajs6f>escowles: That sounds useful. NOT!
<escowles>ajs6f: exactly
<ajs6f>escowles: I'm bringing back "NOT!" Also "boss!" and maybe even "rad!".14:54
<escowles>but for FCREPO-1921, we might want to say that return=minimal doesn't touch the kernel for triple generation (the rest api can generate nothing)
<ajs6f>escowles: WIN! WIN! WIN!
<escowles>bitchen!
* diegopino joins
<ajs6f>escowles: Then we can say that the inputs to getTriples actually partition the possible triples returned. That is a strong and valuable claim.14:55
escowles: I mean the possible values of the inputs.
<escowles>ajs6f: yes, that sounds useful and logical, even
<ajs6f>escowles; That could create some tubular impl optimizations.
* yinlin leaves14:56
<acoburn>escowles: ajs6f: that would make the implementation much, much easier
<escowles>ajs6f: i remember when 'tubular' seemed like a reasonable thing to say.... but i can't say i really understand it
<ajs6f>escowles: I remember when "23 skidoo" seemed like a reasonable thing to say, but I can't remember why.14:57
acoburn: Yeah, it's a stronger outcome than I was really hoping for, but it will make a lot of work a lot easirer.
<escowles>acoburn: ajs6f: so is this headed in the direction of having the include/omit values map 1-to-1 to the RDF generation classes?
<ajs6f>escowles: NO!14:58
<escowles>ajs6f: oh well, i thought it was going to be *really* simple there for a second
<acoburn>ajs6f: wait, why wouldn't it be a 1-1 mapping?14:59
<ajs6f>escowles: That's what we are fixing. It's heading towards having there be proper representations in the type system (maybe interfaces or something, that's part of the work of 1921) for the various bundles of triples, that partition results. Then impls of the kernel-api module will decide for themselves on the mechanics of getting from the representations to algorithms that generate triples.
<acoburn>ajs6f: oh I see, we're saying the same thing15:00
<ajs6f>acoburn: Why would it be a one-one mapping? Why couldn't you have an impl that features policy-driven persistence where various different types of resources (different types as in persisted differently) need to have very different mechanics for how you build, say, version triples?
acoburn: You need a mapping, but you need to leave it in the hands of the impl.15:01
acoburn:escowles: The mapping in the MODE impl will be pretty simple, and that's great, but ultimately, the point is that it is an impl concern, not an API concern.
<acoburn>ajs6f: makes sense to me15:02
<ajs6f>acoburn: SUCKER!
acoburn: I have no idea what I'm talking about!
* tjohnson leaves15:04
* jcoyne joins15:05
<ajs6f>awoods: Are you back yet?15:06
acoburn: If the categories partition the possible triple outputs for a given resource, the type system for 1921 is just a bunch of singletons that all impl a marker interface.15:12
acoburn: Actually, we could even keep an enum of required categories (that impls the marker interface) and let people add to that by offering new singletons with the marker interface.15:13
acoburn: Then we can easily distinguish between required/core and "new fangled".15:14
<acoburn>ajs6f: that would be great
<ajs6f>acoburn: I'm glad we're all on the same trolley. Now where are we going?15:15
<acoburn>mohamedar1++ #thanks!15:26
<jcoyne>trolley? Looks like a handbasket from my perspective.15:28
* tjohnson joins15:53
* dhlamb leaves15:58
* dhlamb joins
* dhlamb leaves16:03
* peichman leaves16:10
* mcritchlow joins16:16
* jcoyne leaves16:43
* mcritchlow_ joins16:48
* mohamedar1 leaves16:49
* mcritchlow leaves
* acoburn leaves16:50
* github-ff joins17:02
[fcrepo4] ajs6f created FCREPO-1921 (+1 new commit): https://git.io/v2UsC
fcrepo4/FCREPO-1921 f7f0bf1 ajs6f: First widening of contract for FedoraResource::getTriples
* github-ff leaves
* github-ff joins
[fcrepo4] ajs6f opened pull request #989: First widening of contract for FedoraResource::getTriples (master...FCREPO-1921) https://git.io/v2Us0
* github-ff leaves
<awoods>ajs6f: back
<ajs6f>barmintor: https://github.com/fcrepo4/fcrepo4/pull/98917:03
<barmintor>ajs6f: heading out, but I assigned myself and will watch for the promised commits.17:04
<ajs6f>awoods: "when return=minimal and properties are requested, the skolem nodes and hash uris are excluded" seems a little weird to both acoburn and myself. do we have user reports requesting that?
barmintor++ # thanks muchly
<awoods>ajs6f: not that I know of... that is just the way it has been.17:06
<ajs6f>awoods: so you're not against changing that?17:07
<barmintor>awoods: I just added a label to the fcrepo4 project (work-in-progress) so I don't have to edit the titles of PRs with [WIP]
<awoods>ajs6f: we should probably as folks before changing it.
* barmintor goes to home
<ajs6f>awoods: yeah, first bring it up at a tech call
* ajs6f is home, but is now signing off17:08
<awoods>ajs6f: it is a reasonable topic
* barmintor leaves
* diegopino leaves17:16
* github-ff joins17:18
[fcrepo4] awoods pushed 2 new commits to master: https://git.io/v2UnD
fcrepo4/master 5c77cfc Esmé Cowles: Only warn about namespaces mismatches if there are any user-defined namespaces
fcrepo4/master fcb3f0e Andrew Woods: Merge pull request #988 from escowles/ns-logging...
* github-ff leaves
* ajs6f leaves17:21
* travis-ci joins17:22
fcrepo4/fcrepo4#4286 (FCREPO-1921 - f7f0bf1 : ajs6f): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/commit/f7f0bf128527
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/110493147
* travis-ci leaves
* jrgriffiniii leaves17:39
* jcoyne joins17:42
* whikloj leaves17:44
* mcritchlow_ leaves17:58
* jcoyne leaves18:47
* jcoyne joins19:07
* mcritchlow joins19:34
* jcoyne leaves19:43
* jcoyne joins
* mcritchlow_ joins19:48
* mcritchlow leaves
* mcritchl_ joins19:50
* mcritchl_ leaves19:51
* mcritchlow_ leaves19:53
* jcoyne leaves20:20
* jcoyne joins20:30
* dhlamb joins20:34
* jcoyne leaves20:35
* dhlamb leaves
* dhlamb joins20:39
* jcoyne joins21:04
* jcoyne leaves21:08
* jcoyne joins21:14
* jcoyne leaves
* jcoyne joins21:15
* dhlamb leaves22:22
* jcoyne leaves22:31
* dhlamb joins22:44
* jcoyne joins22:55
* awoods leaves22:58
* dhlamb leaves23:15
* dhlamb joins23:16
* dhlamb leaves23:20