General information about table

[sgoutteb]

What inspired this wish list request? 

A data table contains rows and columns, but other information may also be of interest, such as: data description, origin, contact name, provenance, original format, a reference to a project or company number, ....., even an image indicating the context, the machine,

What is the improvement you would like to see? 

A dedicated menu in JMP to specify informations on the data table, may be also accessible on the home screen

Why is this idea important? 

Important for example to know more about the data table and to check prior to download all the table if it corresponds to our need

[jthi]

I'm fairly sure I have seen a wish list item regarding adding metadata to JMP tables, but I cannot find it (could just be my thoughts, as I was going to write an add-in for this). Currently you have to use table variables (especially Notes) and table scripts ( Scripting Guide > Data Tables > Add Metadata to a Data Table ).

[aharding]

I was writing this up on the wish list also and found this entry instead. This would be very helpful to users. An intern working for us figured out a way to do it using Workflow Message but it is quite cumbersome. I hope this can get done soon.

[SarahGilyard]

This is an interesting idea. Thank you for posting sgoutteb !

[hogi]

After having a discussion yesterday about the topic, I found this wish in the wish list.

We wondered how we can handle the case of multiple input files?
use case:
- N measurements imported and concatenated. each csv file has it's own header

We started to store the meta data as table variables - and noticed that JMP automatically converts Table Variables into columns when tables are concatenated:

View more...

dt1 = Open( "$SAMPLE_DATA/Big Class Families.jmp" );
dt2 = Open( "$SAMPLE_DATA/Big Class.jmp" );

dt1 << New Table Variable( "date", "2024.01.01" );
dt2 << New Table Variable( "date", "2024.06.09" );

dt1<< Concatenate(
	dt2
);

If the table is stored with compression and enabling "compact" columns, the file size won't be affected,

but it "hurts" a bit to see the few values replicated with every row.
And it's not nice to mix the meta data and the real data. Definitely makes sense to group the columns afterwards - to separate them from the real data.
Maybe even hide the columns ...

Another idea: store the information as a (nested) associative Array - with a second level of hierarchy to specify the value for the individual input files.

The values can be linked to specific rows of the data table via the filename column.
The disadvantage: At the moment the associative array can not live as a Table Variable (table variables: just numbers and strings).

As a workaround, one could "archive" the Associative Array as a table script and run the script every time before accessing it. Definitely not nice.

[hogi]

related wish Let us use more complicated data types for table variables than just text and numbers 
with an alternative workaround to store an associative array:
as a string in a Table Variable -> use parse to access it as an associative array