Hello dear BrainVisa experts!
I am trying to add a new custom attribute to a graph node (using PyAims).
I tried to add the attribute to the dictionary:
node['my_attribute_key'] = some_value
This however, works only while I am in the same session. I.e. later in my code I can successfully access node['my_attribute_key'] and get the correct value.
However after I save the graph with aims writer, and reload it, the node has no more 'my_attribute_key'...
write method does not fail, it prints no error or warning. Sadly, it just ignores my attribute...
The attribute I am trying to add is a result of a long computation, which I will need over and over again. I really have to save it for later use.
I tried to override existing attribute with my calculated value and this worked. This workaround, however, looks too ugly to me, and I prefer not to use it (it proofs, however, that there is no problem with my writing procedure in general).
Any cue how I can save my own attribute (without destroying existing one) would be highly appreciated!
Kind regards,
Ruslana.
Custom node attributes are not persistent
-
riviere
- Site Admin
- Posts: 1361
- Joined: Tue Jan 06, 2004 12:21 pm
- Location: CEA NeuroSpin, Saint Aubin, France
- Contact:
Re: Custom node attributes are not persistent
Hi,
You're right, attributes that are set manually in a graph and which are not part of an attributes set which has been defined are not saved. This is half an intentional behaviour, an half a limitation of the old .arg format. Here is a short explanation:
* when working with graphs, we quite often set some temporary attributes in them which we do not want to save, so at the beginning (about 20 years ago...) this was what we wanted, and we decided to declare all attributes that should be saved. There is a config file for it, which is <brainvisa_dir>/share/aims-<version>/nomenclature/syntax/graph.stx, this is what we call a "syntax file".
* As a matter of fact, the .arg format is not self-explanatory, and does not include any way to specify the type of "unknown" new attributes, thay are written in ASCII format without a way to know if they are strings, numbers, lists or something else, so this has to be specified somewhere else (in the graph.stx syntax file above). If the format is changed (for a json or xml-based format for instance) this could be somewhat extended, but we have never taken time to to so.
* We also wanted to manage a graph format version, which allows some mandatory or optional attributes, and which make sure that they comply the same syntax. In this context, additional attribute would compromise this format homogeneity and compliance, so this was another reason not to allow to extend the attributes set.
But we agree that this behaviour has also drawbacks.
The "syntax files" can be extended and copied somewhere else, but the high-level graph readers will only look for the "official" syntax file location, which is the one specified above, to it is not really easy to change. It is possible to use them using lower-level reader/writer objects, which have not been bound in python (they are available only in C++, currently).
Denis
You're right, attributes that are set manually in a graph and which are not part of an attributes set which has been defined are not saved. This is half an intentional behaviour, an half a limitation of the old .arg format. Here is a short explanation:
* when working with graphs, we quite often set some temporary attributes in them which we do not want to save, so at the beginning (about 20 years ago...) this was what we wanted, and we decided to declare all attributes that should be saved. There is a config file for it, which is <brainvisa_dir>/share/aims-<version>/nomenclature/syntax/graph.stx, this is what we call a "syntax file".
* As a matter of fact, the .arg format is not self-explanatory, and does not include any way to specify the type of "unknown" new attributes, thay are written in ASCII format without a way to know if they are strings, numbers, lists or something else, so this has to be specified somewhere else (in the graph.stx syntax file above). If the format is changed (for a json or xml-based format for instance) this could be somewhat extended, but we have never taken time to to so.
* We also wanted to manage a graph format version, which allows some mandatory or optional attributes, and which make sure that they comply the same syntax. In this context, additional attribute would compromise this format homogeneity and compliance, so this was another reason not to allow to extend the attributes set.
But we agree that this behaviour has also drawbacks.
The "syntax files" can be extended and copied somewhere else, but the high-level graph readers will only look for the "official" syntax file location, which is the one specified above, to it is not really easy to change. It is possible to use them using lower-level reader/writer objects, which have not been bound in python (they are available only in C++, currently).
Denis