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

Using timezone: Eastern Standard Time
* dchandekstark joins03:24
* dchandekstark leaves03:29
* dchandekstark joins04:26
* dchandekstark leaves04:31
* dchandekstark joins06:28
* dchandekstark leaves06:32
* dwilcox joins07:43
* dwilcox leaves07:51
* dwilcox joins
* dchandekstark joins08:09
* manez joins
* dchandekstark leaves08:13
* dwilcox leaves08:19
* coblej joins08:26
* dwilcox joins08:32
* dwilcox leaves08:47
* dwilcox joins08:49
* dwilcox leaves08:52
* dwilcox joins08:55
* ajs6f joins
* arebenji joins
* whikloj joins08:56
* coblej leaves08:58
* mikeAtUVa joins
* coblej joins09:01
* dchandekstark joins09:02
* coblej leaves09:05
* esm_ joins09:06
* dhlamb joins
* coblej joins09:12
* dchandekstark leaves09:21
* apb18 joins09:26
* coblej leaves09:27
* dchandekstark joins09:32
* coblej joins09:33
* coblej leaves09:35
* coblej joins09:36
* dchandekstark leaves09:37
* coblej leaves09:38
* acoburn joins09:40
* esm_ leaves09:49
* peichman joins09:50
* esm_ joins09:51
* dchandekstark joins09:58
* dchandekstark leaves
* dchandekstark joins
* dchandekstark leaves10:03
* coblej joins10:04
* dchandekstark joins
* coblej leaves10:06
* dchandek_ joins10:07
* dchandekstark leaves10:08
* dchandekstark joins10:09
<ajs6f>Seriously, why do we actually need the fcr:metadata URI "elbow"? Why can't we just return a URI in a header for a created bitstream (as we now do already) and the syntactic form of that URI is not defined by the API? You just take whatever is in there and use it. That's what most of the clients do now, anyway. We would then base the JAX-RS machinery entirely on the properties of that actual persisted resource.10:11
* dchandek_ leaves
* dchandekstark leaves10:13
* dwilcox leaves10:20
* dwilcox_ joins
<apb18>ajs6f: (I may be missing some background context for that observation, but) I can't see any reason to codify any particular URI syntax for this. The fcr:metadata URI is an implementation detail; clients should discover the resource via the 'describedby' header prescribed by LDP for this purpose!10:24
<ajs6f>apb18: Right. That's already true, and I think we're all cool with it. I'm saying we should go ahead and get rid of the actual syntactical accident. Instead of URIs like "mybitstream/fcr:metadata" we should be returning really opaque URIs like "mybitstream/243f4-3h5-j56-56" or whatever. I'm suddenly thinking about this because of the discussion here: https://wiki.duraspace.org/display/FF/Design+-+Mapping+JCR+Constructs+to+URIs and here: htt10:27
* bseeger joins10:28
<apb18>What sort of impact would changing that have on people who have already indexed or bookmarked the old URIs?10:30
<ajs6f>apb18: I don't see why it would have any. We're not talking about changing any URIs in the wild, so far as I can think. Although I certainly might be missing something. What I want to do is (rumbling around in Github);10:31
* coblej joins10:32
<acoburn>ajs6f: it could affect installations that have indexed their Fedora content in a triplestore; but I wouldn't be particularly concerned about that10:33
* dchandekstark joins
<acoburn>ajs6f: i.e. this change may be part of a significant version update, and I'd expect those sorts of updates to potentially involve reindexing
<ajs6f>acoburn: No, it shouldn't change any URIs. Those fcr:metadata URis should continue to work.
acoburn: Just new URIs would change.10:34
<acoburn>ajs6f: oh right, that make sense
ajs6f: plus the camel tooling relies on the link header
<ajs6f>After all fcr:metadata is a perfectly reasonable opaque identifier. I mean, actually, it's kind of crappy as an opaque ID, but "'tis enough, 'twill serve".10:35
acoburn: Right, I think pretty much any tooling I've heard about in the wild actually does the right thing. barmintor or escowles or someone told me that the Hydra gear does.
<apb18>ajs6f: Oh, if that's the case (that existing URIs won't change) then I think there's no concern at all to changing how new URIs are minted10:36
<ajs6f>apb18: That is how I am trying to think about it.
<acoburn>ajs6f: then I'm just registering that I have no concerns
<ajs6f>apb18:acoburn: There's a deeper reason I'm interested in this: the API specs are quickly (IMO rightly) moving to understand a bunch of stuff (versioing, fixity, et al) as LDP containers with additional semantics.10:37
<acoburn>ajs6f: and I'm all in favor of that
<ajs6f>apb18:acoburn: There's a _thing_ about that— you have to couple the lifecycles properly. Those things have to go away when their descriptand does.
* dchandekstark leaves
<acoburn>ajs6f: IIRC, the fcr:versions endpoint is sorta "magic" right now, correct?10:38
<ajs6f>apb18:acoburn: That the "categorical version" of all this stuff (versioning, metadata, fixity, etc.): they are all an LDP resource that has to live only as long as some primary resource.
acoburn: I would have picked that as an example, but it tends to get people confused because our versioning model is the son of JCR and a demon.10:39
<acoburn>ajs6f: in that, a resource w/o versioning enabled doesn't have any pointers to that fcr:versions endpoint
<ajs6f>acoburn: metadata is easier to reason about.
<acoburn>ajs6f: right
<ajs6f>acoburn: Right, but forget the endpoint.
acoburn: A resource without versioning has no associated "version container" resource.
* dchandekstark joins10:40
<ajs6f>acoburn: I want to stop talking about endpoints and talk instead of resources being associated with other resources. In some cases, there is a coupling of lifecycle as well. That's the general machinery. Then we take up instances (versioning, description, etc. ).
<acoburn>ajs6f++10:41
<ajs6f>acoburn: We had this problem with hash URIs. We couldn't understand how to properly make them live and die.
<acoburn>ajs6f: but the lifecycle of hash URIs are tied to the parent, no?10:42
<ajs6f>acoburn: escowles and I agreed at that time that the real solution was to decouple lifecycle management from LDP containment. Sometimes you want things to manage each other's lifecycle with the semantics of true containement. But it would have been too much work then.
acoburn: They are, but it's not containement. You don't get thing ldp:contains thing#stuff.
acoburn: We use JCR containment to impl a lifecycle behavior. That's not wrong, per se, but it's not a general pattern. I want to establish the general pattern, and I want to base it on LDP, not JCR.10:43
<apb18>ajs6f: I like the conversation about resources being associated with other resources, and a general pattern for lifecycle coupling
<acoburn>ajs6f: yes, absolutely10:44
<ajs6f>apb18: That's really the point. It's something that we might be able to express with some kind of LDP machinery. I admit I get tangled up with Direct and Indirect containers.
* dchandekstark leaves
<ajs6f>Then there's the whole tombstone thing. Sigh.10:45
<acoburn>ajs6f: why do we have tombstone endpoints?10:48
ajs6f: I mean, they are convenient for being able to reuse URIs in development, but that's not really kosher for real linked data10:49
* dwilcox_ leaves10:51
* dwilcox joins
<ajs6f>acoburn: I do not know. as far as I can tell, they are some way to give a familiar surface to people who are used to the Fedora2/3 machinery of "ACTIVE/INACTIVE/DELETED". I do not like them and I wish we had encouraged people to use a property instead.10:52
acoburn: But I may be missing some important use case.
<apb18>ajs6f:acoburn Would you imagine this coupling of lifecycles something expressed ontologically? Would the fedora specification need mention something about lifecycle management, outside that which is prescribed by LDP?10:54
<ajs6f>Oh, wow. I just realized that on 26 Aug, when I am supposed to be releasing Fedora 4.6.0, I will be in airports travelling back from Ann Arbor. Hm.10:55
* acoburn leaves
<ajs6f>apb18: That's a good question. It's a generalization of containment from one POV, but from another it's a generalization of https://tools.ietf.org/html/rfc5988 and https://tools.ietf.org/html/rfc689210:56
Are our current description resources LDP containers?10:57
If they are, then immediately, but anyway, at some point, you have to ask about the transitivity of lifecycle management.10:58
If x describedBy y and y describedBy z, it seems intutive that DELETE x deletes z.
And you can have links in that path that are LDP containment. That's going to transfer the lifecycle, but does it transfer the semantics?10:59
So x describedBy y and y ldp:contains z .
DELETE x => z is gone.
But does x describedBy y and y ldp:contains z imply x describedBy z ?11:00
<apb18>ajs6f: They are not exposed as LDP containers. just ldp:RDFSource
<ajs6f>apb18: Okay, but I doubt we'll enshrine that in the API spec. We wouldn't want to, I don't think. And if we get away from the description example to say, versioning, the problem becomes a little more intense.11:01
* dchandekstark joins11:05
<apb18>ajs6f: Oh, right. I'm just saying that in 4.7.0-SNAPSHOT they don't happen to be exposed as LDP containers at the moment. I vaguely recall some past conversation about lifecycles and implications of containership for NonRDFSourceDescriptions, but do not remember when, or what over what media.11:08
I want to say "voice" and "OR '15", but that doesn't seem right.
<ajs6f>apb18: Probably over beer. That's the medium for most Fedora planning.
<apb18>Ha, that's probably true11:10
* acoburn joins
<ajs6f>I've always said that whatever Fedora's problems, it consistently has the best booze of any repository framework out there.
Well, maybe this is all for the sprints on specs after the im/ex work gets done.
I'm sure ruebot would like to see some concentration on that.11:11
* arebenji leaves11:17
* tjohnson joins11:31
* dhlamb leaves11:52
* arebenji joins11:54
* coblej leaves11:55
* dwilcox leaves
* dwilcox joins11:58
* coblej joins12:01
* coblej leaves12:06
* acoburn leaves12:12
* bseeger leaves12:19
* dhlamb joins12:20
* esm_ leaves12:23
* bseeger joins12:34
* ajs6f leaves12:36
* manez leaves12:38
* manez joins12:40
* coblej joins12:41
* esm_ joins12:43
* esm_ leaves12:45
* esm_ joins12:48
* dwilcox_ joins12:55
* ajs6f joins
* dwilcox leaves
* ajs6f leaves12:57
* coblej leaves13:17
* coblej joins13:23
* coblej leaves13:26
* coblej joins
* ajs6f joins13:31
* esm_ leaves13:34
* esm_ joins13:36
* coblej leaves13:37
* esm_ leaves13:45
* esm_ joins13:50
* bseeger leaves14:03
* coblej joins14:05
* bseeger joins14:21
* coblej leaves
* dwilcox_ leaves14:26
* dwilcox joins14:28
* travis-ci joins14:32
* apb18 leaves
<travis-ci>fcrepo4-labs/fcrepo-webapp-plus-cloud#6 (binarystore-in-modeshape - 55761aa : Bill Branan): The build passed.
Change view : https://github.com/fcrepo4-labs/fcrepo-webapp-plus-cloud/compare/abe4cd69cc6f...55761aa1c291
Build details : https://travis-ci.org/fcrepo4-labs/fcrepo-webapp-plus-cloud/builds/153049618
* travis-ci leaves
* apb18 joins14:37
* acoburn joins14:52
* apb18_ joins15:05
* apb18 leaves
* bseeger leaves15:18
* esm_ leaves15:23
* bseeger joins15:34
* apb18__ joins15:44
* apb18_ leaves15:47
* ajs6f leaves15:55
* acoburn leaves16:11
* manez leaves16:15
* manez joins16:19
* dhlamb leaves16:32
* manez leaves16:40
* manez joins16:49
* manez leaves16:51
* whikloj leaves17:01
* dwilcox leaves17:02
* dchandekstark leaves17:03
* dwilcox joins17:04
* peichman leaves
* dchandekstark joins17:05
* arebenji leaves17:06
* dchandekstark leaves
* dchandekstark joins
* dchandek_ joins17:08
* bseeger leaves17:09
* dchandekstark leaves17:10
* apb18__ leaves17:12
* dchandek_ leaves17:13
* manez joins17:26
* manez leaves17:28
* dchandekstark joins17:38
* apb18__ joins
* dchandekstark leaves17:42
* dwilcox leaves18:03
* dwilcox joins18:05
* dwilcox leaves18:31
* dwilcox joins
* dwilcox leaves19:01
* dwilcox joins19:02
* dwilcox leaves20:01
* dwilcox joins20:02
* tjohnson leaves20:07
* dwilcox leaves21:03
* dwilcox joins
* dwilcox leaves21:08
* apb18__ leaves21:25
* esm_ joins21:42
* esm_ leaves23:31
* esm_ joins23:34
* esm_ leaves23:38
* esm_ joins23:52
* esm_ leaves00:20
* esm_ joins00:21

Generated by Sualtam