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

Using timezone: Eastern Standard Time
* dwilcox joins07:31
* coblej joins08:07
* awoods joins08:21
* coblej leaves08:36
* ajs6f joins08:37
* coblej joins08:47
* kefo joins08:55
* coblej leaves08:57
* coblej joins08:58
* peichman joins09:11
* peichman leaves09:15
* peichman joins09:16
* coblej leaves09:35
* coblej joins09:36
* coblej leaves09:43
* ajs6f1 joins09:44
* ajs6f leaves
* coblej joins09:45
* coblej leaves09:50
* whikloj joins10:01
* peichman leaves10:02
* coblej joins
* peichman joins
* peichman1 joins10:06
* dhlamb joins10:08
* peichman leaves10:10
* mikeAtUVa joins10:41
* acoburn joins10:50
* coblej leaves10:52
* coblej joins10:53
* coblej leaves10:56
* coblej_ joins
* bseeger joins
<acoburn>*is here*11:00
<bseeger>*is here*
* ruebot is here
<mikeAtUVa>I'm here too.
* ajs6f is here11:01
* coblej_ is here
* apb18 joins
* dhlamb on my way11:02
* esm_ joins
Elliot's on the phone too
* escowles joins
<bseeger>Ralf's on the line as well.
* escowles is here
<bseeger>couldn't unmute fast enough. :)
* claussni joins11:03
<kefo>Stefano is also eavesdropping.
* dhlamb is on the line
<awoods>dhlamb: are you taking notes?11:06
<dhlamb>i am now
acoburn: So headers?11:11
ajs6f: Yes, headers.
I would like to see that happen for the MODE impl. Not going to do the work for it, though.
<ajs6f>"Blank nodes will not be skolemized at /.well-known/.... If Blank nodes are supported at all, they will be skolemized as hashURIs whose lifecycle is bound to the existence of the resource itself."11:15
That's definitely what the MODE impl should do.
* peichman1 leaves
* ylchen joins11:16
<escowles>@barmintor is on his way
<ajs6f>They aren't part of the spec, and ain't gonna be.11:17
The thing about c&p vs. MOVE is that it requires moving bits over the network.
* peichman joins11:18
<dhlamb>whikloj, was about to ask the same11:19
<ajs6f>URIs are nice.11:20
esm_: Not so fast!
<whikloj>acoburn: as always you are blowing my mind... so much to read and learn11:24
I try to avoid getting into code.11:26
That's just asking for trouble.
<ajs6f>Why "trellis"?
<dhlamb>how dilbert. the name is the most important part11:28
<ajs6f>dhlamb: optics, optics.
Yep, definitinely.11:30
No single-subject rule.11:31
<ajs6f>Next up: Latakia.
<escowles>sorry — very windy here...
i haven't been involved in tpendragon's valkyrie work yet...11:34
i could imagine an implementation that did all the triple-generation on updates and so they'd all be stored in the triplestore11:38
<ajs6f>It's another API for Blazegraph.11:40
<escowles>acoburn++ barmintor++ lots of great stuff here
<whikloj>barmintor++ # very cool11:44
<escowles>dhlamb: trey pendragon11:45
<apb18>Excellent work acoburn, barmintor!
<ruebot>acoburn++ barmintor++
<escowles>valkyrie is: https://github.com/tpendragon/valkyrie11:46
<ajs6f>escowles: What is that?11:47
<escowles>trey experimenting with an alternative to fedora for a hydra backend
<ajs6f>escowles: Ah, cool.
Or for the non-Java types, a test suite.11:48
<acoburn>test suite++11:50
<escowles>i don't have an opinion on what the subject of binary-description triples should be, but <> should resolve to it whatever it is11:52
<ajs6f>The subject has to be the LDP-NR. Anything else is nonsense.11:53
<my:rdf:document> hasWidth 3400^^uom:pixels . is nonsense.11:54
You get triples that don't make any sense then.
The single-subject rule is ours. We shouldn't break RDF interpretation in favor of our rule.11:56
<apb18>Triples that describe the LDP-NR should have the URI of the LDP-NR as subject
<acoburn>I'm going to be using hashURIs for this
<acoburn>such as /my/binary and /my/binary#description
you can't PUT to /my/binary#description and replace triples (you'd replace the binary)11:57
but this way the PATCH operations work properly and it is still in line with the LDP spec
* barmintor_ joins11:58
<dhlamb>acoburn, that makes sense
<barmintor_>ajs6f: don't forget hash URIs!
* barmintor_ jazz hands11:59
<apb18>barmintor_, hash URIs + owl:sameAs?
<kefo>That makes sense.12:00
<ajs6f>barmintor: Hell yes. I liked corned beef hash URIs, tofu hash URIs, all of them.
barmintor: That's actually where acoburn and I were ending up going.12:01
<apb18>Also, Delta doc planning tomorrow 2pm Eastern
<esm_>SSR isn't in the spec either...
<ajs6f>esm_: No, because @barmintor was ready to throw me off a bridge if I did put it in.
<barmintor>whoa hey12:02
<ajs6f>That's what I said!
<barmintor>that's very un-barmintor
<ajs6f>This is basically how it went down: https://www.youtube.com/watch?v=lng-YA-mOc812:03
* ylchen leaves
<ajs6f>with barmintor as the Michael Caine character.
* claussni leaves12:04
<dhlamb>notes are here: ttps://wiki.duraspace.org/display/FF/2017-02-09+-+Fedora+Tech+Meeting12:07
please look them over to make sure i didn't misrepresent something12:08
<esm_>I only ask because I'm curious about the implications of the SSR and the interop between future Fedora implementations. To date, clients interact with the existing Fedora impl as an object repository because of the SSR, but future impls may not have SSR, or have different policies.
* bseeger leaves12:10
<esm_>Is it appropriate for the spec to make a provision for implementations to somehow advertise their constraint policies?
<acoburn>esm_: wouldn't ldp:constrainedBy work?12:11
* coblej_ leaves
<apb18>esm_: ldp:constrainedBy is an HTTP header which links to a document that advertises the constraints. The LDP spec states that this MUST be published if there are such constraints12:13
<esm_>Oh ok, well that's embarrassing :)12:15
<apb18>esm_: So at the moment, SSR is merely a local implementation/policy concern, and not specifically mentioned in any specification
<ajs6f>apb18:esm_: and I doubt whether it will be mentioned anytime soon. I too frightened of barmintor to try.12:18
<esm_>I see. So the Fedora specification's silence on SSR specifically isn't really a concern. And the use of ldp:constrainedBy is required by the Fedora spec.12:19
Yeah, my concerns are assuaged.
<apb18>esm_, yeah, it's mostly a concern to clients who want to create certain kinds of resources that the repository won't let them create, out of policy12:20
* esm_ nods
<ajs6f>Tom Johnson wanted to stuff for DPLA that he said he couldn't because of SSR.12:25
I'm more interested in the move that acoburn and I contemplated-- changing description from a relationship between two resources, to a representation of the described resource.12:26
<esm_>ajs6f: would that change result in an alignment of descriptive LDP-RSs and the single-subject restriction? Or would descriptive LDP-RSs still be exempt from the SSR?12:29
* coblej joins12:30
<ajs6f>esm_: Could go either way. The important immediate point is that it removes the problem in hand. You could, if you want, use the SSR with LDP-NRs without worrying about what subject to use.12:32
esm_: There's another move I am thinking about which veers closer to what barmintor is doing. I can't read the LDP document in any way that prevents me from returning a full dataset (instead of a single) graph to HTTP traffic for an LDP-R.12:34
esm_: Which changes the whole ballgame.
* coblej leaves
<ajs6f>esm_: Instead of RDF triples encoding the properties of an object, RDF quads compose a view of the properties of any number of objects from the point of view of the object on which you made the request.12:35
esm_: There is no problem so difficult that we can't make it worse by parameterizing it.12:36
* esm_ leaves12:43
<kefo>On the topic of the describedBy LDP-RS of an LDP-NR, would it be possible to do away with the fcr:metadata slug and replace it with a hashURI as acoburn is doing with Trellis?12:46
<awoods>kefo: If I understand ajs6f correctly, I believe that is what is is suggesting as well.12:51
<kefo>awoods: Oh, right, I see the comment now. Yeah, that.12:52
<ajs6f>awoods: I made that suggestion quite a while ago, I haven't brought it up since, I'm not sure why you think that's what I am suggesting now (because it isn't), but I thoroughly agree with the idea...12:53
<kefo>ajs6f: What did you mean then at 12:26 eastern?
kefo: We have two URIs now, a resource and its description, right?12:54
kefo: I'm saying go to one URI, and use conneg.
kefo: But I'm not sure that works with LDP.
kefo: It's what I would like, though.12:55
<kefo>ajs6f: I *think* we're talking about the same thing here.
<ajs6f>kefo: Not sure we are. Using hash URIs you still have two URIs. They may resolve to the same request location, so to speak, but you have two URIs.
<kefo>ajs6f: I believe Callimachus uses a single URI with conneg: http://callimachusproject.org/docs/1.4/articles/crud-operations-on-rdf-content.docbook?view
<ajs6f>kefo: I haven't followed that-- I will go take a look.12:56
<kefo>ajs6f: Correction. It uses 2 URIs, but since the second is a hash it's not transmitted, correct? The representation must be triggered by the Accept type.12:57
<ajs6f>kefo: I'm honestly not sure-- I keep seeing "rel=describedby" URIs referred to.
kefo: The question for me is what the boxes in:12:58
mean. If they are abstract types, I don't know why you can't have something that is both. If not, you really can't.12:59
kefo: anyway, hash URIs, I think would be an improvement.
kefo: But I'm going to leave that to acoburn to explore. I want to go with the "LDP-RSes are datasets" idea.13:00
kefo: I have use cases for that that have nothing to do with description.
* coblej joins13:02
<acoburn>kefo: ajs6f: you'd have two different URIs one with a URI fragment and one without, but both would resolve to the same location from the perspective of an HTTP server13:03
so, you'd use conneg (Accept header) to distinguish b/t the LDP-NR and the LDP-RS13:04
* coblej leaves
<ajs6f>acoburn: Right. And I think that is better than what is there now (two URIs that resolve to two different things) but not as nice as one URI, but we may or may not be able to do one URI,
* coblej joins13:05
<ajs6f>acoburn: so the scheme you outline would be an improvement, from my POV.
<acoburn>ajs6f: I *think* the LDP spec says you need two distinct URIs
<ajs6f>acoburn: That's entirely possible.
acoburn: Like I said, I'm not going to put a lot more effort into this. It doesn't seem to accomplish anything.
acoburn: The dataset thing is what interests me,.13:06
<acoburn>ajs6f: yes, that is quite intriguing
ajs6f: how would you define the boundaries of the dataset?
<ajs6f>acoburn: I can then go onto the case where you do a GET on an LDP-RS and get back an entire triplestore and you client crashes. That's the win!
acoburn: You don't. It's just a dataset. But you say that for every named graph, the triples obey the SSR within that graph.13:07
So for the description thing, you can do a GET on any number of descriptor resources. For any one of them, the dataset returned will have a named graph named by the URI of the LDP-NR.That named graph13:08
will have nothing but triples about the LDP-NR, with the URI of the LDP-NR as their subejct.
Each of those datasets might have lots of other graphs. For example, a named graph named with the URI of the descriptor13:09
resource might have provenance info. Who wrote this description? When? Etc.
<acoburn>I've had this idea of bolting a GraphQL client onto the side of a Fedora impl that would fetch/return datasets in a very similar manner13:10
<ajs6f>acoburn: I just want to think about the data right now. Language later.13:11
acoburn: Also whether this really makes sense in LDP. I don't know why not, but there's lots of stuff I don't know.
acoburn: Unless you mean a completely independent data store? Like an LD cache?13:12
<acoburn>ajs6f: yes, I was thinking of this as something like an LD cache13:13
<ajs6f>acoburn: Oh, that's a bit different-- how does that do something similar to what I am talking about?13:14
<acoburn>ajs6f: I guess the similarity is that it maps an HTTP request to a dataset response13:16
<ajs6f>acoburn: but you wouldn't have to care about LDP, right?
<acoburn>ajs6f: from the perspective of the GraphQL client, no
<ajs6f>acoburn: from what perspective _would_ you?13:17
<acoburn>ajs6f: you mean from what perspective do I care about LDP? only from the perspective of the server's API13:20
<ajs6f>acoburn: From the LDP POV, the big constraint is that you have to be able to return turtle and json-ld. So what you do? Merge the graphs a la Cavendish? Select the default graph, or the graph that is named with the request URI?
acoburn: So you are talking about being able to make LDP requests against a server and on the backend, a GraphQL client is querying... something?
<acoburn>ajs6f: just that the GraphQL client queries the LDP server, nothing complicated13:21
ajs6f: we're probably talking about completely different things
<ajs6f>acoburn: So you're putting a GraphQL API over the LDP server?
<acoburn>ajs6f: it's just a thought13:22
<ajs6f>acoburn: I think we are talking about the opposite direction of things.
* coblej leaves14:31
* escowles leaves14:36
* coblej joins
* coblej leaves14:41
* coblej joins14:43
<barmintor>regardless of how our spec arguments are resolved, I want to thank everyone who has contributed for sticking with text documents, and not 3 minute youtube videos, which make me want to stab someone everytime I click on a documentation link for json-ld.14:46
ajs6f acoburn fwiw there is a syntax for named graphs in json-ld14:48
* ajs6f leaves
<barmintor>if TriG were a superset of ttl, I think that too would be a solved problem14:50
but I'm not sure that it is
* ajs6f joins14:55
<barmintor>ajs6f: "if TriG were a superset of ttl, I think that too would be a solved problem / but I'm not sure that it is" was the other bit of that sentence14:59
<ajs6f>barmintor: What? What sentence?15:00
<barmintor>"ajs6f acoburn fwiw there is a syntax for named graphs in json-ld"
<ajs6f>barmintor: Oh, that's cool. But that doesn't change Turtle. There still have to be either a projection or a merge down to a single graph for that.15:01
<barmintor>ajs6f: I was trying to follow up on "From the LDP POV, the big constraint is that you have to be able to return turtle and json-ld. So what you do? Merge the graphs a la Cavendish? Select the default graph, or the graph that is named with the request URI?"
<ajs6f>barmintor: Yeah, I got you. But ^^^ Turtle/
<barmintor>ajs6f: yes, turtle is a problem
<ajs6f>barmintor: Well, a crisitunity.
<barmintor>ajs6f: this is why I was trying to sort out whether TriG was a turtle superset or what
<ajs6f>whikloj: ^^^ eh, eh-- see what I did there?
* mikeAtUVa leaves15:02
<ajs6f>barmintor: wouldn't help if it was (it calls itself an extension): subset or superset, the variance doesn't work.15:03
<whikloj>ajs6f: I'm afraid that joke requires more education than I have received
<ajs6f>whikloj: I AM SHOCKED. That is a classic Simpsons reference.
I totally forgot about that one15:04
<ajs6f>whikloj: glad I could help
<barmintor>ajs6f: it *looks* like the no-brace default graph is isomorphic to a turtle serialization of that graph
<ajs6f>barmintor: I _do_ think it's telling that we are all kind of going to the same place (datasets not graphs)
barmintor: differences, yes, but there's something the same too
<barmintor>ajs6f: weirdly, there is some wiggle room in "unless HTTP content negotiation requires a different outcome"15:07
ajs6f: I think you could also fairly say that an implementation only returns what it can in the format15:09
ajs6f: and advertises availability in other formats
* barmintor shrugs
everything is pointless15:10
<ajs6f>barmintor: hm. yeah, I'm not at first sight sure what to make of that15:13
barmintor: but the explanatory note seems to restrict the import of that statement a good bit15:14
<ajs6f>barmintor: Maybe we need to forge our own future from the rusty chains of W3C process.
<barmintor>ajs6f: I'm just trying to think of what the best way to represent the use case you were describing is: as an LDP-RS that cannot be represented in turtle (so it loses the conneg scoring), or that turtle is an incomplete representation (which is fine, there's no promise that it is, tho you would probably need to specify 409 for PUT-replace in turtle in that scenario)15:17
or merge the graphs and take them apart again on the back end D:15:19
* barmintor leaves15:20
<ajs6f>barmintor: For my case, I could do that, but a) not for the general case, and b) I'm not sure that works for persistence. I think you end up with an exponential problem. But I haven't thought much about this.
* coblej leaves15:23
* coblej joins15:25
* coblej leaves15:45
* coblej joins15:56
* coblej leaves16:07
* coblej joins16:11
* coblej leaves16:15
* coblej joins16:35
* apb18 leaves17:00
* coblej leaves17:15
* acoburn leaves17:31
* peichman leaves17:50
* whikloj leaves17:51
* cbeer leaves18:33
* cbeer joins18:34
* kefo leaves18:44
* ajs6f leaves18:57
* manez_ joins19:16
* peichman joins
* manez leaves19:18
* peichman leaves19:21
* peichman joins19:39
* peichman leaves19:43
* ajs6f joins19:57
* peichman joins20:32
* ajs6f leaves20:36
* peichman leaves20:37
* peichman joins20:47
* peichman leaves20:51
* dwilcox leaves20:58
* peichman joins21:06
* peichman1 joins21:08
* peichman leaves21:11
* peichman joins21:13
* peichman1 leaves
* peichman leaves21:27
* peichman joins21:42
* peichman leaves
* peichman joins
* peichman leaves21:44
* peichman1 joins
* peichman1 leaves21:48
* peichman1 joins22:02
* peichman1 leaves22:09
* peichman joins
* peichman leaves22:11
* awoods leaves23:39
* dhlamb leaves00:33