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

Using timezone: Eastern Standard Time
* peichman joins06:57
* dwilcox joins08:37
* dwilcox leaves08:39
* dwilcox joins08:40
* dwilcox leaves08:42
* dwilcox_ joins08:43
* awoods joins08:54
* dhlamb joins08:57
* bseeger joins09:02
* yamil joins09:26
* bryjbrown joins09:43
* bryjbrown leaves10:21
* whikloj joins10:53
<peichman>custom emoticons? madness! :-)11:05
* apb18 joins11:10
* dshalvi joins11:11
<apb18>dbernstein, yup - I still need to do API-X. Will aim to do that today11:12
* kefo joins11:27
<bseeger>I'm having a really hard time hearing Danny - is it just me?11:33
<awoods>bseeger: I seem to be hearing him fine11:34
<whikloj>bseeger: headphones make all the difference11:51
* whikloj leaves
* whikloj joins
gotta run, see you all later!12:01
<apb18>Essentially this implementation is using it as a "server-managed triple"
so we'd be within our right to validate it.. or not
That particular triple likely has no specific significance in any other implementation
<awoods>apb18: yes, quite likely12:02
<apb18>i.e. changing it would NOT result a change in an LDP-NR response
Is there a "within the specs" way of updating a mimetype of an LDP-NR, outside of re-uploading it, albeit with a new Content-Type?12:03
<awoods>The spec is silent on mimetype details
<apb18>Another way of asking it - do the specs suggest a different way to update the Content-Type of an LDP-NR, or is it inherently implementation dependent?12:04
Yet another way: Would a server have to invent its own way to update the mime type of an LDP-NR without having to re-upload it via PUT?12:05
<awoods>apb18: I think so, yes.
It can be reasonably safe to assume that the provided mimetype on upload of the 'content-type' header is used ...12:06
<bseeger>should the ebucore:hasMimeType become a server managed field?
<awoods>after upload, it is implementation-specific
on how to update that value
bseeger: I don't think so
<whikloj>bseeger: I'd say no as well12:07
<awoods>bseeger: because folks sometimes want to change the mimetype
<whikloj>awoods++ # Islandora did a lot of text/xml -> application/xml
<awoods>but to apb18's point... the mechanism for changing mimetypes is likely implementation-specific12:08
<apb18>What is the definition of "server managed"? I think it fits - the server creates and updates "i.e. manages" it for you
Isn't that akin to, say, last modified date?
<awoods>apb18: users can not directly update server-managed-triples
apb18: which would be problematic in this case
<apb18>hm. I thought it was the case that a server *may* disallow or ignore updates to server-managed triples12:09
not that it MUST disallow.
Besides - didn't the import/export work make the policies on that more lenient?12:10
<awoods>re:import/export, yes
it is now possible to allow users to update SMTs
<apb18>Therefore, using the "walks like a duck, talks like a duck" analogy.. could we not consider ebucore:hasMomeType to be of the same ilk?12:11
a "server managed triple"?
I think it makes a lot of sense in documenting what it is and does, and setting the expectation that it is one of the "special ones"12:12
<awoods>the ebucore:hasMimetype is more like a duckalope
<apb18>.. and allows the server latitude to validate it if it wants
<bseeger>for reference: https://www.ebu.ch/metadata/ontologies/ebucore/index.html#hasMimeType12:13
(sorry, but this seems appropriate: http://davidkorenblat.wixsite.com/graphic-arts/project01)12:14
<awoods>apb18: are you suggesting we do the validation... as long as we also document the behavior?12:15
bseeger++ that is what I am talking about
<apb18>Not necessarily - I'm saying that it *is* a server-managed triple, and as such the server would be within its rights to validate. So we can have a conversation that focuses strictly on the merits of doing so, rather than "can we do so in the first place"12:16
I'm actually on the fence12:17
<awoods>apb18: I am not sure if it is critical to this conversation, but I believe ebucore:hasMimetype does not behave like an SMT... because users can update it.12:20
<bseeger>awoods: but before the bug fix was put it, it was a predicate that the server relied on the value of… it definitely blurs lines as to if it is a SMT or not. But if the value of a triple can throw an error… we either need to not rely on that predicate for something or we need to validate it and somehow indicate to users its 'specialness'.12:25
<awoods>bseeger: agreed. And documenting that behavior seems absolutely appropriate.12:26
<bseeger>And we could just leave the code as is (now, after my accepted PR). Clients can still set the mime type to whatever and if it's bad, it gets ignored and treated like an octet stream.12:27
<bseeger>that makes it less server managed triple like
* kefo leaves12:32
* kefo joins12:33
* whikloj_ joins12:44
* whikloj leaves
* peichman leaves12:54
* dhlamb leaves12:57
* dhlamb joins12:58
* bseeger leaves14:07
* peichman joins14:41
* bseeger joins15:01
* bseeger leaves15:02
* bseeger joins15:12
* jpr joins15:18
* dshalvi leaves15:23
* bseeger leaves16:02
* dwilcox_ leaves16:03
* dwilcox joins16:13
* bseeger joins16:14
* jpr leaves16:15
<dbernstein>So it sounds like the notes that I just sent out on fedora-tech may have been inaccurate. Sounds like we are saying no to validation on updates to ebcore:hasMimetype. Is that right?16:19
Or are we still discussing it?16:20
<whikloj_>dbernstein: I thought we were going to do that, but perhaps I misunderstood as well. awoods? bseeger? apb18?16:22
<bseeger>I think it's still a little under discussion… we left the meeting with yes, validate, but then subsequent irc conversation around whether or not it was a server managed triple ensued16:24
<dbernstein>okay - that’s where I thought things were falling (if they haven’t yet completely landed)16:25
<bseeger>one option is to leave it as is - if they enter a bad mimetype, we leave it as is, ignore it and treat it like "application/octet-stream"
a second option is to validate it and deny the POST/Sparql update if it is bad16:26
<awoods>ditto to bseeger's comment: "we left the meeting with yes, validate, but..."
bseeger: I am not seeing the downside of validating on PATCH/PUT/POST16:27
* dwilcox leaves
<awoods>bseeger: if things are going to blow up... it seems to make sense for that to happen on update.
<bseeger>awoods: true - they won't blow up anymore, thankfully. :)
awoods: to me, it seems like the first time we're _semantically_ validating a predicate outside of a SMT.16:28
<whikloj_>bseeger: You are worried this is the edge of the "slippery slope"?16:29
<bseeger>awoods: that's where my hesitation comes in and just want to make sure we think through it all.
whikloj_ - yeah, sort of
could it be?
<whikloj_>bseeger: I'm not sure16:30
bseeger/awoods: Not to start the discussion here again, but it appears in this case the client is throwing garbage at Fedora. The question is whether it is Fedora's job to filter that garbage
<bseeger>whikloj_ right - exactly - that is the question16:31
<awoods>whikloj_: if Fedora has expectations on that garbage, then it is within Fedora's rights to validate (not filter) it.16:32
<bseeger>the fact that we're relying on a user supplied triple for logic — do we do that elsewhere? — is what makes this a little challenging.
<awoods>bseeger: I would suggest that it actually makes things less challenging... more clear16:33
<whikloj_>yeah that is maybe the larger problem, why do we use what they say it is. What if I put up a Tiff and say its a MP3?
<awoods>bseeger: Fedora has expectations on the provided mimetype and should therefore ensure its correctness16:34
<whikloj_>awoods/bseeger: and this ebucore:hasMimeType is created from the provided Content-Type header correct?
<bseeger>I think if it's not set, something set's it somewhere…16:35
but it's not based on Content-Type header
<awoods>bseeger: I though that on-ingest, it is using the Content-Type header.16:36
<bseeger>oh, um, I misspoke. :)
mis-wrote that is
yeah, what awoods said ^^
<whikloj_>So on ingest it uses the Content-Type header for the binary, but you could alter it later16:37
whikloj_/bseeger: this ticket may be of interest: https://jira.duraspace.org/browse/FCREPO-153216:38
<bseeger>here is the ingest - and contentType is the Content-Type header: https://github.com/fcrepo4/fcrepo4/blob/94ad29863f90864d12e58f149d533bcf635bf5b0/fcrepo-kernel-modeshape/src/main/java/org/fcrepo/kernel/modeshape/FedoraBinaryImpl.java#L166
<whikloj_>awoods/bseeger: So then on ingest we can validate the Content-Type header against RFC-2045, but if you later PATCH it to something wrong that is your fault16:39
<awoods>bseeger: it is all you16:40
<whikloj_>Section 5.1 - https://www.ietf.org/rfc/rfc2045.txt
<awoods>whikloj_: bseeger has demonstrated that bad content-types are rejected by the servlet container... and never make it to Fedora16:43
whikloj_: The issue at hand only relates to post-ingest updates
Then tell them too bad, stop sending bad data and expecting Fedora to fix it16:44
<bseeger>awoods, whikloj_: given 1532, I guess it's down to validating the triples and squaking if mimetype is semantically bad
<awoods>bseeger: I am on board with that16:45
<whikloj_>If we do ebucore:hasMimeType can we also do ebucore:hasContainerMimeType ?
<awoods>bseeger: maybe a 409 Conflict
what's that?
<bseeger>anything else you want whikloj_?
<awoods>whikloj_: does such a predicate exist?
<bseeger>(and actually, I don't now what that is, either)
"To prpovide the Mime type of the Resource."16:47
I'm putting on my ajs6f hat and noting that without a clear definition of what is allowed in this predicate we are limiting it.16:48
<bseeger>that website makes me unhappy — it's so… unclear.16:49
<whikloj_>I would say if we need a mimetype for Fedora, we should be storing it as a server managed-ish property. Take the provided one on POST/PUT/PATCH and validate it to our own
<bseeger>But I can't see anywhere that a range is stipulated (and it would only be a string literal, I think, anyways)
by validating it to our own - where would we get our own? Check the file ourselves?16:50
<whikloj_>So if I say <> ebucore:hasMimeType "bobs burgers" it sticks to the resource, but we put application/octet-stream in our internal propertu
<apb18>So what does "internal property" mean. One that is under the fcrepo: namespace?16:51
<awoods>whikloj_: have you reviewed: https://jira.duraspace.org/browse/FCREPO-1532 ?
<bseeger>ah, I see - if what they say isn't a correctly formatted mime type, fallback on application/octet-stream
<whikloj_>awoods: I have not reviewed all those PRs and tests if that is what you mean, is there a discussion I am missing?16:52
<awoods>whikloj_: I am just pointing you to the original issue that implemented the current functionality... and rationale16:53
<whikloj_>awoods: oh ok, and I see the rationale for allowing updates to the mime-type. But in the context of an external ontology that is not clearly defined I am uncomfortable excluding values based on what we think should be allowed.16:54
<apb18>In general, I tend to think that "use someone else's ontology for internal purposes" is problematic.
<whikloj_>apb18: agreed16:55
But we are...so that is why I was wondering about storing the Fedora copy of the mime-type separately
<awoods>whikloj_/apb18: that makes sense...
<whikloj_>If I upload a file with Content-type: image/jpeg then store image/jpeg
<awoods>whikloj_/apb18: ...but we do want to reuse ontologies for interop
<whikloj_>If I patch with image/gif, set to image/gif16:56
If I patch to flaming sambuka, then update the RDF but either leave the internal as image/gif or revert to application/octet-stream
<apb18>awoods: I tend to think "ontologies for interoperability" should be a user-space thing.16:58
<whikloj_>Either that or we have to return an error because we won't accept the operation. In which case I would say 400 Bad Request?
<bseeger>and we wouldn't necessarily have to publish this internal mime type… or would we?
<whikloj_>bseeger: no
bseeger: we don't tell people we use ebucore:hasMimeType right now do we?16:59
<apb18>i.e. a user of the repository explicitly buys into the ontolog(ies) and uses them intentionally.
<bseeger>whikloj_ we add it to the rdf and return that info for the fcr:metadat17:00
<apb18>there's no standard (or recommendation) that repositories use/manage ebucore:hasMimeType
<whikloj_>bseeger: and it would be under the fedora: namespace as a true server managed triple, we just consider client input when setting its value17:01
or we can validate ebucore:hasMimeType entries...but I do agree with bseeger that it feels like the edge of some sort of slope17:03
<apb18>I'd also say "...and no longer do anything with ebucore:hasMimeType"
<bseeger>fwiw, I found this: https://pro.europeana.eu/files/Europeana_Professional/Share_your_data/Technical_requirements/EDM_profiles/Technical%20Metadata%20properties_20150217.pdf17:04
<whikloj_>apb18: the problem there becomes how do you change the mime-type then
<bseeger>which says for ebucore:hasMimeType: The main MIME types as defined by IANA: e.g. audio, video, text, application, or a container MIME type.
<whikloj_>bseeger: ooooo EDM, they like solid ontologies
<apb18>*my* ideal repository would not have any server-managed triples, for what it's worth.17:05
whikloj_: If one does create a fcrepo:hasMimeType" server-managed triple, then interact with that instead
<bseeger>I need to head home, but I'll be thinking some more on this.17:06
but before I go, would it be crazy to have fcrepo figure out mime type… (well, as much as it can… I realize it's probably a non-starter)17:07
<whikloj_>bseeger: probably
bseeger: but based on that PDF from EDM if ebucore:hasMimeType is defined like they say. I have no issue validating it17:08
<awoods>bseeger: potentially... as a separate feature from what is being discussed here
<whikloj_>However if we do what EDM has done then I think we might be getting into the area of having a Fedora metadata profile to explain how we expect data17:09
<bseeger>whikloj_: so going down the road of let them set it and we return a 4XX error if it's incorrect?
<whikloj_>bseeger: Yes, but I think what that document says is how EDM views those properties. Because I don't see anything that clear from EBU17:10
<bseeger>ah, I see what you're saying.
<whikloj_>That document is what Islandora and Samvera needs to output to allow for interoperability :)17:11
<apb18>validation by checking content (eg. via tika) should likely be an external service, or something like a "value add" provided by API-X
<apb18>but anyway, I *wish* there were a way, implied by the spec, to update Content-Type in a non-implementation-specific way
<awoods>apb18: that could be a useful suggestion... if you have thoughts.17:14
<apb18>something like "external content, but pointing to itself as the source of content" maybe?
<bseeger>so for now, I'd like to go down the road of validating the hasMimeType triple - any major objections to that?
<awoods>no objection here17:15
<apb18>awoods: I still think that Content-Location could be an appropriate way to handle external content. My reading of the specs differ from the spec editors, though. I'd really like to e-mail the IANA HTTP list to get their opinions.17:16
<bseeger>have a nice evening everyone!
<apb18>then updating mime type could be something like:
* yamil leaves
<whikloj_>bseeger: night
<apb18>Content-Location: <URI of resource>
Content-Type: <new content type>17:17
in a PUT to an LDP-NR at <URI of resource>
* bseeger leaves
<awoods>apb18: an empty-body PUT?
<apb18>Yes, also with a Prefer header17:18
(in the spirit of those discussed in the redirect/proxy thread)
<awoods>apb18: Let's get that topic higher on next week's tech agenda.17:19
apb18: empty-PUT with headers could be an interesting way to update modify the Content-Type.17:20
<apb18>I don't remember bpennel's write-up. Something like Prefer: content-resolution=copy
<awoods>apb18: I need to revisit the Content-Location counter-arguments... but they seem to be deeply rooted.17:21
<apb18>I haven't been convinced that Content-Location is a bad idea by what I've seen. It just makes things so much more elegant and flexible.17:23
I don't think it's bending the rules by too much :)17:24
certainly no more than the external body mime type.
<awoods>apb18: Yes, I need to revisit the topic. Some of the editors feel like that line of argument is retreading old discussions.17:26
<apb18>That's why I'd like to query the IANA list, or otherwise get input from HTTP experts.17:28
* peichman leaves17:32
* apb18 leaves17:39
<dbernstein>re putting the mimetype discussion higher on the agenda for next week: +1 and noted.17:40
I’m sorry I missed the discussion. It was a spicy read.
<awoods>dbernstein: and the redirect/proxy topic17:41
* dhlamb leaves17:52
* whikloj_ leaves18:00
* apb18 joins18:02
Today’s tech meeting notes: https://wiki.duraspace.org/display/FF/2018-02-01+-+Fedora+Tech+Meeting
<apb18>awoods: I'll aim to e-mail the HTTP working group list and see if there's any advice re: the stuff we're allowed to do with Content-Location with Prefer directives.18:05
ideally before the tech call.
<awoods>apb18: thank you for doing that... bringing another perspective to the conversation.18:06
<apb18>no prob!18:07
* travis-ci joins18:44
ualbertalib/fcrepo4-oaiprovider#149 (fcrepo_4.7.4 - be8d067 : Jeffery Antoniuk): The build passed.
Change view : https://github.com/ualbertalib/fcrepo4-oaiprovider/compare/b5babd5b60df...be8d0679531d
Build details : https://travis-ci.org/ualbertalib/fcrepo4-oaiprovider/builds/336346731
* travis-ci leaves
* kefo leaves19:09
* apb18 leaves19:40
* awoods leaves22:10
* travis-ci joins22:47
fcrepo4-labs/Fedora-API-Test-Suite#74 (External-Binary-Content-Tests - bcb9d1c : Jorge Abrego): The build passed.
Change view : https://github.com/fcrepo4-labs/Fedora-API-Test-Suite/compare/7b4b624b6791...bcb9d1c03bd4
Build details : https://travis-ci.org/fcrepo4-labs/Fedora-API-Test-Suite/builds/336401774
* travis-ci leaves
* travis-ci joins23:01
fcrepo4-labs/Fedora-API-Test-Suite#75 (External-Binary-Content-Tests - 69f6bae : ibr-jabrego): The build has errored.
Change view : https://github.com/fcrepo4-labs/Fedora-API-Test-Suite/compare/bcb9d1c03bd4...69f6bae6c8cf
Build details : https://travis-ci.org/fcrepo4-labs/Fedora-API-Test-Suite/builds/336404162
* travis-ci leaves

Generated by Sualtam