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

Using timezone: Eastern Standard Time
* deepbook5broo joins00:06
* deepbook5broo leaves
* apb18_ leaves00:23
* apb18_ joins00:25
* apb18_ leaves00:49
* dwilcox joins08:13
* apb18_ joins08:20
* awoods joins08:44
* bseeger joins09:10
* whikloj joins09:11
* peichman joins09:26
* acoburn joins09:29
apb18_: ping
<apb18_>acoburn: pong09:30
<acoburn>apb18_: I'd like to run an idea past you related to storing RDF documents in a Fedora as an LDP-NR
<acoburn>apb18_: so LDP mandates support for TURTLE and JSON-LD09:31
apb18_: but it is silent about support for RDF/XML
apb18_: what if the Fedora _doesn't_ support RDF/XML for LDP-RS
apb18_: that's the basic idea09:32
apb18_: so then, if you have an RDF document (many ontologies are serialized as RDF/XML)
apb18_: you store it as RDF/XML using a Link header w/ ldp:NonRDFSource as the type
apb18_: if you try storing the RDF/XML as an LDP-RS, you'd get an error09:33
apb18_: I was thinking about not supporting RDF/XML in trellis anyway
apb18_: thoughts?09:34
* apb18_ thinks
In the general case,
I am aware of xslt on rdf/xml having been done. It's possible that someone out there in Fedora land might be doing that. So "don't use rdf/xml for ldp-rs" might not be universally acceptable out of the box09:35
as far as a local policy, that might work.09:36
A risk additionally is inadventently creating ldp-nr. Jena model writers, for example, default to rdf/xml if format is not specified09:37
<acoburn>I know that we at Amherst are using XSLT on RDF/XML LDP-RSs, and it is really cumbersome09:38
<apb18_>boy, I can't spell
<acoburn>apb18_: no worries — my font size is small enough that I don't notice
apb18_: there wouldn't be a risk of inadvertently creating an LDP-RS, because trellis would just reject that09:39
<apb18_>So I think the rdf/xml trick can work under controlled circumstances, but might be problematic in the wild
<acoburn>apb18_: I'm relying more strongly on link headers for resource creation
<apb18_>acoburn: I think that's something the LDP spec is weak on: When to create an LDP-NR. I think that's because it presumes that RDF is LDP-RS, anything else is LDP-NR; end of story09:40
* yamil joins
<acoburn>apb18_: I agree; LDP assumes that an RDF resource is an LDP-RS09:41
apb18_: I also wonder about the possibility of supplying a Prefer header to relax the single-subject rule09:42
apb18_: that would be allowable by the Fedora spec
apb18_: but it would be very application-specific
apb18_: I am also very hesitant to relax the single-subject restriction09:44
<apb18_>Yes, it would be application-specific. Even if there were something codified in the spec, the current fedora impl won't be able to comply for technical reasons
acoburn: Why is that (hesitant to relax single subject). I've never understood the use cases around that09:45
<acoburn>apb18_: my concern about that is that if you create /foo and /bar, but you have triples under /bar that describe /foo09:47
<apb18_>Another way to say it - I've never seen anything in print (book article) that argues for such a policy. That resources *should* at least describe themselves, sure
<acoburn>apb18_: however….
apb18_: I am not necessarily against the idea of having resource subjects be completely out-of-domain
apb18_: i.e. resource /foo has subjects from, say: http://example.org/myns09:48
apb18_: and isn't that part of your use case w/r/t storing ontologies?09:49
<apb18_>Yes. w.r.t storing ontologies, it will be the case that subjects will be under the ontology domain.09:51
but in any case, stepping back a little bit09:52
Even though I tend to see the single subject rule as strictly problematic in general; it's part of the fedora 4 culture, and repositories will have such restrictions.09:53
So as long as that's the case,
it would be really nice if the spec carved forward a path for depositing RDF as LDP-NRs that could be relied upon..09:54
without resorting to, say `application/octet-stream`09:55
<acoburn>apb18_: I agree; my main consideration with this suggestion is to avoid application/octet-stream
apb18_: in any case, I'll keep thinking about this09:58
apb18_: thanks for the feedback!
<apb18_>Yeah, I think about this as well, but a nice and general solution has been elusive so far!
Thank *you* for thinking about this. Since it appears that Hydra persists RDF as an LDP-NR under certain circumstances, it may be a more wide-spread issue than has been previously thought.10:02
* apb18 joins10:25
* apb18_ leaves10:28
* bseeger leaves10:48
* bseeger joins10:52
* kefo joins10:58
* github-ff joins11:09
[fcrepo-camel-toolbox] mohideen opened pull request #134: Updated Solr and Triplestore routes to reduce redundant fcrepo requests. (master...indexing-performance) https://git.io/vDHHC
* github-ff leaves
* HackmasterA joins11:33
* HackmasterA leaves11:34
* apb18_ joins12:02
* apb18 leaves12:05
* bseeger leaves12:55
* manez leaves13:18
* manez joins13:23
* peichman leaves13:28
* peichman joins13:30
* bseeger joins13:36
<awoods>bseeger/escowles: https://hangouts.google.com/hangouts/_/event/c1glu6soq43r1rr6ou17qtobug814:00
* acoburn leaves14:48
* acoburn joins15:16
* dwilcox leaves16:45
* dwilcox joins16:47
* dwilcox leaves
* dwilcox joins
* dwilcox leaves16:48
* acoburn leaves16:49
* coblej joins17:01
* coblej leaves
* bseeger leaves
* peichman leaves17:23
* apb18_ leaves17:33
* whikloj leaves18:01
* yamil leaves19:05
* kefo leaves19:18