Consolidate auxiliary information about nodes into getData/setData calls
tcstewar opened this issue · 5 comments
The idea here is to get rid of the bizarre global variables that serve to associate some sort of information with a particular node in the network. In particular, we have
hrr.Vocabulary.registered
timeview.watches.FuncRepWatchConfig.config
which can both grow without bound, and have no way of removing elements when a network is closed.
This capability would also be able to get rid of the setDocumentation abuse that happens in spa.bg and spa.thalamus
Another use case is storing the x/y/z location of a node
This system should also have an interface to the nef API, allowing something like:
net.data('node')['info'] = whatever
...
something = net.data('node')['info']Sounds like a good idea. Can I propose that we call it metadata and not data?
Sure, that works for me. The java object interface would be something like
obj.setMetadata("key",value);
value = obj.getMetadata("key");
and the nef API interface will be
net.metadata('name')['key'] = value
value = net.metadata('name')['key']
For simplicity, if you ask for metadata that is not set, you get None (or null) as a response.
So metadata finds a dict attached to a node? Would a node-centric implementation make more sense than a network-centric one? I.e.,
net.get('name').metadata['key'] = value
value = net.get('name').metadata['key']I'm not really attached to either way, just putting it out there for discussion.
That would be an option, but I don't think there's a decision yet as to what net.get('name') should return. Basically, if we include net.get() as part of our API, then we have to define an API for what functions are expected to be callable on that returned object, regardless of whether we're using the Java or Theano or whatever version. Personally, I'd prefer to not have net.get() and to not have net.make* return anything at all. But that's a whole other discussion. :)
Hah, yeah for sure 😄 Friday's discussion!