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

Using timezone: Eastern Standard Time
* amccarty joins04:22
* amccarty leaves04:26
* amccarty joins05:23
* amccarty leaves05:27
* dchandekstark joins05:49
* dchandekstark leaves05:54
* dwilcox joins06:07
* amccarty joins06:24
* dwilcox leaves06:27
* dwilcox_ joins
* amccarty leaves06:28
* dwilcox joins06:33
* dwilcox_ leaves
* dwilcox leaves
* dwilcox joins06:37
* amccarty joins06:51
* dchandekstark joins07:51
* dchandekstark leaves07:55
* manez joins08:00
* manez leaves08:05
* coblej joins08:11
* dwilcox leaves08:22
* manez joins08:34
* whikloj joins08:58
* mikeAtUVa leaves09:02
* acoburn joins09:15
* mikeAtUVa joins09:17
* ajs6f joins09:24
* dbernstein joins09:28
* dwilcox joins09:36
* dwilcox leaves09:41
* youn joins09:51
* dwilcox joins09:52
* dchandekstark joins
* coblej leaves09:56
* dchandekstark leaves09:57
* coblej joins10:11
* peichman joins10:16
* youn leaves10:17
* dwilcox leaves10:19
* dhlamb leaves10:28
<ajs6f>awood: ping10:36
* bseeger joins10:48
* awoods on a call10:56
<whikloj>It's true... I've even seen him do two calls at once10:58
<ajs6f>If he can participate in two calls at once, how is it less possible for him to participate in IRC and a call at once?10:59
Or perhaps he is already on two calls right now?11:02
What more do you want from the man? Oh the humanity!?!11:03
<ajs6f>awoods: What is your expected schedule for "spec sprints"? I had a good short conversation with michael Nelson yesterday and I'd like to start aligning our versioning ideas with the work of the Memnto group.11:05
<awoods>ajs6f: that is great. I would like to start organizing spec sprints immediately.
<awoods>ajs6f: I will add it to the tech agenda...
ajs6f: I was thinking it may make sense to pick a spec, and both flush it out and have dev work towards alignment with the spec happing in the context of the sprint.11:07
* ajs6f leaves11:10
* ajs6f joins
* ajwagner leaves
* ajwagner joins11:11
<ajs6f>awoods: Sure, if you like. I don't much care about what happens with the code.11:12
<awoods>ajs6f: do you have specific thoughts on how you imagine the spec sprints working?11:13
<ajs6f>awoods: No— doing sprints for this was your idea. I don't really understand how it's supposed to work or why the use of "sprint" -type methodology makes sense for something that is clearly not writing software. I'm just happy for any excuse to get people to pay attention to the specs.11:15
<awoods>ajs6f: great... just wondering.
<ajs6f>awoods: I suppose you could break the specs down into sections, but many of them aren't even that well-structure yet.
awoods: Versioning, you could do that. Maybe one or two others?11:16
awoods: Messaging, maybe.
<awoods>ajs6f: Indeed, the intent is to get focused attention on the specs for a time-boxed period.
<ajs6f>awoods: Well, then it all depends on who is going to participate. One of the things I dislike the most about "sprint" methodologies is the extent to which they can promote the fiction that people are funglible.11:17
awoods: Do you know who is going to participate?11:21
<awoods>ajs6f: no, there has not been a call for participation yet.11:22
<ajs6f>awoods: I guess we'll just wait until the Im/Ex work is done.
<acoburn>ajs6f:awoods: the fcrepo-camel component has an endpoint option "tombstone", that allows one to remove tombstones in a Fedora repository.11:24
ajs6f:awoods: I'm thinking of removing this
ajs6f:awoods: any thoughts?
<ajs6f>acoburn: I thought part of the point of "tombstones" was that they can't be removed, as per the siuggestion in the LDP spec, but I don't claim to understand them very wel.
barmintor: ^^^ if tombstones are the final version of a resource, that wouldn't make them any more amenable to removal, would it?11:25
<acoburn>ajs6f: my point here is that we shouldn't have tooling that makes it _easy_ to just remove tombstones
<awoods>acoburn: you are suggesting removing the ability to easily remove tombstones with the fcrepo-camel client? +111:26
<ajs6f>acoburn: I'm not disagreeing— I'm saying I'm not sure that it should be possible _at all_>
<acoburn>awoods: that is exactly what I'm suggesting
awoods: as long as Fedora allows users to remove tombstones, a client can still do that (i.e. w/ the HTTP component), but I don't want to make it easy for folks to do11:27
ajs6f: whether it should be possible _at all_ is another topic, and I don't think I disagree with you there
<awoods>acoburn: perfect
<ajs6f>acoburn: Why don't you make the change and open a ticket for the larger quesiton?
acoburn: Maybe put it on the meeting agenda.11:28
<acoburn>ajs6f: https://jira.duraspace.org/browse/FCREPO-220611:29
<ajs6f>acoburn: cool, but I meant a ticket for preventing people from removing them at _all_.11:30
<acoburn>ajs6f: yes, I'm writing that one now
* bseeger leaves11:36
* dwilcox joins11:37
<acoburn>ajs6f: https://jira.duraspace.org/browse/FCREPO-220711:43
<ajs6f>acoburn: Cool. I don't know if I actually think we should do that, but we should at least talk about it.11:44
<acoburn>ajs6f: I certainly find it convenient to be able to remove tombstones11:45
ajs6f: but there's a difference b/t possible and easy
<ajs6f>acoburn: I find it more efficient to just avoid creating resources. In fact, I try not to even start up any repositories.11:46
ajs6f: btw, what is the background on putting system managed triples into headers?
ajs6f: I assume that would just be fedora: namespaced triples?11:47
<ajs6f>acoburn: The questions scossu raised about the ease or difficulty of doing PUT.
<acoburn>ajs6f: ldp namespaced triples would still need to be in the RDF, no?
<ajs6f>acoburn: Mostly, I think. It would exclude triples that LDP mandates, obviously.
acoburn: Right, right.
<acoburn>ajs6f: is the idea to use Link: headers?11:48
<ajs6f>acoburn: More or less.11:49
<acoburn>ajs6f: can you even have literal values in those headers?
<ajs6f>acoburn: If we need those, we could use fresh headers.
<acoburn>ajs6f: Link: "fedo raadmin"; rel="http://fedora.info/definitions/v4/repository#createdBy"
ajs6f: that seems wrong ^^^
<ajs6f>acoburn: No, fresh headers. Not reused. Created-by: fedo raadmin11:50
<acoburn>ajs6f: ok, got it
<ajs6f>acoburn: Links are links. That's just one kind of header.
acoburn: Just as triples with URIs for objects are just one kind o triples.
<acoburn>ajs6f: right
<ajs6f>acoburn: I mean, this may be a terrible idea, but it seems like it might simplify a lot of things.11:51
<acoburn>ajs6f: it would simplify a lot of things on the server side, but it will make other things more complex
ajs6f: like indexing in a triplestore11:52
<ajs6f>acoburn: Yeah. That's true.
acoburn: But we can start complexifying Prefer values.
acoburn: Prefer: stick-everything-in-RDF
acoburn: Or something.
acoburn: I'm really talking about the default operation.11:53
<acoburn>ajs6f: changing the default would be an easy way to do this
ajs6f: btw, I just changed a big pile of my code at Amherst from maven to gradle11:54
<ajs6f>acoburn: That's all I'm talking about. Maybe make the default "only ldp triples added to RDF" and provide other info in headers, with other presentations also available.
* dchandekstark joins
<acoburn>ajs6f: you'll weep when you learn what the release process is like
ajs6f: seriously, it's a single command
<ajs6f>acoburn: gradle-to-grave
acoburn: Half the crappiness of releasing Fedora is the byzantine project structures and dependencies.11:55
* dwilcox leaves11:56
<acoburn>ajs6f: once the api goes into its own repo and is versioned independently, things will become easier
ajs6f: for one thing, all the cross-project -SNAPSHOT dependencies can go away
<ajs6f>acoburn: Yes, that will help. Really, the more stuff is broken apart, the better. That also makes it easier to just get rid of stuff, which is my long-term goal.11:57
<acoburn>ajs6f: or at least most of them can
* dchandekstark leaves11:58
* dwilcox joins12:01
* dbernstein leaves
* dbernstein joins12:02
* dwilcox leaves
* coblej leaves12:03
* ajs6f leaves12:08
* ajs6f joins12:09
* manez leaves
* bseeger joins12:17
* ajs6f leaves12:19
* dwilcox joins12:23
* dchandekstark joins12:34
<ruebot>ajs6f,awoods: i think we can do spec sprint in conjunction with import/export sprits. or, maybe better said, one isn't dependant on the other. but there might be overlap with people.12:36
ajs6f,awoods: maybe if the spec sprints were short. no more than a week, we might get some good turn out.
ajs6f,awoods: ...and determine the dependancy chain for the specs before hand12:37
* dwilcox leaves12:53
* dwilcox joins12:57
* github-ff joins13:00
[fcrepo-camel] acoburn opened pull request #119: Deprecate transform option (master...fcrepo-2205) https://git.io/vi2Ev
* github-ff leaves
* coblej joins13:02
* dwilcox leaves13:08
* github-ff joins13:09
[fcrepo-camel] acoburn opened pull request #120: Deprecate the use of the tombstone option (master...fcrepo-2206) https://git.io/vi2ui
* github-ff leaves
* manez joins13:10
* manez leaves13:14
* mjgiarlo leaves13:43
* dbernstein leaves13:50
* dbernstein joins13:51
* mjgiarlo joins13:56
* dwilcox joins14:00
* ajs6f joins14:10
* manez joins14:11
* manez leaves14:16
* youn joins14:35
* bseeger leaves15:01
* peichman1 joins15:03
* peichman leaves15:04
* peichman joins15:06
* peichman1 leaves15:07
* bseeger joins15:10
* manez joins15:12
* acoburn leaves15:14
<barmintor>ajs6f: no more or less than they are now- versions are deletable15:16
* manez leaves