Suggested paradigm for (instance) page titles

[graybeal]

In template designer, users can supply a name and a description of a each artifact (template). This name and description shows up at the top of the page (the scrollable dark teal part), and can be used to distinguish entries in the browser.

In metadata editor, users are not given any such choice, the name of the source Metadata Template appears at the top of the page, and there is no way to distinguish multiple entries from each other in the browser. Well, there is apparently some way, but it doesn't always work and isn't clear a priori how to make changes.

I think the paradigm for every artifact should be that it has some kind of name, even a temporary one, and that it be clear how to edit that name. If the name is derived from a particular field's data, that field name can be shown in small text above the name. Otherwise, the user should be able to enter a specific name for that entity in the top section, and that name is used as the entity name in the browser.

This name is metadata about every artifact (part of the meta-metadata), and should be required (even if only defaulted).

[graybeal]

oh no, the dreaded enhancement tag...

[martinjoconnor]

Actually, this is really a new feature - not an enhancement.

Will require changes to the instance model to allow CEDAR-specific name and description fields.

The use cases would have to be good here I would argue because we have resisted throwing CEDAR-specific artifacts into the instances. The goal was to make them generic JSON documents (with JSON-LD too, of course).

All instances we have received to date have had user-defined fields that naturally fit this name/description requirement. ImmPort and ISA studies, for example, have study ID/name, and study description fields.

Allowing the template designer to tag specific user-defined fields so that they appear as the main displayed fields in a summary of a derived instance might be a good way of achieving the same result.

[graybeal]

Uh oh, new feature even less likely to happen.

(a) How does the system recognize a user-defined field that "naturally fits this name/description requirement"?

(b) Not all the existing templates meet this criteria. The Instrument template does not. Obviously just a small test case, but real users will have many more.

(c) Does the argument "we have resisted throwing CEDAR-specific artifacts into the instances” apply to all the meta-metadata (what you call provenance — see my comments/suggestions on that white paper) that I’m tasked with defining? It seems exactly the same to me. Sorry, we can start a separate issue on that if necessary.

So, yes, allowing the template designer to tag the specific user-defined fields so that they appear as the main displayed Title/Description fields in any summary of instances might be a good way of achieving the same result. As long as it makes them display at the top of the instance, which was my first point of recognition that my instrument instance had no unique identifier or description of any sort.

On Mar 30, 2016, at 4:59 PM, martinjoconnor notifications@github.com<mailto:notifications@github.com> wrote:

Actually, this is really a new feature - not an enhancement.

Will require changes to the instance model to allow CEDAR-specific name and description fields.

The use cases would have to be good here I would argue because we have resisted throwing CEDAR-specific artifacts into the instances. The goal was to make them generic JSON documents (with JSON-LD too, of course).

All instances we have received to date have had user-defined fields that naturally fit this name/description requirements. ImmPort and ISA studies, for example, have study ID/name, and study description fields.

Allowing the template designer to tag specific user-defined fields so that they appear as the main displayed fields in a summary of an related instance might be a good way of achieving the same result.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHubhttps://github.com/metadatacenter/cedar-template-editor/issues/151#issuecomment-203690131

John Graybeal Technical Program Manager Center for Expanded Data Annotation and Retrieval /+/ NCBO BioPortal Stanford Center for Biomedical Informatics Research 650-736-1632 skype: graybealski

[martinjoconnor]

(a) I doubt the system will be able to recognize these fields automatically (though some heuristics like fields in the first few positions, fields with 'name', 'id', or 'description/title' in the name may go a long way).

(b) Likely - but I am biased by what I have seen so far (the investigation model, ISA, ImmPort, GEO, BioSample, caDSR, NLM value sets, and LINCS templates) where all templates have some combination of id/name/description at the user level. Having another name/description at the meta-meta level seems odd to me. I would argue that it would be odd for a user to design a template without these user defined fields. The use cases we find will tell. Do you have examples that do not contain these fields?

(c) Clearly provenance is meta-meta (for want of a better term) and is needed - but my bias is to be very conservative on additions to the model. If we end up adding new fields on a regular basis for new use cases then we will not have much of a model at all.