Re: Hackathon concept and deliverables - request for comment
|
Brandon Kuczenski
You just wanted to show off that princess photo! Thanks for conceiving and enacting the hackathon project, and for sending out this introduction. I have some comments that I wanted to send out right away as a "hot take" (acknowledging that one purpose of such a missive is to provoke responses), and I will also have some (perhaps more reasoned) comments later. The task you have conceived of is exciting and useful. And probably achievable. My first critique is: none of those is a deliverable; those are tasks. The deliverables should be things that we can look at and send around. Perhaps the deliverables would be the outputs resulting from those tasks executing successfully. But we should be precise in specifying them. "An RDF database containing EXIOBASE in terms of the BONSAI ontology." and there should be some standard by which we decide whether the deliverable has been met. (e.g. querying "x" against the database should return "y" from EXIOBASE). Maybe writing these tests is itself in-scope for the hackathon. (in which case: perhaps "operating unit tests for EXIOBASE import" is a reasonable deliverable?") Second: Well, (b) is a kind of a deliverable.. I suspect what you mean is more like "a document that reports the group's consensus on" those standards. But I want to observe that one such standard has already been proposed: (https://doi.org/10.1111/jiec.12810) The work in that paper was intended to achieve this goal. I humbly offer it for consideration (and possibly rejection on grounds) prior to the hackathon, since it might help us move the ball down the field. The key utilities of this framework are: (1) it provides a precise statement of a narrowly scoped process-flow model which can be easily revised and parameterized, (2) it explicitly requires linkages to remote data sources, and (3) it explicitly excludes elementary flow matching, assuming the solution to that problem to be located in (2). A product system model disclosure includes: three entity lists (of foreground flows, background flows, and emissions), and three sparse matrices that connect the entities to one another. One could easily imagine the entries in the entity lists to simply be references to the RDF database. There is also a (semi-)working brightway implementation: (https://github.com/pjamesjoyce/lca_disclosures) that casts a BW2 database to a JSON document according to the framework; writing an RDF output would not be hard. Really, I am just fishing for critical feedback on my disclosures proposal. But I do think it's relevant. -Brandon
On Thu, Feb 21, 2019 at 2:01 PM Chris Mutel <cmutel@...> wrote: Dear Hackathon participants: -- Brandon Kuczenski, Ph.D. Associate Researcher University of California at Santa Barbara Institute for Social, Behavioral, and Economic Research Santa Barbara, CA 93106-5131 email: bkuczenski@...
|
|
|