Thinking of changing the CSV format

[Phil Beauvoir]

At the moment importing and exporting CSV files involves creating three .csv files (i.e three tables) - elements, relationships, and properties. The reason to use three files is because each table is different.

However, it is possible to save them into just one file if some columns are used for more than one field.

For example:

Code Select Expand


"Type","ID","Name","Documentation","Source/Key","Target/Value"
"ArchimateModel","7e5204b6-acce-4251-8328-d94d97f2c4fb","(new model)","","",""
"BusinessActor","3925101a-bbcc-4f96-81a2-9aec02c438bd","uuudddddddddd","Some Documentation","",""
"ApplicationComponent","4a37e297-030d-42fc-813a-14fc617f4a75","Application Component","","",""
"Device","5f2ea42a-9d55-4e08-94c6-6cc8aee6101d","Device","","",""
"Node","d552df64-bfea-49b9-a141-5ce73507c420","Node","","",""
"TriggeringRelationship","fda902a3-fa2c-4729-8191-2ff5435ff1ce","My Rel","Some Documentation","3925101a-bbcc-4f96-81a2-9aec02c438bd","f1771987-f8d3-4ce1-a15c-eea1f90dd927"
"Property","fda902a3-fa2c-4729-8191-2ff5435ff1ce","","","key","value"
"Property","fda902a3-fa2c-4729-8191-2ff5435ff1ce","","","key2","value2"


Here we can see the "Source/Key" and "Target/Key" fields are used to store the relationship source and target IDs if type is a Relationship. If type is a Property then the fields are used to store Key and Value.

What do you think? It would be simpler than having to deal with three files.

[Jean-Baptiste Sarrodie]

Hi,

Personally I don't really like this option because I think it would make it more difficult to work with these files. Not sure there's a real pain point to solve. Maybe a better documentation with examples could help on this. I'd like to have feedback from people who uses it too.

I could imagine that someone want a different format like JSON or XML, but that' not the same story at all.

JB

[Phil Beauvoir]

> Personally I don't really like this option because I think it would make it more difficult to work with these files.

What problems do you foresee?

> Not sure there's a real pain point to solve.

Some people get in trouble working with three files. Cross-referencing is easier.

[Jean-Baptiste Sarrodie]

> What problems do you foresee?
> Some people get in trouble working with three files. Cross-referencing is easier.

Well, this is my own experience and of course might not be universal: As of now there is no better tool to work with CSV than a spreadsheet like Excel. So cross referencing is not a problem because in fact it is easier to load each files in separate worksheets, assign each of them a name and then use them in formula and lists. Mixing elements and relationship in a same worksheet would them require some additional filtering to make sure you target the right kind of concept. When done, exporting each worksheet in a separate CSV file is really easy.

If the goal is not to have a human edit files, but to load them in another software or to generate them to inject data in Archi, then having one or three files doesn't matter. Using CSV instead or XML or JSON does matter more.

So my feeling is that we really need to see how people are using this feature and understand their pain points (if there are some) before thinking about changing it.

FWIW, one of the people I work with was able to convert its internal capabilities catalog to elements and relations CSV file and import them successfully in Archi in only a fews days (not full time) without any issues.

[Phil Beauvoir]

It seemed a good idea to put it all into one file. Perhaps more portable. I've written the code to do it, but if users prefer to use three files I'll just go away and cry. ;-)

Seriously, though, "let the people decide!"

[gcfortin]

I would vote to leave everything as is. I generate the csv files from a spreadsheet, baseline them, and then import into Archi; so changing them would be a bit of a pain as I'd have to change code and how I baseline.

[Alberto]

Same here, I generate csv files from our assets inventory system to keep my as is model up to date, so for selfish reasons I'd like to ask not to change the csv importing method.  My only gripe with the current csv import I cannot just to import properties or relationships without including an elements file, which makes me wonder if there's such restriction on the proposed change.

[Phil Beauvoir]

I won't change the format of using three files if that's what people prefer.

> My only gripe with the current csv import I cannot just to import properties or relationships without including an elements file

I just fixed it so you can do that. In the next version you can provide all three csv files, or just one, or just two files.

Obviously the IDs have to correspond to already existing concepts if you are importing relations and properties.

Also, you will be able to select any of the csv files in the import dialog. If the other matching csv files are there, they will also be imported. If they are not there, just the single file will be imported.

For example:

You have three files, "elements.cvs", "relations.csv", and "properties.csv". You select any of these files in the Import dialog and all three files will be imported/merged into the model.

You have two files, "elements.cvs", "relations.csv". You select any of these files in the Import dialog and both files will be imported/merged into the model.

You have two files, "relations.cvs", "properties.csv". You select any of these files in the Import dialog and both files will be imported/merged into the model.

You have one file, properties.csv". You select this file in the Import dialog and only it imported/merged into the model.

You get the idea...


Phil

[Alberto]

 

[mansley]

Why not offer an option?  I like the simplicity of a single file; I've tried to do that in a lot of the imports that I process.  But I can understand people wanting to keep the existing format where there are already assets using them, or where they've mentally adjusted to using three separate files.

[Phil Beauvoir]

Because the code and format is too different and I don't want to maintain two methods. We're gong to stick with one way to do it.