Input and output formats

[joeroe]

We should be able to read and write data to/from these formats:

• Complex tables like @tsdye / hm: http://www.tsdye.online/harris-matrix/data-tables/
• Complex tables like ArkMatrix: https://gitlab.com/arklab/ArkMatrix/blob/master/docs/format_csv.md
• INTCHRON JSON files: https://doi.org/10.1017/RDC.2019.21
• Generic tables of relations (i.e. "above", "below", "equal", as on a typical context sheet)
• BASP/ArchEd/Stratify .LST files: http://archaeologic.al/wiki/Harris_Matrix#LST

We probably won't be handle these formats:

• .HM files from ArchEd – are in binary format, and the only software that could write/read them doesn't appear to be functional any more (see http://archaeologic.al/wiki/Harris_Matrix#ArchEd)
• CRMarchaeo/CIDOC CRM ontologies: http://cidoc-crm.org/crmarchaeo/sites/default/files/CRMarchaeo_v1.3.pdf – extremely complicated so indefinitely postponed pending evidence that anyone actually uses it.

[nevrome]

How would you like to implement these data types? A read.* function for each type? Or S3 classes that reproduce the respective table structure? Only input or also output?

[joeroe]

Good question! I don't think having S3 classes for each would be worthwhile, since they all represent the same thing. What we need are read_ functions that transform each to a standardised, tabular data structure that describes the stratigraphic relationship between units. That can then be turned into a matrix (an S3 stratigraph object) using rules specified by a function like harris().

The question is what the intermediate tabular format should look like. My preference would be something that follows tidy principles, i.e. a single table, where 1 row corresponds to 1 stratigraphic unit and all other observations are columns. Multiple relations can be expressed as nested vectors like those used in vignette(harris).

And yes, now you mention it we should provide write_ functions for all these too.

[tsdye]

Harris' law of stratigraphical succession is satisfied by transitive reduction of the DAG. The intermediate tabular format might want to serve up information to the transitive reduction function with as little fuss as possible. Transitive reduction is another feature igraph apparently lacks: igraph/igraph/issues/932

[nevrome]

Ja - the main datatype (and maybe a list class for many of these objects?) has to be defined with all necessary class methods (is., as., format., print.). We probably also have to define the accessors [, [<-, ... to make sure that adding and removing stratigraphic units is handled correctly.

I like your harris12 sample datatset, @joeroe. List columns are fashionable and a cool feature of R data.frames. If we inherit from tibbles, we already have an excellent base class.

@tsdye Are you aware of a way to access lisp code from R? I guess it would be great to access the functionality of hm for stratigraphr. Could you compile the package to a command line tool? Something that simply runs on any shell after compilation? I just googled for a while without clear results. Lisp is an interpreter language and one always need an interpreter to run it, ja? Just like R?

[tsdye]

@nevrome, yes, lisp can produce stand-alone binaries with a command line interface. It is a bit tricky to write code that works cross-platform, so I'm not sure about producing command line tools for every OS with the hm code. Nevertheless, that is one of my goals for the hm project.
I doubt it is possible to call lisp code from R, but I don't know.

[nevrome]

@tsdye A command line interface would be great! It's simple enough to call a command line tool from within R. Maybe we could even provide hm with the R package as we did with oxcal in oxcAAR.

stratigraphr could be a simple interface between tidy data and network visualisation in R on the one hand, and Harris graph algorithm implementation in lisp via hm on the other. No need to reinvent the wheel. What do you think @joeroe? Is this a way to go?

[joeroe]

(The comment I just deleted was a duplicate.)

[joeroe]

I'm actually in favour of reinventing wheels, as long as they're not too complicated. It's often easier than having to deal with external dependencies in the long run. But it might be a good stopgap.

[tsdye]

Either way is fine with me. I plan to work on hm again this summer, which might or might not suit your plans.

[nevrome]

Alright. I could offer to write some reader and writer functions for stratigraphr when the main class is defined.

[joeroe]

b1daaf3 added a read_lst() function, but I only had one file to test it with so it might not be the most robust.

[joeroe]

As expected it is not very robust: #9