feat: ✨ add Layout chapter for structure of package

[lwjohnst86]

Description

This lists all the files and folders within a data package, as a high-level overview of a data package but also of the book itself.

The PR is a bit on the long side, but I thought it was ok because it isn't high priority to review and merge in.

Needs a thorough review.

Checklist

• Ran just run-all

[signekb]

Very nice overview 🌟 When reading, I thought that I might as well give some suggestions:

[signekb]

Very nice overview 🌟 When reading, I thought that I might as well give some suggestions:

[joelostblom]

Looks good! Just some minor comments

[joelostblom]

Do you think it would be beneficial to give our more general data package another name that is less similar to the existing Data Package standard? "Package" is maybe the nicest name, and we could make a technical point around the use of title case or not, but it will likely still be confusing to try to distinguish the two, even more so in speech. Calling it "data package" also makes it sound like we're closer to the datapackage.json standard than e.g. data-dict.yaml or anything else that would be developed in this space. This is currently true but more as a historical artifact and if we intentionally want to distance ourselves from that standard, we might benefit from a different name.

A different name would of course include more work to change wording elsewhere compared sticking to our current mixed use of "Data Package" and "data package" in the docs which doesn't stand out as obviously when used interchangeable even if they technically are different things. I'm not saying that we need or even should do this, I'm just bringing it up for discussion since the seedcase project has evolved to be less tightly couple to the Data Package standard the it was initially and I'm wondering if there would be benefits to the name reflecting that. It depends on how important you think the distinction is from the already existing Data Package standard. Some possible suggestions, none feel perfect:

Data project
Data bundle
Data product
Data artifact
Data repository
Data collection
Data capsule
Data pod
Data module
Data distribution

[lwjohnst86]

Yea, it's unfortunate that they named it so generically. But I don't think we should be afraid to use the really accurate description of "data package" just because someone else used it for something that isn't exactly accurate of what a "package" means (in the software ecosystem anyway). And none of the other terms come even close to accurately describing what we're doing and building. I think the closest might be data project, which could have nice symmetry with pyproject.toml. But.. I'd rather make the connection to software packages than a project (e.g. a project doesn't imply that we have a build and release process, that we treat the code and raw data as the source to the "compiled" final data). For example, Python projects and R projects (e.g. .Rproj) don't imply the production of a formal product and artifact, unlike the package does.

[signekb]

Although I actually really like the name "data package" bc it feels very clear in terms of what it is, you do have a point. Maybe open an issue for this discussion?
I think that "data pod" is pretty cute 🌱 🌷 despite it not being as clear as "data package".

[joelostblom]

Include a sentence about what it contains like for the other bullets?