Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Metadata #348

Open
dlevenstein opened this issue Oct 28, 2019 · 11 comments
Open

Update Metadata #348

dlevenstein opened this issue Oct 28, 2019 · 11 comments
Assignees

Comments

@dlevenstein
Copy link
Collaborator

extended bz_getSessionInfo that incorporates Peters metadatasystem for sessionInfo.mat creation and loading

@dlevenstein
Copy link
Collaborator Author

see also #86

@brendonw1
Copy link
Collaborator

How will this proceed? I don’t know the first thing about Peter’s system. Will Peter take the lead?

@dlevenstein
Copy link
Collaborator Author

I don't either, or have a sense really of what will be involved in the integration.

To my understanding from the conversation yesterday, the goal is to have a sessionInfo file that maintains the old structure (for backwards compadibility), but also includes the metadata from Peters system. So what is needed is a way that when bz_getSessionInfo is called the first time, it populates the sessionInfo file with the metadata from peter's system, or prompts the user to enter it.

@samamckenzie
Copy link
Collaborator

The issue, which I am sure @petersenpeter will show you, is that you want much more information than what is currently stored in sessioninfo. Peter defined a standard that mates with his database (bidirectionally, you can populate it by entering information online). What we discussed yesterday is maintaining the sloppy organization of the current sessioninfo (xml scraper) and then adding his fields as optional with redundant information to preserve backwards comptability. After looking at his organization, and how many times sessioninfo is called in buzcode (<30) I reiterate my original suggestion - abandon the current organization of sessio info and adopt Peter's whole hog. it is conceptually much better, it has more information and can more easily expand without breaking the internal logic, and it has expanded capability (through its readbility with the web database).

@dlevenstein
Copy link
Collaborator Author

That all sounds great. One thing that was nice, was the ability to easily use legacy datasets that only had the xml (when calling bz_getSessionInfo, a sessionInfo file with the info from the xml was automatically created). I just request that this ability will still be there.

@brendonw1
Copy link
Collaborator

Thanks @samamckenzie and of course @petersenpeter it sounds great.

The big question is who will lead this who actually knows Peters stuff? Someone can't start it without knowing his stuff. Is @petersenpeter the only one who can do this? Do others know his system? If we don't find a person to lead this it won't get off the ground.

@petersenpeter
Copy link
Collaborator

petersenpeter commented Oct 29, 2019 via email

@brendonw1
Copy link
Collaborator

brendonw1 commented Oct 29, 2019 via email

@dlevenstein
Copy link
Collaborator Author

I think the best thing would be for Peter to update bz_getSessionInfo so it

  1. Loads his metadata file
  2. If the file doesn't exist:
    -prompts the user to input the necessary info
    -Pulls info from the xml into the file if it hasn't been done already
    -saves the file
  3. Has option for "noPrompts" in which it just loads from the xml if no file exists

That way, we have one path to all the metadata, (per #360), which makes the file from all the proper information if it hasn't been made yet.

Does this seem reasonable/feasible?

@petersenpeter
Copy link
Collaborator

petersenpeter commented Oct 30, 2019 via email

@petersenpeter
Copy link
Collaborator

petersenpeter commented Oct 30, 2019 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants