Associating a longitudinal form with an "entity type"

[LN]

I started a wiki topic to act as a table of contents at ODK ecosystem entity-based data collection table of contents. Anyone with sufficient privileges can edit it. Does that seem reasonable?

I really appreciate all the thinking you've shared.

@adam.butler

In my head, mostly

That's a wonderful start! It's still all very fuzzy in mine because there are so many possibilities and angles. I think it would be great to pick a couple of specific scenarios and workflows (e.g. turtle nesting) as anchors and ideally make sure that the user experience development happens as close to the field as possible. That is one of your strengths, @adam.butler, being so close to the eHA use cases. Have you written up some of the existing specific studies/workflows that you're basing your design around?

@adam.butler

a) upload a new form, e.g. a form for patient details

b) select an existing form that is already on the server, currently in a different project

c) provide a CSV/XLS file, where each row defines an entity (maybe this isn't a 1.0 feature, but I think it would be important that entities can come from sources outside of ODK)

I agree all of these paths would be useful. I would find it very useful to see these options ranked by priority and one picked as the highest priority path that can initially be designed for.

@adam.butler

(And this is where we intersect with the "Linked/Sub-forms" topic that has been discussed elsewhere)

Yes, exactly, there's a lot here and a big risk is to be so bogged down considering everything at once that we never get started! Thanks for shaking off that paralysis!

@adam.butler

To more explicitly tie these back to the question that started this thread -- where is the “entity” concept visible to the form designer, the project manager, the data manager and the enumerator?

I meant my question to be about the "entity type" concept, I'm sorry! Luckily I think the two questions lead to roughly the same context. With what you've shared, I'm not convinced that "entity type" is something that needs to be explicitly represented. That is, there could be a project which contains an updating list of entities. Implicitly the project name probably would describe the entity type. That's also what I understand when @Xiphware says

@Xiphware

register --> items
register --> forms

The latter of which happens to line up quite nicely with Central's 'projects' --> forms

Is it possible that you're thinking about an explicit entity type identifier because you're starting to imagine using entities of one type in a project that has to do with entities of another type?

@adam.butler

It's not necessarily the case that entities will come from a form, and in the interest of making this spec as generic as possible, I'm looking for a solid way of referencing a [definition + collection], such that the implementation in Central could allow either a [form + submissions] or a [definition + collection] that was created by uploading a CSV/XLS file.

The format that a user uses and the underlying representation don't have to be the same. Perhaps you could expand on why this requirement leads to an "entity type" concept requirement?