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

Using timezone: Eastern Standard Time
* dchandekstark joins00:16
* dchandekstark leaves00:21
* dchandekstark joins02:18
* dchandekstark leaves02:23
* thomz joins02:38
* dchandekstark joins04:20
* dchandekstark leaves04:24
* dchandekstark joins06:21
* dchandekstark leaves06:25
* manez joins08:00
* manez leaves08:05
* coblej joins08:10
* dwilcox joins08:16
* ajs6f joins08:20
* dchandekstark joins08:23
* dchandekstark leaves08:27
* dwilcox leaves08:41
* acoburn joins08:45
ajs6f: can I pick your brain on RDFS entailment?08:47
<ajs6f>acoburn: You already are.
<acoburn>ajs6f: first, I'd like to distinguish b/t _publishing_ linked data and storing data in a repo08:48
<acoburn>ajs6f: so, say I want to use some predicate with a certain domain
<ajs6f>"I want to use some predicate with a certain domain"08:49
<acoburn>ajs6f: w/ RDFS entailment, the rdf:type of that resource is then implied to be of that particular class
ajs6f: e.g. bibframe:shelfMark
<ajs6f>acoburn: Yes. That's a triple you can create. Must create, actually.
<acoburn>ajs6f: when _publishing_ that data publicly, I'd include the implied rdf:type for the domain of the resource
<ajs6f>acoburn: You needn't materialize it, but it is in-scope for further entailment.08:50
<acoburn>ajs6f: but what about persisting that in Fedora
ajs6f: ok, I'd like to be as minimal as possible w/r/t the rdf:types applied to resources in the repo
<ajs6f>acoburn: How are you publishing it? Just by exposing your Fedora API? Or by some other means (e.g. API-X) that includes inference?
<acoburn>ajs6f: I would not _just expose the Fedora API_08:51
<ajs6f>acoburn: You can do the inference dynamically for your clients. There's nothing wrong with that.
<acoburn>ajs6f: there's be some intermediate step — APIX or via Jena or Fuseki
* esm_ joins
<ajs6f>acoburn: Store the minimal graph and on-the-fly do the inferencing?
<acoburn>ajs6f: yes, exactly08:52
ajs6f: does that seem bizarre or does that seem like a sensible approach?
<ajs6f>acoburn: Totally legit, to my mind. Just keep in mind that even if the entailed triples are in fact an important set of assertions about the resource, you haven't persisted them. Implicitly, RDFS entailment is then an important part of your _preservation strategy_.
<acoburn>ajs6f: that's a good point about preservation08:53
<ajs6f>acoburn: If the entailed triples are convenient, but not a crucial ingredient in the model, then who cares? And after all, if you really believe in "digital preservation", I have a bridge in Brooklyn to sell you.
<acoburn>ajs6f: I'm not in the market for bridges08:54
ajs6f: but following the semantics of simple entailment, graph G (e.g. the minimal graph) implies graph E (e.g. the entailed graph)08:55
<ajs6f>acoburn: But your preservation actions occur via other machinery (e.g. Camel), and you could reintroduce the entailments there.
acoburn: If you understand implication in that way, which is a fair assumption for most people. Entailment and implication aren't exactly the same, but they are pretty dang closely related.08:56
<acoburn>ajs6f: yes, if they are even necessary for the functioning of that machinery (they often aren't)
<ajs6f>acoburn: There is a wide gap between "necessary to make machines function" and "preserves the meaning"
<acoburn>ajs6f: I was being loose with my language — I mean "entails" and not "implies"
<ajs6f>acoburn: Part of the idea of Fedora has been to bridge that gap with its modeling.08:57
<acoburn>ajs6f: what it would mean for digital preservation (in my mind) is that the corresponding ontologies are available indefinitely or part of the digital preservation strategy08:58
<ajs6f>acoburn: And some sense of how to use them. You can call that solved by the larger context, if you like, but it is part of the story.08:59
acoburn; If you think I'm being impossibly picky, let's sit down with some Wordstar documents or a nice Visicalc spreadsheet.
<acoburn>ajs6f: thanks! I feel like there hasn't been much discussion about this sort of thing in the wider Fedora community09:00
<ajs6f>acoburn: No, because the basic idea of Fedora (preserve meaning, not bits) has pretty much gone by the wayside.
<acoburn>ajs6f: and that most people's approach seems to be to persist every possible triple (and not use inference at all)
ajs6f: which isn't necessarily _wrong_, but it makes for some pretty baroque modeling09:01
<ajs6f>acoburn: People think they got burned by the early difficulties with inference. I would put it differently; people had unrealistically high expectations for a nascent technology.
<acoburn>ajs6f: "semantic web" has some pretty high expectations09:02
<ajs6f>acoburn: RDFS is reasonably cheap, and even some OWL profiles can be effectively used in the right circumstances. But it all requires people to think about modeling coherently, instead of just slapping properties onto amorphous entities.
<acoburn>ajs6f: this is also left over from modeling the world in XML (i.e. document-centric modeling)09:03
<ajs6f>acoburn: TBL promised a lot in ScAm, but anyone in this line of work had access to people who could speak with expertise. If you get your information from the newspaper, you deserve what you get.
<ajs6f>acoburn: People using Fedora regularly employ habits of modeling inherited by RDBSes.
<acoburn>ajs6f: yes, I see that _a lot_
<ajs6f>acoburn: Inertia is not evil in itself, but this is _Fedora_. The soul of the whole thing is modeling.
<ajs6f>acoburn: One of the keynotes at ISWC this past fall was from a guy who advises central banks on technology issues.09:06
acoburn: Let me see if I can find a video.
acoburn: http://iswc2015.semanticweb.org/michael-atkin09:07
acoburn: He talked about the success they've had moving giant institutions like, THE WORLD FINANCIAL SYSTEM, onto OWL-based inference. The audit and bookkeeping strictures under which they operate make automatic entailment really attractive.09:08
acoburn: These are freakin' bankers we are talking about here. Not exactly wild and crazy people.
<acoburn>ajs6f: the abstract is very interesting09:09
* apb18 joins
<ajs6f>acoburn; So part of the problem with getting inference takeup is rooted deeper, with the structural problems in the community of institutions of memory in the U.S. Did you watch the slo-mo train wreck that was the first attempt at Bibframe?
acoburn: If you can't even do Linked Data, how do you expect to do inference, which is more subtle?09:10
<acoburn>ajs6f: I've mostly tried to stay away from bibframe :-)
<ajs6f>acoburn: Right. And for all the reasons you have so done, do you want the same people trying to use OWL?
<acoburn>ajs6f: though our librarians want to use bf:shelfMark and I'm trying to avoid having to suddenly persist all of these additional triples09:11
<ajs6f>acoburn: When you complain about librarians not suing inference, you are basically saying "You did so badly with plain hand-operated RDF that I want you to try using power tools."
* whikloj joins
<acoburn>ajs6f: well, I'm actually keeping the power tools locked under my desk — we haven't even _talked_ about OWL in our metadata meetings09:13
<ajs6f>acoburn: Why are librarians even talking about triples? Do librarians talk about integrated circuit design? Why is this even a conversation? You and they should be talking about models, not triples.
acoburn: It's -your- business to make the triples work. It's what they pay you for. That's like hiring a plumber and then telling him or her how to use the tools.
<acoburn>ajs6f: basically, I wanted our librarians to have some level of understanding of RDF and linked data
ajs6f: I could just go into my office and write code that does what we described abstractly, but I felt that would be counter-productive in the long term09:14
<ajs6f>acoburn: Sure, the way my plumber explains what he does to me. But that's a transfer of knowledge in one direction.
acoburn: Because getting them to tell you what triples to use is working so well?
<acoburn>ajs6f: well…09:15
<ajs6f>acoburn: It's your thing, man.
acoburn: Do what you want to do.
acoburn: I can't tell you...
acoburn: who to sock it to.
acoburn: Or what triples to use.
<acoburn>ajs6f: here's the deal — if I make all of the decisions about how metadata is structured, and it appears that my decisions are completely at odds with other (much larger communities who use Fedora) — which they often are09:17
ajs6f: then I need a more solid footing to explain why we make the decisions we make.09:18
ajs6f: for example, I'm currently suggesting that we completely ditch PCDM
ajs6f: I see no benefit with it, but everyone else (it seems) is rushing to use it
ajs6f: I would much rather just use ORE
<ajs6f>acoburn: (sotto voce) Not everyone is rushing to use it.09:19
<acoburn>ajs6f: but if I keep going "against the grain" (as it appears) — even if I think my approach is correct, I get a lot of push back
ajs6f: yes, I know that not everyone is rushing to use it, but that's the impression people get
<ajs6f>acoburn: That's a modeling decision. That seems to me to be a legitimate topic of conversation with your librarians.
acoburn: There's a difference, in my mind, between "Should we use PCDM?" and "What kind of entailment regimes are we going to deploy at various points in our architecture?"09:20
* manez joins
<acoburn>ajs6f: right, and everything we want to model can be done with ORE, which is a much more mature vocab that doesn't seem to be changing every 6 mos
<ajs6f>acoburn: You will get no argument from me. I do not understand the value proposition of PCDM and I do not understand how it fits with the ideas at the heart of Fedora about modeling for durability.09:21
<acoburn>ajs6f: well at least that makes two of us.09:22
<whikloj>brave decision you made their mr. acoburn, but I think time will prove you to be correct and probably ahead of the curve.09:23
<ajs6f>acoburn: Not just two of us. But there's a built in bias here. No one is going to spend the time to announce, "We're not using PCDM right now!" whereas anyone who is using it is instantly going to announce that fact by communicating with the larger group using it.
<acoburn>whikloj: my main problem with PCDM is that I can't tell if it's a "domain model" or an "application profile"09:24
whikloj: if it's a domain model, how does it improve on ORE?09:25
<ajs6f>acoburn: Are you confident that the people evolving it know, themselves?
<whikloj>acoburn: there is much love of your idea of simply decorating your own data model into PCDM
* coblej leaves
<acoburn>whikloj: and if it is an application profile, I want nothing to do with it — at least not in the repository
whikloj: that's the role of downstream applications — not the repo
<ajs6f>acoburn: The only value I have heard ascribed to it is "interoperability", which certainly points at an application profile.09:26
<acoburn>whikloj: and my impression of the entire PCDM discussion to date is that it is becoming more and more like an application profile
<whikloj>yes, my issue has been one of this is a very lacks structure so everyone can use it differently. It also seems to make the interoperability harder
<acoburn>ajs6f: has no one heard of CONSTRUCT {} WHERE {} ?
<whikloj>me talk pretty one day
<acoburn>ajs6f: easily create an application profile from a domain model09:27
<ajs6f>acoburn: There are some bright people involved with PCDM, but my impression is that the majority of work revolves around immediate application level problems.
<acoburn>ajs6f: yes, that's my understanding, too. And those application level problems are of very little concern to me
* coblej joins
<ajs6f>acoburn: "I can't make my Hydra head do X. Can we alter the model to make it easier?"
* diegopino joins
<ajs6f>acoburn: Well, I look forward to your Acoburntology.09:29
<ajs6f>acoburn: Which should also be the name of your forthcoming smooth jazz album.09:30
<acoburn>ajs6f: I just hope it doesn't turn out like DFW's Escatology
* dhlamb joins
<acoburn>I mean Eschatology
good morning dhlamb and diegopino — we're talking about RDFS entailment09:31
<diegopino>acoburn: catching up =)
<dhlamb>how recent are logs, would like to catch up but was disconncted09:32
<ajs6f>"We're talking about…": https://www.youtube.com/watch?v=ZFD01r6ersw
<acoburn>dhlamb: http://irclogs.fcrepo.org/2016-08-22.html
<diegopino>ajs6f: jajajaja… elasticity of language…!
<ajs6f>I love Hugh's bright look as he says "Hello! We're talking about..."09:34
<acoburn>ajs6f: that's fabulous
diegopino: say you're using ORE to model resources in Fedora but your application needs to use PCDM classes and properties — I have a simple CONSTRUCT {} WHERE {} statement that does the conversion09:37
diegopino: for both the so-called v1.0 or v2.0
<diegopino>acoburn: completely. If your definition base if ORE, then “semantically casting” to anything derived from is kinda easy
acoburn: also, gives us more flexibility when using other rdf:types simultáneosly.09:38
<acoburn>diegopino: even if your structure is ever so slightly different
diegopino: by which I mean, you can model objects in Fedora according to how you think they should be modeled09:39
<diegopino>acoburn: but are you thinking of full blown ORE? ReM?
<acoburn>diegopino: if an app needs a slightly different structure (e.g. FileSets), you can generate that
diegopino: yes I am: ReMs09:40
<ajs6f>Interesting. I think diegopino's spell checker "corrected" his word to "simultáneosly". That's kind of a mixture, I think.
<diegopino>ajs6f: my spellcheck is my damn brain, which is mixed. Sorry for that, will be in 100% english mode soon
<dhlamb>acoburn: thinking of persisting the ReM, or just generating on the fly for an API?
acoburn: or knowing you, that's what you're sticking in RIAK09:41
<acoburn>dhlamb: persisting the ReM and putting descriptive metadata there
* peichman joins
<diegopino>dhlamb: acoburn: ReM is the one that defines where on Graph begins and ends
<ajs6f>diegopino: No trouble, I just get excited about different forms of distortion. Much more interesting that oldfashioned AM radio static.
<diegopino>dhlamb: acoburn so it should be present
<dhlamb>acoburn: was reading through ore spec last night. so you don't want to put any descriptive metadata on the aggregations, and leave it to the ReM altogether
<acoburn>diegopino: that's exactly how I want to be able to model resources — a clear defn of where the graph begins
dhlamb: yes
<dhlamb>acoburn: instead of just having the ReM pull in the whole graph, and the metadata on the aggregations09:42
<ajs6f>acoburn: That's been a practice in the Fedora community for a long time.
<dhlamb>acoburn: dang
<ajs6f>acoburn: (Not with ORE, per se, but with whatever aggregatory machinery is in play.)
<dhlamb>acoburn: that's interesting
<acoburn>dhlamb: I also don't see how collections fit into the aggregation (at least the don't for me)
<dhlamb>acoburn: i don't see the need for a distinction09:43
<ajs6f>acoburn: The description of the aggregation is the aggregation of the descriptands being assembled.
<diegopino>dhlamb: acoburn: right, ReM solves a big problem: Until where do you want to traverse
<dhlamb>acoburn: esp. with pcdm, since so often our collections do have files, like descriptive metadata or a thumbnail, at least
<acoburn>dhlamb: being a member of a collection is different than being a necessary part of an aggregation
dhlamb: in that case, they are their own aggregation
dhlamb: but the collection doesn't ore:aggregates the objects it contains (at least that's my understanding)09:44
<diegopino>acoburn: completely, member of a collection is upper semantics (almost like tagging) part of an aggregation means all those resources(in ReM) helo describe the same instance of a concept
<dhlamb>acoburn: why not? what else would it do?
<diegopino>helo = help
<dhlamb>acoburn: or just have the collection as a container and be done with it?
<acoburn>dhlamb: i.e. I have a collection of Emily Dickenson poems. That collection is its own resource (i.e. its own container)09:45
<diegopino> collection as a container does not work with multiple memberships
<acoburn>dhlamb: the individual poems may be dcterms:partOf that collection
<ajs6f>diegopino: Why not? It's not just basic containers. There are direct and indirect containers, and a resource can be in an arbitrary number of those.
Collection modeled as container is a pretty darn natural LDP idiom.09:46
<diegopino>ajs6f: not ldp:contains, the indirect will jsut add that to a proxy not to the real resource09:47
ldp containment is like putting stuff in a box
<ajs6f>diegopino: Is that a problem?
<diegopino>once in a box, it can not be in another box.
* manez leaves
<dhlamb>acoburn: so you're saying there's no need for the ore:aggregates refinement? and therefore no need for a ReM?
<acoburn>diegopino: that's only if you're using ldp:contains09:48
<ajs6f>diegopino: It's simply not true that a resource can be in but one LDP container.
<diegopino>acoburn: ajs6f yes. I was thinking of LDP domain predicates only. ajs6f you are right. But the rpedicate would be in another semantic space
<acoburn>dhlamb: I'm saying that a ReM is _definitely_ necessary, b/c that tells you where your graph starts
<diegopino>ReM is _definitely_ necessay ++ to that09:49
* manez joins
* bseeger joins09:50
<acoburn>diegopino: but ReMs are not part of the PCDM model
<ajs6f>Rob Sanderson was involved with writing ORE ReM, and at some level in writing PCDM, at least early on. It would be interesting to hear from him what he thinks is in PCDM that isn't in ORE.
<diegopino>acoburn: for which i think i saw the “why” explanation in some talk in github…but it should09:51
<dhlamb>acoburn: ajs6f: no one's saying you CAN'T use ReMs, right?
<ajs6f>dhlamb: OWA.
<acoburn>dhlamb: what ajs6f said
dhlamb: but there's no mention of them in the documentation
dhlamb: which also speaks volumes09:52
<dhlamb>acoburn: yeah, seems like you're missing the whole point to spec wihtout them
<ajs6f>OWA is the name of ruebot and my new wrestling tag team.
<dhlamb>acoburn: it's being able to get the whole graph in RDF that's useful
<acoburn>dhlamb: I agree, and that's also why I'm suspicious of pcdm:Collection that (effectively) ore:aggregates all of the members09:53
* peichman leaves
<acoburn>dhlamb: we have collections with hundreds of thousands of members09:54
* peichman joins
<dhlamb>acoburn: and so just ore:aggregates is enough because yo udon't need another refinement
<acoburn>dhlamb: it is in no way necessary to treat that entire graph as a unit that must belong together in the sense that all the resources that are part of a single manuscript belong together09:55
dhlamb: dcterms:hasPart / dcterms:isPartOf is perfectly sufficient
dhlamb: for aggregations, ore:aggregates is perfectly sufficient09:56
<diegopino>acoburn: for me, in graph traversal theory, knowing where one “concept” begins and ends was always a problem. Sometimes when you traverse you just need strongly related resource. ReM is that. More over in LDP this can be a problem and ReM can be of aid. ReM is subclass of graph by the way, so not sure how you can store that on fedora. But i maybe need more papers
<dhlamb>acoburn: still trying to wrap my head around your first statement, there
<diegopino>dhlamb: aggregations are tighlty related resources that all help to describe the same09:57
dhlamb: if you aggregate to collection
<acoburn>dhlamb: even if you need the PCDM properties/classes, it's incredibly easy to infer them with RDFS entailment
<diegopino>dhlamb: you are saying that all the members of that collection are so similar that define the collection itself
<dhlamb>diegopino acoburn: ok, i think i get it
<diegopino>dhlamb: which is wrong
<ajs6f>acoburn:dhlamb: If you have to have all of the graph describing a resource in one place, you have to offer a strong, precise, and computable definition of "describe". Which we haven't got.09:58
<acoburn>diegopino: I see collection membership as a much looser than what ore:aggregates suggests (i.e. I completely agree with you)
<diegopino>ajs6f: i have dyslexia..!
<dhlamb>so the aggregation is for the file representations like a preservation master and then lower quality access copies, but not collections
<ajs6f>diegopino: Eh?
<dhlamb>so then what about pages of books?09:59
<ajs6f>dhlamb: If I remove an member of a collection, does the collection change identity?
<dhlamb>partOf seems to fit better there
<acoburn>dhlamb: yes, exactly, a single page may ore:aggregates a set of files
dhlamb: and a manuscript may ore:aggregates a set of pages10:00
<dhlamb>acoburn: i like where this is going
<acoburn>dhlamb: the MS and the page are both aggregations
dhlamb: and each have a ReM
<dhlamb>acoburn: MS == manuscript?
<acoburn>dhlamb: yes
<diegopino>acoburn: correct. And that page belongs only to one book/manuscript10:01
<acoburn>dhlamb: the <MS> dcterms:isPartOf <the collection>
<ajs6f>acoburn: But a series of MSes, grouped together because they were purchased together… a collection, I would say.
<dhlamb>acoburn: but <page> ore:aggregatedBy <MS>
<acoburn>ajs6f: sure
dhlamb: yes (or <MS> ore:aggregates <page> in my model)10:02
<dhlamb>acoburn: ok, so forgive me if i'm slow, so what's the suggestion for implementing a collection?
<diegopino>acoburn: dhlamb: but we have to distinguish two types of pages “a conceptual one” that links to “physical one” (this last one aggregates the files), so you can have sequences and orderings
<dhlamb>direct container?
<ajs6f>acoburn: I'm trying to make the point that the signal that you have a collection (loose) and not an agg (tight) is when you can subtract and add members without the identity of the super-thing changing.
<acoburn>dhlamb: no
ajs6f: yes, I completely agree
<diegopino>ajs6f: yes, that is so, agree10:03
<ajs6f>acoburn: I think that's the rule to keep in your pocket.
<dhlamb>ajs6f: i would agree with thta too
<acoburn>ajs6f: there may be some collections whose identity depends on the membership, and others that don't
<ajs6f>acoburn: I'm talking about how to know which technical construct to use to model something.
<acoburn>ajs6f: for those whose identity depends on the membership, I'd use <collection> ore:aggregates <MS>
<ajs6f>acoburn: Right.10:04
<diegopino>acoburn: but not “membership”, aggregation, love semantics
<acoburn>diegopino: yes, aggregation
<ajs6f>acoburn: You can call it whatever you want in natural language. A lot of it is just junk, anyway. Librarians and archivists love to collect things. Real hoarders.
<acoburn>ajs6f: "box o' stuff"
<diegopino>acoburn: still i have to research more on hasPart and isPartOf, not sure how loose that is10:05
<ajs6f>afk bbl
* ajs6f leaves
<acoburn>diegopino: FWIW ore:aggregates is a refinement of dcterms:isPartOf
diegopino: so I see ore:aggregates as "stronger" (or at least "not weaker")
diegopino: or maybe it's dcterms:hasPart — I can never remember these things10:06
<diegopino>acoburn: right. a Piston is part of an engine. Without that piston, engine does not work. It’s not the same as being member of a collection… not sure. I lack of semantic docs to confirm
<dhlamb>diegopino: in acoburn's case removing a single poem from his Dickinson collection wouldn't stop it from being a dickinson collection10:08
diegopino: i think it's ad hoc based on how you view the collection
<acoburn>dhlamb: and I may have a collection of five related poems that all belong together (ore:aggregates)10:09
dhlamb: but maybe the complete set of poems dcterms:isPartOf <some Dickinson collection>
* coblej leaves
<dhlamb>acoburn: so then is your smaller set really a collection? or is it a single body of work (forgive using the word work)?10:11
<acoburn>dhlamb: the smaller would be an ore:Aggregation (which is also a dcmi:Collection)10:12
dhlamb: the larger set would only be a dcmi:Collection
dhlamb: or, if the larger collection _does_ ore:aggregates some resources, those resources aren't the MSs
* dhlamb goes to look up dcmi10:13
<acoburn>dhlamb (e.g. some images to show on a splash page or something)
<diegopino>acoburn: i suppose it depends on your other rdf:types right? If all the poems where published in a same manuscript and you are using schema:book also?
acoburn: so about additional concepts (rdf:types), will you manage those also in fedora right?10:14
acoburn: i mean at least one
<acoburn>diegopino: I'd like to use RDFS entailment pretty extensively
<diegopino>acoburn: yeah, but lets say you want to list “all book like structures”10:15
<acoburn>diegopino: triplestore + inference
* coblej joins10:16
<diegopino>acoburn: ok, but triplestore will have extra rdf:types
<acoburn>diegopino: yes, the entailed and inferred types
<diegopino>acoburn: so, in case of “KAPUT”, how do you restore triple store data?
<acoburn>diegopino: reindex10:17
<diegopino>acoburn: so… the some rdf:types (higher semantics) are in fedora
acoburn: that is what i meant: not only fedora, ore and ldp namspaced semantics10:18
<acoburn>diegopino: that remains to be seen. there's a lot you can do with simple RDFS entailment
diegopino: I'd have the ORE and LDP semantics loaded into the triplestore
(as they are right now)
diegopino: as you know, I'd like to really minimize the number of triples in Fedora — most rdf:type triples can easily be inferred10:19
diegopino: if an rdf:type triple can't be inferred, then I'd wonder: is this really appropriate for rdf:type and not, say, dcterms:type or dcterms:format?10:20
* coblej leaves
* coblej joins10:21
<diegopino>acoburn: i like to stick to rdf:type
<acoburn>diegopino: there's nothing wrong with being explicit
<diegopino>acoburn: and i like to upcast rdf:types (see this as a way of caching) to the most general one in the most specific group
acoburn: not sure if i explain myself10:22
<acoburn>diegopino: when publishing linked data, I'd expect that we'd be really explicit about types
<diegopino>acoburn: comes from my graph traversal algorithm experimentation
acoburn: right
<acoburn>diegopino: Dijkstra?
<acoburn>diegopino: I spent 7 years building graph traversal engines10:23
<diegopino>acoburn oh cool. I will ask you then for some advice further this year. (when we have solved this)
<acoburn>diegopino: then I ended up working on Fedora, where we've got graph traversal :-)
<diegopino>acoburn: my current approach is to builkd weighted adjacency graphs10:24
<acoburn>diegopino: are you familiar with this for doing parallel graph computation: http://spark.apache.org/graphx/
<diegopino>acoburn: nope, but wow10:25
<acoburn>diegopino: spark is pretty cool
<diegopino>acoburn: well having a choice of algos is cool. And not having to write them as i do…10:26
<dhlamb>diegopino: yeah, it'd be great if we really had to scale out
* diegopino_ joins10:27
to be able to cache traversal baser on repeting patterns
acoburn: but i’m still stuck in some stuff
<acoburn>diegopino_: there are some hard problems tucked inside the familiar-sounding idea of a graph10:28
<diegopino_>acoburn: completely. And exactly because of that and the problems i have found during graph traversal and diverging paths (predicates that link to non atingent knowledge domains) is that ReM feels so important10:30
acoburn: ok, will go back to coding. CLAW Sprint this week and i have to prepare my head. Cool talk!10:31
* diegopino leaves
<acoburn>diegopino: a pointed, directed graph is also easier to deal with than an arbitrary, undirected graph
<diegopino>acoburn: fully! But real world. I had to deal last year with cyclic graphs and is a pain
<acoburn>diegopino: ouch. nice chatting with you!10:33
<diegopino>acoburn: thanks for sharing all your knowledge!
<acoburn>diegopino: you too! the finer details of ORE is kinda new for me, and it's great to have your perspective on it10:34
* peichman leaves10:42
* peichman joins10:43
* manez leaves10:45
* manez joins10:46
* dwilcox joins10:52
* thomz leaves11:01
* esm_ leaves11:15
* ajs6f joins11:17
acoburn: "diegopino: a pointed, directed graph is also easier to deal with than an arbitrary, undirected graph"11:19
acoburn: That's why when you did RdfStream => Java 8 I wanted to be sure we understood that the concept in hand was a _pointed_ graph.
<acoburn>ajs6f: that's _exactly_ why I used that language above11:20
ajs6f: the _pointed_ graph is central to the Fedora model
<ajs6f>acoburn: It's nice when things are _about_ other things, instead of being about the world at large. It makes for tractability.
<acoburn>ajs6f: I completely agree11:21
* bseeger leaves11:22
<ajs6f>all: I am going to https://wiki.archivematica.org/Community/Camps/UMSI201611:23
tomorrow. Happy to take any messages, desires, opinions with.
<diegopino>ajs6f: have fun + fetch (or propose) ideas for a simple ontology for FRP, we all can use as common way of defining our future derivative needs.11:31
<ajs6f>diegopino: I think Mark from Artifacual actual has a certain amount of that already done, so that shouldn't be hard.
<ajs6f>diegopino: Nope, it was Justin: https://www.youtube.com/watch?v=dfRtZFiRp6U11:35
* coblej leaves
<diegopino>ajs6f: oh, yes, i already saw that. cool.11:36
<ajs6f>I've said it once and I'll say it again. Justin ha a really nice voice.11:39
<acoburn>ajs6f: he's also a very nice person. send him my greetings11:40
* dwilcox leaves11:41
<ajs6f>acoburn: will do
* coblej joins11:51
* coblej leaves11:55
<ajs6f>afk bbl12:05
* cmills leaves12:07
* cmills joins12:08
* coblej joins12:50
* dwilcox joins12:53
* bseeger joins12:58
* peichman leaves13:00
* peichman joins13:01
* diegopino leaves13:20
* travis-ci joins13:28
ualbertalib/fcrepo4-oaiprovider#42 (master - 23a0725 : piyapongch): The build has errored.
Change view : https://github.com/ualbertalib/fcrepo4-oaiprovider/compare/ce04eef3fcce...23a072514840
Build details : https://travis-ci.org/ualbertalib/fcrepo4-oaiprovider/builds/154215089
* travis-ci leaves
* jello joins13:35
* peichman leaves13:39
* peichman joins13:41
* jello leaves13:55
* bseeger leaves14:19
* bseeger joins14:20
* acoburn leaves14:28
* manez leaves14:48
* manez joins14:51
* peichman leaves14:56
* peichman joins14:58
* coblej leaves15:01
* coblej joins15:02
* bseeger leaves15:06
* acoburn joins
* coblej leaves
* acoburn leaves15:12
* coblej joins15:13
* acoburn joins
* bseeger joins15:14
* coblej leaves15:17
* dwilcox leaves15:18
* dhlamb leaves15:36
* coblej joins15:59
* acoburn leaves16:03
* bseeger leaves16:21
* manez leaves16:25
* travis-ci joins16:26
ualbertalib/fcrepo4-oaiprovider#43 (master - 32a7f7e : piyapongch): The build passed.
Change view : https://github.com/ualbertalib/fcrepo4-oaiprovider/compare/23a072514840...32a7f7ee4988
Build details : https://travis-ci.org/ualbertalib/fcrepo4-oaiprovider/builds/154264482
* travis-ci leaves
* dchandekstark joins16:28
* manez joins16:30
* dchandekstark leaves16:33
* travis-ci joins16:36
ualbertalib/fcrepo4-oaiprovider#44 (master - d9ecd74 : piyapongch): The build passed.
Change view : https://github.com/ualbertalib/fcrepo4-oaiprovider/compare/32a7f7ee4988...d9ecd74ebd80
Build details : https://travis-ci.org/ualbertalib/fcrepo4-oaiprovider/builds/154265076
* travis-ci leaves
<jackhill>ajs6f: I've started to take a look at FCREPO-2118. I made a note on the ticket about what I remember from the call.16:42
My first question there is, which documentation did we think needed changes?
<ajs6f>jackhill: The documentation explaining versioing16:43
<jackhill>The JavaDoc or something else?16:45
* manez leaves16:46
<jackhill>or what's on the wiki. Now that I think about it the wiki makes more sense…16:47
<ajs6f>jackhill: No, not the Javadoc at all. Start with the HTTP API docs and then we may need some entirely new pages explaining what versioning actually does (ie what new resources are created, and how they relate to each other). Think diagrams showing the reelationships between the resource you versioned, the versions of it, and resources pointing in (via links) at it. One important point is to make clear that no link goes to a named version o
* manez joins16:48
<ajs6f>jackhill: Right, not the Javadoc. That's not substantially wrong, anyway. Harsha got confused because we haven't adequatley explained what versioning actually does. That's what we have to correct.
jackhill: Sorry, got to run, and I'm travelling all day tomorrow and then at conference for much of the rest of the week. But I'll try to be on IRC as much as possible and you can email me.16:49
* ajs6f leaves
* whikloj leaves16:55
* apb18 leaves
* manez leaves17:01
* manez joins17:07
* manez leaves
* travis-ci joins17:11
ualbertalib/fcrepo4-oaiprovider#45 (fcrepo4-oaiprovider-4.2.0 - d9ecd74 : piyapongch): The build passed.
Change view : https://github.com/ualbertalib/fcrepo4-oaiprovider/compare/fcrepo4-oaiprovider-4.2.0
Build details : https://travis-ci.org/ualbertalib/fcrepo4-oaiprovider/builds/154277212
* travis-ci leaves
* coblej leaves17:13
* peichman leaves17:15

Generated by Sualtam