Switch from EML to eml2 in publishing-data lesson

[cboettig]

@mbjones

I believe eml2 provides a significantly improved user interface over EML. Please see the diff for a good illustration of this. In eml2, all bbjects behave like R lists (S3 objects); there is never a need to use new(), never a need to index repeatable objects if they are not repeated (e.g. no more @physical[[1]]), never a need to coerce attribute values to attribute types or coerce textTypes to the corresponding class. I think this eliminates most of the gotchas that make the EML package such a huge pain to work with.

[mbjones]

Looks great, Carl. I've asked several people on our team to give eml2 a spin. I'm going to hold onto this PR for a bit as the current repo reflects what we actually taught in OSS, and we're trying to figure out how to tag and version these repos. But we'll get it folded in. Plus we have several other tutorials around that could be updated.

[cboettig]

@mbjones Thanks Matt! yeah, that makes sense. Mostly am trying to get some more eyeballs on eml2 package and figure out how to migrate people towards that (since it seems like EML is actually getting users now and I think eml2 approach gives a lot nicer interface).

btw, eml2 is built around another package I've called emld, which defines a mapping between EML XML and JSON-LD. As we've discussed a bit before, I think JSON's more limited scope really helped me focus the design and and maps very cleanly into R list objects. It also makes it trivial to handle things like <references> nodes. I don't think much is lost with this, the only incompatible case I think is the arbitrary markup in textType, which is just left as XML string (same as in the EML package, since you can't just have an S4 slot for "bold" anyway). A side effect of this approach is that you can treat all EML as RDF and query it via sparql, though I'm not sure if that's any more useful than just querying the R list objects or XML files via xpath....