Log of the #duraspace-ff channel on chat.freenode.net

Using timezone: Eastern Standard Time
* ksclarke leaves01:50
* dwilcox joins08:08
* dwilcox leaves08:28
* awead joins08:32
* awoods joins08:35
* dwilcox joins
* awead leaves08:45
* awead joins09:07
* ajs6f joins09:08
* whikloj joins09:09
* mikeAtUVa joins
* osmandin joins09:18
* ksclarke joins
<osmandin>awoods: Is a decision still pending for 1381, or can I go ahead and create and a PR?09:31
<awoods>osmandin: please create a PR that is limited to the solution agreed upon here: https://github.com/fcrepo4/fcrepo4/pull/739#issuecomment-8296424509:33
* ksclarke leaves09:36
* ksclarke joins09:39
* jgpawletko joins09:49
<ajs6f>all: does anyone have some spare cycles today to help me with the "blank nodes" issue (FCREPO-1385) I'm working? awoods and I have both found problems building the rbacl-auth module against the bnodes branch, but the failures are completely different, and I'd like to get more data. I would like someone to build the bnodes branch and then try to build the rbacl module and tell me what you get...09:59
* awoods leaves10:01
<whikloj>ajs6f: If your just looking for build messages I have time to compile
<ajs6f>whiloj: Yes, that's it: a build log. The bnodes branch is BNodesAreBNodes. Thank you so much!10:02
whikloj++
<whikloj>ajs6f: Ok BNodesAreBNodes built fine10:09
<ajs6f>whikloj: Good, that's what I would expect. Now, please try building the rbacl module. The build log from that is what interests me. I would expect it to fail with problems in the i-tests, but which ones is the question.10:10
<whikloj>ajs6f: ok10:12
* awoods joins10:13
* awoods leaves10:21
* awoods joins
<ajs6f>whikloj: Any luck?10:25
<whikloj>ajs6f: oh yeah sorry, how do want the build.log. The whole thing or just the failed section?10:26
<ajs6f>whikloj: It's probably easiest if you just upload the whole shebang into the ticket. Okay?10:27
whikloj: As an attachment to a comment, I mean.
<whikloj>ajs6f: ok, ticket num?10:28
<ajs6f>whikloj: Sorry, https://jira.duraspace.org/browse/FCREPO-1385
<whikloj>ajs6f: np its there10:30
<ajs6f>whikloj++
whikloj/awoods: Okay, cool. whikloj is getting the same problems as awoods, which narrows it down for me to something weird about my setup. Thanks for the cross-check, whikloj!10:31
<awoods>ajs6f: I suspect if you catch the AccessDenied exception in Deskolemizer.isSkolem() and return false in that case, all will be well.10:33
<ajs6f>awoods: That would be the first option I (jokingly) suggested— "Well, one option here is to assume that if the node is unreadable, it is not Skolem."10:34
awoods: You're basing that on the logic you put in your comment to the issue— that all true Skolem nodes should have exactly the same permissions as their parents?10:35
<awoods>ajs6f: and more specifically, no Skolem node will ever get to the method Deskolemizer.isSkolem() because the user will be blocked at the parent.10:36
<ajs6f>awoods: You mean, "no SKolem node that would not have been readable because of permissions"?10:37
<awoods>ajs6f: yes, thanks.
<ajs6f>awoods: Okay, I think I'm with you. I'll try that change immediately to keep moving, although I would like to think about it a bit and convince myself that we're really safe here. I really like the assumption that any blank/skolem node is unique within the sub-hierarchy of exactly one non-blank/non-skolem node, but I want to make sure that we're surely okay saying that and that we've got it encoded.10:39
I still can't believe we have a package name "org.fcrepo.kernel.impl.rdf.impl". Got to fix that sometime.
<awoods>ajs6f: yes, please verify that assumption: Skolems and their parents10:41
* awead leaves10:46
<awoods>ajs6f: "org.fcrepo.kernel.impl.rdf.impl" has half of a good reason for existing. The first "impl" relates to "fcrepo-kernel-impl" (vs. "fcrepo-kernel") and the second "impl" should relate to implementations of interfaces defined in the "org.fcrepo.kernel.impl.rdf" package. However, there are no such interfaces. So the second "impl" could probably go away, and the classes in "org.fcrepo.kernel.impl.rdf.impl" be moved to "org.fcrep
o.kernel.impl.rdf".
<ajs6f>awoods: Right.
awoods: "impl", as a package name segment, is idempotent.10:47
<awoods>ajs6f: I am not sure I get what you are getting at.10:48
<ajs6f>awoods: Once you have used "impl" as part of a package name, you have declared that everything in that package and subpackages is implementation. Using "impl" again, or five more times, for that matter, doesn't change anything more.10:49
<awoods>ajs6f: hmm10:50
ajs6f: If there were interfaces defined in the "org.fcrepo.kernel.impl.rdf" package, I would argue that it makes sense to put the implementations of those interfaces in "org.fcrepo.kernel.impl.rdf.impl"10:51
<ajs6f>awoods: I'm saying that there should not be interfaces in org.fcrepo.kernel.impl.rdf.
<awoods>ajs6f: That is tricky, no? If those interfaces are never intended to get out of kernel, would you still want them in the fcrepo-kernel project, instead of the fcrepo-kernel-impl project?10:53
<ajs6f>awoods: Why would we have interfaces in kernel that are internal-only?
* dwilcox leaves10:54
<awoods>ajs6f: If they were only used within the fcrepo-kernel-impl project.10:56
<ajs6f>awoods: If they were only used w/i fcrepo-kernel-impl, they belong in org.fcrepo.kernel.rdf, in fcrepo-kernel-impl. There's no law that says that if the Maven artifact name has impl in it, so must all packages therein.10:57
* awead joins11:02
<awoods>ajs6f: Are you suggesting in that case, that the interfaces and their implementation co-exist in "org.fcrepo.kernel.rdf"?11:03
<ajs6f>awoods: No, I'm saying that in that case, interfaces go in org.fcrepo.kernel.rdf and impls in org.fcrepo.kernel.rdf.impl.
awoods: But isn't this an empty point, because there are no such interfaces?
<awoods>ajs6f: yes, in a way11:04
<ajs6f>awoods: Maundering on endlessly about anti-practical minutia is usually my job, not yours.
<awoods>ajs6f: I wanted to see what it felt like. Thanks for giving me the opportunity.11:05
<ajs6f>awoods: I love the smell of obsessive-compulsive technical hygiene in the morning.Smells like… pedantry.11:07
* dwilcox joins11:16
<ajs6f>awoods: Yep, I'm catching AccessDeniedException and mapping it to false, and that seems to have solved the auth modules' problems. I'll commit that.11:17
<awoods>ajs6f: good
ajs6f: did you add a comment in the code describing the rationale?
ajs6f: I could see that bit of logic becoming blurry over time.11:18
<ajs6f>awoods: yes, but I'm still thinking we need to make that assumption more generally explicit. Perhaps a "usage note" of some kind in the documentation explaining the limits on the usage of bnodes.
<awoods>ajs6f: I agree that documenting this behavior is useful for developers, but do you see it ever surfacing to users?11:19
<ajs6f>awoods: maybe. I'm thinking of someone who notices that, as escowles explained recently to birkland, you can run updates against resource X with triples in them for resource Y and they will get applied to resource Y. If, in such an update, you refer to a bnode "in common" between the resources, you're not going to get quite what you thought you would.11:21
awoods: really, the confusing thing is not the bnode handling, but the fact that our updating methods allow you to act against resource X but make changes to resource Y.
* github-ff joins11:24
[fcrepo4] ajs6f pushed 1 new commit to BNodesAreBNodes: http://git.io/hrgn
fcrepo4/BNodesAreBNodes 5320cd1 ajs6f: Mapping nodes that are not readable because of access limitations to not-Skolem
* github-ff leaves
<awoods>ajs6f: would you be opposed to disallowing that current update behavior? (update on target X with triples relating to Y)11:25
<ajs6f>awoods: Definitely not opposed. I think it might be considerably clearer. But I write basically no client code against Fedora. Let's hear from some people who do.11:26
<mikeAtUVa>Does anyone know of a decent library (in java) to easily programatically build sparql update queries?11:42
* awead leaves11:43
<ajs6f>mikeAtUVa: You mean like a fluent API?11:48
* mikeAtUVa shrugs at ajs6f... anything beats string concatenation, right?11:49
<ajs6f>mikeAtUVa: Depends, but certainly, I would want something else. It has to be SPARQL (not just some useful graph traversal language)?11:50
<mikeAtUVa>ajs6f: basically I'm just writing code to issue a lot of Sparql update commands to fedora 4 and I don't want to build all those query strings by hand if there's a useful library out there.11:51
* awead joins11:54
<ajs6f>mikeAtUva: And it has to be Java? Not just something on the JVM? (I'm thinking of https://code.google.com/p/scardf/wiki/Querying).
<mikeAtUVa>Eh, I'll weigh the pros and cons...11:57
ajs6f: thanks11:58
<ajs6f>mikeAtUVa: If I come across one, I'll send it your way.11:59
<mikeAtUVa>ajs6f: thanks!
<awoods>mikeAtUVa: It looks like someone else had the same question: http://stackoverflow.com/questions/7250189/how-to-build-sparql-queries-in-java12:12
mikeAtUVa: wihch leads to: http://jena.apache.org/documentation/query/manipulating_sparql_using_arq.html12:13
* awead leaves12:18
<mikeAtUVa>Thanks awoods. I'll look into that.12:21
Mostly I was curious if everyone had a way of composing sparql update queries that I hadn't hear about, and it sounds like a resounding no.12:22
<awoods>mikeAtUVa: lead the way12:23
<ajs6f>mikeAtUVa: https://github.com/anqit/spanqit/wiki12:24
Worst. Name. Ever.
<awoods>ajs6f: that is ridiculous12:25
<ajs6f>awoods: Don't blame me. That's the kind of joke Fedo would enjoy.
awoods: Still, it looks like what mikeAtUVa wanted.12:26
<mikeAtUVa>ajs6f: I think spanqit only supports SELECT and COSNTRUCT queries, not update... so perhaps we dodged a bullet there.12:28
<ajs6f>mikeAtUVa: Well, if you do something to scratch your own itch, you can send them a PR. Including a name-change.
<awoods>mikeAtUVa/ajs6f: https://github.com/anqit/spanqit/issues/112:33
<mikeAtUVa>awoods: the developer's name is anqit.12:34
<ajs6f>awoods/mikeAtUVa: It's only fair to offer some suggestions. How about "Sparqit"
<awoods>mikeAtUVa: I guess you could submit an issue against his/her name.12:35
<ajs6f>awoods/mikeAtUVa: Maybe this only matters to people who are American-English-speakers and as immature as we clearly are?
<awoods>ajs6f: Sparqit is reasonable
ajs6f/mikeAtUVa: yes, a project name change would have to also propagate to the associated projects: "OpenRdfSpanqitAdapter" and "spanqit-examples"12:37
* awead joins12:47
* awead leaves13:00
* github-ff joins13:01
[fcrepo4] awoods closed pull request #751: Making sure prefer header params isn't null (FCREPO-1406) (master...prefer-parsing) http://git.io/hzn5
* github-ff leaves
* awead joins13:03
<whikloj>awoods: This Fuseki thing seems like it might be a bug https://issues.apache.org/jira/browse/JENA-81613:07
<awoods>whikloj: have you tried using Fuseki 2.13.0?13:08
<whikloj>awoods: not yet. I tried setting up an in-memory and TDB endpoints and submitting to both. They both seemed to have this issue when defined in a config file.13:09
awoods: trying just an in-memory setup in a config file now13:10
awoods: still version 1.1.2, I'll try 2.13 after
* awead leaves13:16
* awead joins13:58
* ajs6f leaves14:33
* ajs6f joins14:39
<whikloj>awoods: alright I give up, I found one reference that says that Jena only supports entailment rules for in-memory dataset because otherwise they are too costly. I'll merge your request and I have a couple of fixes of my own to add.14:53
<awoods>whikloj: thanks for looking into it... we can always update the config later.14:54
whikloj: p.s. I also plan on forking your work into fcrepo4-labs
<whikloj>awoods: ok14:55
awoods: you can also consider updating the sparql recipes to use the appropriate namespaces :)14:58
<awoods>whikloj: they work as is. what do you have in mind?15:01
<whikloj>add the XMLSchema namespace prefix and if you want to use strings in a triple append the IRIref15:02
<awoods>whikloj: have you tested if that works with the "--mem" option?15:04
<whikloj>awoods: I think I did, but I have re-run those sparql recipes so many times I could be wrong.15:05
awoods: I am rebuilding my VM right now, I'll test it once it comes up.
<awoods>whikloj: if we have recipes that work with both the "--mem" and "--loc" configuration options, maybe we should update the recipes.15:06
* dwilcox leaves16:02
<whikloj>awoods: yes it works with both --mem and --loc if you add the prefix and change the query 1b to ?ds fcrepo:mixinTypes "fedora:NonRdfSourceDescription"^^prefix:string16:13
awoods: I'll try 1c right now
<awoods>whikloj: great. If all of the recipes on the following page works, let's go back to your --loc config16:14
https://wiki.duraspace.org/display/FEDORA4x/SPARQL+Recipes
whikloj: if they do work, could you also please update the above wiki page?
<whikloj>awoods: sure thing
* osmandin leaves16:15
<whikloj>awoods: funny thing is that 3i returned 2, not "2"^^<http://www.w3.org/2001/XMLSchema#integer>16:38
<awoods>whikloj: hmm
<whikloj>awoods: so question 2b would have 2 possible answers either "Foo" or "Foo"^^<http://www.w3.org/2001/XMLSchema#string> and 3i would have 2 possible answers16:40
awoods: just not sure why string doesn't auto translate and integer does when using a persistent store16:41
<awoods>whikloj: seems pretty odd to me.16:43
whikloj: If you can find the simplest form that works for both --mem and --loc, then update the wiki with that, please.
<whikloj>awoods: what do you mean by the simplest form?16:46
<awoods>whikloj: the form that does not have the type included.16:47
<ajs6f>awoods: Moving the deskolemization down into the kernel-impl layer is the right thing to do. It's also kind of a nightmare. We're going to have to pass maps of substitutions all over the place, because the RDF available by one resource may depends on the RDF produced by another (say, a blank node to which the first has some relationship) and we have to use the same deskolemizing substitutions all through the graph of dependency.
awoods: Don't hold the release. I'm going to have to turn to the DC stuff early next week, and I'm not going to do this blank node thing in a crappy and confusing way that will be impossible to maintain.16:48
awoods: the alternative would be to let it live in the HTTP layer. I don't like that for the same reasons you don't like that.
<awoods>ajs6f: if you think you can crack the nut in a clean and pleasing way, let's do it right. There is no immediate rush.16:49
mikeAtUVa: that would me the gates are open for a 4.1.1 release.16:50
mikeAtUVa: that would mean the gates are open for a 4.1.1 release.
<ajs6f>awoods: I don't think there is a clean and pleasing way to support blank nodes. I'm reaching for some kind of way that doesn't stab people in the face while rubbing bubblegum in their hair.16:51
<awoods>ajs6f: keep up the good work16:52
ajs6f: by the way, I would like to circle with you on what environment you would like for your DC-FUG session
ajs6f: because in the session before, we will be setting up everyone's vagrant environment16:53
ajs6f: may as well do it in a way that supports your session.
<ajs6f>awoods: Environment? Relaxed. Maybe a small jazz combo playing quietly, a friendly bartender… mostly empty tables… just a few people, talking softly, sharing a special moment.16:54
<awoods>ajs6f: can do16:55
<mikeAtUVa>awoods: so we're not waiting for anything for a 4.1.1 release? I can probably start on it on monday if that's the case.
<whikloj>awoods: have you ever compared the results of your tests in text, json and xml? Just wondering I think using fuseki's xml output and xml-to-html translation solves most of these issues.
<mikeAtUVa>awoods: https://wiki.duraspace.org/display/FF/Fedora+Release+Process is roughly up-to-date?16:56
<awoods>whikloj: interesting! if you can document that in the recipes, that would be great.
mikeAtUVa: yes that page is mostly right
<whikloj>awoods: okay, I am going to test this again before I change anything.16:57
<mikeAtUVa>awoods: and it's probably safe to assume no one would be willing/around to test a release candidate?
<awoods>mikeAtUVa: There is one minor ticket that I suspect acoburn will have finished by Monday... https://jira.duraspace.org/browse/FCREPO-1405
mikeAtUVa: you can probe the committers16:58
<mikeAtUVa>awoods: will do... have a good time at Stanford.16:59
<awoods>mikeAtUVa: or maybe I will handle acoburn's issue and be done with it...
mikeAtUVa: in any case, you can plan on a 4.1.1 Monday... or whenever you get to it.17:00
<mikeAtUVa>awoods: K... if that ticket isn't resolved, I'll ask around on IRC.
<awoods>mikeAtUVa: great. thanks
<ajs6f>I'm out for the week. Don't stop believing, Fedora.17:02
* ajs6f leaves
<awoods>mikeAtUVa/whikloj: I am stepping away for an hour or so... do you need anything at the moment?
<whikloj>awoods: nope
<awoods>cheers
* mikeAtUVa leaves17:04
* github-ff joins
[fcrepo-message-consumer] hading opened pull request #80: Connection problem (partial) fix (master...master) http://git.io/h6BM
* github-ff leaves
* jgpawletko leaves17:38
* whikloj leaves17:47
* ksclarke leaves17:53
* jgpawletko joins18:20
* github-ff joins18:38
[fcrepo4] awoods pushed 1 new commit to master: http://git.io/hiTW
fcrepo4/master be0e046 Aaron Coburn: Aliasing any jcr-namespaced properties to fedora......
* github-ff leaves
* github-ff joins
[fcrepo4] awoods closed pull request #669: aliasing any jcr-namespaced properties to fedora: (master...jms-jcr-properties) http://git.io/H1GHOg
* github-ff leaves
* ksclarke joins20:00
* ksclarke leaves20:24
* ksclarke joins20:40
* awead leaves22:18

Generated by Sualtam