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

Using timezone: Eastern Standard Time
* esm_ leaves01:30
* esm_ joins01:46
* esm_ leaves01:56
* apb18 joins07:20
* dwilcox joins07:37
* apb18 leaves07:40
* manez joins07:57
* apb18 joins07:59
* manez leaves08:02
* dwilcox leaves08:54
* dhlamb joins08:55
* dwilcox joins
* whikloj joins09:03
* acoburn joins09:04
* cmills joins09:19
* manez joins
* dwilcox leaves09:24
* ajs6f joins
* dwilcox joins09:25
* dhlamb leaves09:33
<acoburn>apb18: is today's API-X mtg at 1pm ET?
<apb18>acoburn: Yes, same time as usual.09:34
* esm_ joins
<ajs6f>apb18: acoburn is going to give you far more useful feedback than I am, but one thing I would say: do you really need to abstract that much over ontology operations? Is there an immediate use case for switching from Jena? (To what? RDF4J? OWL API?)
<acoburn>apb18: that's what I thought — I won't be able to make it today :-(
<ajs6f>apb18: And yes, I am biased.09:35
<apb18>acoburn: Sorry to hear that! will make note of it09:36
ajs6f: Yes, I kind of had the idea that eventually we'd want to try one of the owlapi reasoners like hermit, or pellet09:39
ajs6f: although Jena is so easy and practical; probably does 99% of what we need if I were to guess09:40
<ajs6f>apb18: Nothing against Hermit or Pellet, but a) do you really have use cases for that level of inference, and b) check the licensing on those guys. You might want to factor that in.09:41
* dhlamb joins
<ajs6f>apb18: https://github.com/Complexible/pellet/wiki/FAQ#jena-interface09:42
<acoburn>apb18: do you know why the karaf-maven-plugin uses a non-existent namespace for the generated features files?09:44
apb18: i.e. 1.4 (IIRC, the latest version is 1.3)
<apb18>I think to (a) it's 'no, but wouldn't want to rule it out if someone did". I don't feel I know the implementations and their limitations/strengths/performance tradeoffs well enough to put a stake in the ground.
ajs6f: So in your opinion, is the Jena API probably sufficient?09:45
<ajs6f>apb18: That depends on our meaning for "sufficient". Not being a jerk, I really don't have a sense of the ultimate extent of demanded functionality. If you are just a bit beyond RDFS, then prolly.
<apb18>acoburn: huh, that's... interesting. You're right, there is no 1.4 schema.09:46
<acoburn>apb18: I would think the Jena API would suffice — unless you wanted to experiment with commons-rdf
apb18: though personally, I'd wait on commons-rdf until they have a release with a Jena parser
<ajs6f>acoburn:apb18: If you really don't care about triples, but about axiomata and inference, then OWLAPI might actually be _more_ appropriate and pleasant.
* esm_ leaves
<acoburn>apb18: nevermind about commons-rdf — that has nothing to do with inference09:48
<ajs6f>apb18:acoburn: Clearly API-X is interested in inference. I think some more specificity there will answer the "use a framework directly" / "use a general API" question.09:49
RDFS? RDFS+? OWL? If so, which profile? Which features?
Something totally different and custom (not crazy, if you know exactly what the basic mechanics needed are and they are simple, you might able to implement it directly or in some RDF framework more performantly than using the sledghammer of OWL).09:51
<apb18>ajs6f, acoburn: At this point, as far as ontologies are concerned, the only part that cares about triples is inside the black box of the 'OntologyService', and the only aspect about OntologtService that anything else in API-X cares about (e.g Extension binding) is a inference: Can we infer that this instance (object in repository) is a member of some class;09:52
* esm_ joins09:53
<ajs6f>apb18: Instance checking. That's it?09:57
* peichman joins09:59
<apb18>ajs6f: Yes, that's it. OWL to describe a class, extensions specify a class of resources they are applicable to, and reasoning to infer if a resource is described by that class10:00
* esm_ leaves10:03
* esm_ joins10:11
<apb18>ajs6f: It's kind of an analogy to SSWAP. In their situation, they use such reasoning to infer appropriateness of resources as arguments of services. In the context of extension binding, we're inferring about the appropriateness of repository resources with respect to the intentions of an extension.10:12
<ajs6f>apb18: in a hangout right now, but trying to follow you as well (and a slack conversation)10:13
apb18: Do you have to do subsumtion?10:14
apb18: like do you explicitly call out every type of a resource, or do you expect to be able to reason that service x is available for resources with type y, and type z < type y, and resource q is type z, so service x is available for resource q.10:22
<apb18>ajs6f: Oh, no worries. I cannot multitask like that :). Regarding subsumption: probably? This was to address the very practical problem from Fedora 3 of objects having to explicitly call out an awkward list of content models10:24
* dwilcox leaves10:25
* dwilcox joins
<apb18>ajs6f: Right, so part of the intention of binding via reasoning is to avoid having to explicitly call out every type; which I think many of the stakeholders regarded as a problem
<ajs6f>apb18: Okay, so that's subsumption and instance checking. But so far I'm not hearing about OWL-ly stuff like complicated class constructions (con/disjunction, negation etc.).10:27
apb18: This is RDFS, so far.10:28
<apb18>ajs6f: Great. How about I link to one of the examples in the integration test (just a sec)10:30
(just a sec, on phone)10:36
^^ That says a test:RemWithOrderedAggregation is an ore:ResourceMap that ore:describes an ore:Aggregation that has iana:first and iana:last relationships to ore:Proxies10:47
* acoburn leaves10:51
* bseeger joins
<apb18>That's about the extent of complexity of ontology at the moment. We want objects like this to be inferred test:RemWithOrderedAggregations: https://github.com/birkland/fcrepo-api-x/blob/devel/fcrepo-api-x-integration/src/test/resources/objects/object_with_ordered_collection.ttl
* dwilcox leaves
<apb18>Jena micro is sufficient for inferring that10:52
* dwilcox joins10:53
<apb18>ajs6f: or, more specifically, OntModelSpec.OWL_MEM_MICRO_RULE_INF10:54
ajs6f: So I think we're in "RDFS + a tiny bit of OWL" territory?
<esm_>Yeah the author of http://workingontologist.org/ calls it RDFS+, IIRC10:56
* dwilcox leaves
<ajs6f>That's what I referred to above. Some other triplestores do it natively too, like Blazegraph.10:57
* arebenji joins
<ajs6f>Although I'm not sure we couldn't grind this down to RDFS.
* dwilcox joins10:58
<ajs6f>ruebot: The instance you left, the audio improved dramatically. You must have been sucking up bandwidth or something.
* ruebot snorts10:59
<ajs6f>ruebot: Ah, that snort came though crystal-clear.
<ruebot>ajs6f: must have been all the rick james i listened to yesterday11:00
* ruebot here
For the same remark.
<ajs6f>what's the link for the meeting?11:01
<dhlamb>folks, got lots of medical stuff to get to, can't make it :(
<dhlamb>interested if anyting comes up around ETags
i'll be lurking later and asking questions
<bseeger>*is here *11:02
* ajs6f is here
* jackhill waves.11:05
I just joined the call
* barmintor joins11:06
* barmintor is here
<barmintor>I'm interested, but I'm not in a position to commit11:15
<ajs6f>barmintor: I'll take that as committment.11:16
<barmintor>I'm already can't-commit committed to other things
<ruebot>intuitiveness -- 2117 i think that was the single term to summarize that ticket.11:17
<ruebot>s/ben/max headroom/g11:20
* escowles joins
i created the ticket for the LDP/HTTP spec conflict: https://jira.duraspace.org/browse/FCREPO-212211:21
<barmintor>would maybe be cool to say that impls of the versioning spec should link to URI-M of other LDP resrouces when available, but the not-knowing of availability is complicated
complicating, rather
no swooping... no one is swooping
<ajs6f>barmintor: is this the distinction between history and version API that we talked about?11:24
<barmintor>ajs6f: I don't remember.
<ajs6f>barmintor: resource vs. reprsentation
<ajs6f>barmintor: the not-knowing is because the APi doesn't define how history works
<ajs6f>barmintor: Only how you retrieve representations of it11:25
* manez leaves
<barmintor>ajs6f: but it would be difficult for an impl to know how to deal with variously versionable resources, whereas it would be relatively easy for a client to notice Memento headers and re-ask for the memento time as appropriate
<ruebot>am i still on the line?
i just have a bunch of static.
<escowles>i got dropped
<jackhill>me too.
* ruebot phew
<apb18>I can hear11:26
<barmintor>see this is why we don't have ISPN anymore
<ajs6f>barmintor: Sure, but that's why we can't spec it, right?
<barmintor>ruebot: I can hear you
ajs6f: yes
<barmintor>ruebot: yes
<jackhill>back on
<barmintor>what happens when performance stops being pcdm, and starts getting real11:27
<ajs6f>barmintor: The tone of the discussion was that the line between things-we-can-spec and things-we-cannot should neatly outline the world of representations. (REST)
* manez joins11:28
<barmintor>I can type it
<barmintor>there's a PR open for the id translation refactor, ajs6f and acoburn are evaluating it
it's large
* dhlamb leaves
<barmintor>there's a v experimental branch refactoring container membership triple gen11:29
escowles is looking at that
<ajs6f>barmintor: I can't speak for acoburn, but I think i'm done looking at your PR.
<barmintor>there is, unless we commit to writing a MODE index impl, a floor for certain use cases
<ajs6f>barmintor: Because of retrieving nodes?11:30
<barmintor>that is equal to the time it takes to retreive an uncache member node x the number of members
ajs6f: yes
ajs6f: and there's no bulk fetch into the workspace cache in the existing index impls
<ajs6f>barmintor: so no help there
<barmintor>not without more programming stuff11:31
<ajs6f>barmintor: maybe ISPN prevents that?
<barmintor>ISPN is out of the picture
yeah I think all y'all should read this IRC stuf
<ajs6f>barmintor: I AM READING THE HECK OUT OF IT.11:32
<barmintor>you can see me pestering MODE at https://developer.jboss.org/thread/271851
<ajs6f>You had to get into pestering mode.
Does anyone want to talk about soething other than Fedora?11:34
We talk about Fedora too much o these calls.11:35
<barmintor>how do people manage faculty submission of "large" dataset files
barmintor: We avoid promoting them and eventually they go away.
<ajs6f>barmintor: What is large?
<ruebot>barmintor: it rarely happens, and i just usually intermediate it.
<barmintor>brb changing my avatar everywhere
<ajs6f>I love the wary look in those eyes.
* jenlindner joins11:47
* bseeger leaves
* dwilcox leaves12:01
* escowles leaves12:03
* barmintor leaves
* escowles joins
* dwilcox joins12:22
* dwilcox leaves12:25
* esm_ leaves12:26
* dwilcox joins12:28
* dwilcox leaves12:30
* esm_ joins12:31
* esm_ leaves12:32
* dwilcox joins
* esm_ joins12:33
<jjtuttle>barmintor: We ask users to provide an SIP using an extension of the Bagit spec. They transfer that to us via portable media, Dropbox, FTP, Box.net, etc.12:34
* esm_ leaves12:35
<jjtuttle>barmintor: we may one day allow users to deposit directly, but I oppose it.
* bseeger joins12:36
* esm_ joins12:46
<ruebot>https://wiki.duraspace.org/display/FF/2016-08-18+Fedora+API+Extensions+Meeting -- is there an API-X call today?12:58
* ddavis joins
<apb18>ruebot: Yup, like clockwork12:59
* ruebot dials in
* ruebot is here13:00
<bseeger>*is here*13:01
* esm_ leaves13:02
<dwilcox>I'm here
* esm_ joins
<ruebot>dhlamb is out this afternoon too13:03
anybody got a link to the agenda handy?13:04
* Ruth_ joins13:10
<ajs6f>dwilcox: Is awoods traveling?13:28
<dwilcox>ajs6f: He is on vacation until Wednesday
<ajs6f>dwilcox: ok thnx
<ruebot>the pcdm ontology lives in the same space as the fedora ontologies13:33
<whikloj>ruebot: Sorry for the delay, minutes are up - https://wiki.duraspace.org/display/FF/2016-08-18+-+Fedora+Tech+Meeting13:34
<ruebot>as in, the same ec2 instance
whikloj++ #thank you!
* ajs6f leaves
<ruebot>apb18: makes sense to me13:35
* acoburn joins13:36
apb18: I'm here now13:37
<ruebot>apb18: do it :-D13:43
* br2490 joins13:45
* arebenji leaves13:47
* jenlindner leaves13:51
<acoburn>yes, pax-exam++
* ruebot has to drop13:54
* jenlindner joins13:57
<esm_>I think it would be good to have a conversation about deployment targets. For example, is API-X going to be able to be deployed in a traditional servlet container?14:02
Or are we going to target OSGi service containers only?14:03
Or both?
* Ruth_ leaves14:08
<apb18>esm_: Definitely. Would you be willing to add an agenda page for next week, and add that to it?14:09
<esm_>apb18 sure I'll init a wiki page
<apb18>esm_: Wonderful, thanks14:10
* bseeger leaves14:13
* bseeger joins14:14
<acoburn>apb18: esm_: are you planning to use ORE or PCDM (or both) to model complex objects in Fedora?14:17
<esm_>acoburn: good question, i'm not sure that we've made any decisions yet as we're not on fedora 4. We've done some initial modeling for some of our collections in both. Our packaging tool is able to target PDCM.14:18
<acoburn>esm_: we're trying to figure it out right now; I'm concerned about targeting the current version of PCDM if it may be changing (i.e. 2.0)14:19
esm_: it seems that simply using ORE will meet our use cases
<esm_>acoburn: tbh I'm not sure how close we are to any content modeling work. I've seen some of the threads on the list so I've been following from afar. We are considering using Sufia (or some other Hydra variant) for our Fedora 4 front end, so I think we'll make some practical choices based on the models supported by Hydra.14:21
apb18 can chime in here, but we've also demonstrated the ability to use different models for different concerns. We might use a particular profile of PDCM for discovery and presentation, but maybe something different for preservation and curation related activities.14:23
<apb18>acoburn: Yeah, PCDM (and common/best) practices therein have been evolving. ORE has been great for overlaying on top of (or under? alongside) other domain models
<esm_>But tbh, it's not fully thought out here at JHU, so I think we are happy to let the discussions evolve and then see where things sit when we're ready to actually implement something.14:24
<acoburn>esm_: apb18: we're getting ready for a migration from 3 -> 4, and so we need to make structural decisions; mostly I want to avoid needing to migrate content based on evolving needs of downstream applications14:25
that is, I don't want the downstream app to be driving how repository content is modeled structurally (that seems wrong to me)14:26
<esm_>We are concerned about that as well
(but have no good answers :))
<acoburn>esm_ thanks for the input, I will be interested to hear about the direction you plan to go14:27
<apb18>acoburn: yeah, we kind of see api-x as a mechanism for risk mitigation in that regard; decoupling the repository contents with the representations and interaction model(s) the apps need wherever there's friction14:28
<esm_>I wonder if API-X can be used
<esm_>So if you use ORE to model, say, an image collection, but Hydra wants to use PDCM, then you could use API-X to represent those objects as Hydra expects.
<apb18>(not that it has come to that :)14:31
<acoburn>esm_: that is exactly what I am thinking of…14:32
<esm_>I think things get more interesting when the front end wants to add triples to the resources it receives from the repository.14:33
<acoburn>esm_: yes, it does get more interesting in that case14:36
* acoburn leaves15:01
* acoburn joins15:04
* acoburn leaves
* bseeger leaves15:09
* ddavis leaves15:10
* bseeger joins15:11
* bseeger leaves15:13
* bseeger joins15:15
* dchandekstark joins15:22
* dchandekstark leaves15:29
* ajs6f joins15:33
* dwilcox leaves
* br2490 leaves15:34
* dchandekstark joins
* dwilcox joins15:35
* dchandekstark leaves15:38
<ajs6f>esm_apb18:acoburn: Using dynamically-generated representations of resources to provide durability by insulating the structure of the repository from ephemeral concerns of downstream applications? Maybe API-X could do that? Sounds almost like you just discovered Fedora disseminators.15:42
* ajs6f leaves16:01
* ajs6f joins16:22
* bseeger leaves16:25
* acoburn1 joins16:32
* acoburn1 leaves
* dchandekstark joins
* esm_ leaves16:34
* manez leaves16:35
* esm_ joins
* dchandekstark leaves16:37
* dchandekstark joins16:42
* esm_ leaves16:45
* dchandekstark leaves16:47
* ajs6f leaves16:48
* apb18 leaves16:52
* mikeAtUVa leaves16:54
* whikloj leaves17:00
<tpendragon>If only the RDF serialization were separate from the structural representation. :)17:18
* dwilcox leaves17:30
* dwilcox joins17:32
* jenlindner leaves18:30
* dwilcox leaves18:31
* peichman leaves
* dwilcox joins18:33
* dwilcox leaves18:39
* dchandekstark joins18:44
* dchandekstark leaves18:49
* dchandekstark joins19:46
* dchandekstark leaves19:50
* dchandekstark joins21:03
* dchandekstark leaves21:10
* mjgiarlo leaves23:33
* mjgiarlo joins23:46

Generated by Sualtam