❓ Should Full_Database_Backend be renamed to Main_Database?

I’ve been thinking about how we label our data collections, and I feel like the term "database" should really cover everything, including our Broker Guide and Transfer Agent tables.

I think we should rename the table that's got all the info on issuers, their transfer agents, investor relations, and DRS data. Specifically, this is what I'm referring to. I believe a new name could help everyone understand what’s in it more clearly.

What do you all think? Looking forward to your ideas!

IMO database nails it. i am not that creative so I can't think of a better word.

IMO database nails it. i am not that creative so I can't think of a better word.

Thanks Bob. I'm also having trouble coming up with an alternative name. I was thinking Issuer DRS Info, but that doesn't sound like the perfect fit here.

I personally think Database is broad and does cover info on stocks, brokers, transfer agents, etc. I feel that adding labels or qualifiers to it would make it less so.

Maybe Databases, plural? I can appreciate that if we're specifically/internally thinking about the stock info and data as the core 'database', which is by far the largest set of data, then it might be at the detriment to perception or contribution to other datasets.

Or, do you think it would help work flow and documentation if other subsets of data that are still part of the larger whole be in separate repos or sections of this repo? Database - Stocks', 'Database - Issuers', 'Database - Transfer Agents' etc etc etc

I personally think Database is broad and does cover info on stocks, brokers, transfer agents, etc. I feel that adding labels or qualifiers to it would make it less so.

Maybe Databases, plural? I can appreciate that if we're specifically/internally thinking about the stock info and data as the core 'database', which is by far the largest set of data, then it might be at the detriment to perception or contribution to other datasets.

Or, do you think it would help work flow and documentation if other subsets of data that are still part of the larger whole be in separate repos or sections of this repo? Database - Stocks', 'Database - Issuers', 'Database - Transfer Agents' etc etc etc

Actually, now that I think about it I can just set up folders within this repository and create separate links for each one. We'll need to settle on subdomains for them as well (maybe issuers.database.whydrs.org, etc etc?). On the Google sheet, just to be consistent, I think that should be renamed as well.

@BibicJr

Might we chat publicly on the main "end users" we're "selling" each of these data product/access tools to? Forgive me if this happened somewhere else, as I must have missed the convo. Here's my understanding of the current config:

Legacy Rolodex: A Gsheet with additional info on industry data
Broker Guides: An effort spearheaded foundationally by @BibicJr
Transfer Agent tables: Primary reference pioneered by @JamesAlfonse

It's certainly a quandary of whether to encompass everything under "one roof" or allow for specific fragmented references. This came up also in the organization of our repos, and I'm leaning towards the specificity over aggregation approach. I get that it can lead to less "social attention" and popularity, but I think it's probably better for organization, external references, and localized technical upgrades.

@BibicJr

Might we chat publicly on the main "end users" we're "selling" each of these data product/access tools to? Forgive me if this happened somewhere else, as I must have missed the convo. Here's my understanding of the current config:

Legacy Rolodex: A Gsheet with additional info on industry data

Broker Guides: An effort spearheaded foundationally by @BibicJr

Transfer Agent tables: Primary reference pioneered by @JamesAlfonse

It's certainly a quandary of whether to encompass everything under "one roof" or allow for specific fragmented references. This came up also in the organization of our repos, and I'm leaning towards the specificity over aggregation approach. I get that it can lead to less "social attention" and popularity, but I think it's probably better for organization, external references, and localized technical upgrades.

Just to give more context, and correct me if I'm wrong here: @BibicJr spearheaded the Broker Guides/Broker Data, @tehchives put together Transfer Agent Information, and I started the Issuer/Transfer Agent/IR sheet. These were originally three separate files, and I copied them over into one sheet for accessibility and tool-building.

The search tool that's available here was built by @apes-on-parade using data from an earlier point in time and including the combined sheet as one of its sources. The source code for that tool is available here, and is forked here.

I'm open to either segmenting the databases by repo, or encompassing them all in one. Personally, I'm leaning towards one repo with separate folders; any parties interested in downloading the data could click Code -> Download .zip in one shot. The Readme and License files would also stay updated from one; multiple repositories could mean those files are outdated if we aren't on top of it.

@JamesAlfonse

I agree with the idea to combine everything into one repo, based on the voice call at 2pm ET today with James, Throw/apes-on-parade, Chives, Bob, Bibic, Bur, ISayBullish, and myself. This approach will also probably implicate updating the LICENSE structure.

It seems all these functionalities are highly interrelated, and keeping them in separate repos could lead to an unnecessary amount of cross-referencing. As voiced, I'd ultimately love to see all these items in a single page/react app/reference URL.

Meeting Takeaways

Embedded DRS-data React Frames

Throw commented that the broker page on WhyDRS.org should have interactive functionality. They also noted that dynamic features are quite challenging to implement directly with Wix.

Prudent Notes from @JamesAlfonse

Throw advised that having more tables would be better
- Having more tables makes it easier to keep things up to date
- Throw has different JSON files and CSVs from different sources
- Showed off the DRS request template, which would include what information is needed to complete the request (to help people with the DRS process), as a proof of concept
Bur asked if we were planning on monetizing this data. He brought up PII and insurance, which would need to be taken into consideration if we wanted to monetize it in the future¹.
Throw advised to avoid using APIs when possible².
- Throw created most of the drs-data repository in about a week 🦾
James mentioned a simple view of issue-transfer agent data from the React app on whydrs.org/database, and the advanced view.
John brought up that he searched for TSLA, and it showed multiple transfer agents. The React app pulls data from multiple sources.
- James advised that the GSheet has a column for the source of where the transfer agent information came from, which was peer-reviewed.
Throw and Bibic are going to work on Wix broker data; this will eventually be put into GitHub issues where applicable.
Bibic brought up Valor numbers as well as CUSIP and ISIN. Valor numbers are used in Switzerland and Belgium³.

Notes from John: Definitely could see this since we're collating public info. Email specifically is quite the weird thing from my view, as a kind of challenge protocol with questionable spam controls. ↩
This implicates these segregation choices. ↩
Quite the rabbit hole here! Seems the Commission is moving towards LEIs, too. Ideally, I think we could all just use CIKs, which implicates the SEC as a standardized global reporting toolkit. ↩

I remember chatter about data scraping Edgar. was that in here or did I see it elsewhere. and is it active. seems like if Tesla is showing multiple TAs the data scraper would be able to remedy this on all tickers. sorry just spilling my thought while they are fresh.

@JamesAlfonse

I agree with the idea to combine everything into one repo, based on the voice call at 2pm ET today with James, Throw/apes-on-parade, Chives, Bob, Bibic, Bur, ISayBullish, and myself. This approach will also probably implicate updating the LICENSE structure.

It seems all these functionalities are highly interrelated, and keeping them in separate repos could lead to an unnecessary amount of cross-referencing. As voiced, I'd ultimately love to see all these items in a single page/react app/reference URL.

Meeting Takeaways

Embedded DRS-data React Frames

Throw commented that the broker page on WhyDRS.org should have interactive functionality. They also noted that dynamic features are quite challenging to implement directly with Wix.

Prudent Notes from @JamesAlfonse

Throw advised that having more tables would be better

Having more tables makes it easier to keep things up to date

Throw has different JSON files and CSVs from different sources

Showed off the DRS request template, which would include what information is needed to complete the request (to help people with the DRS process), as a proof of concept

Bur asked if we were planning on monetizing this data. He brought up PII and insurance, which would need to be taken into consideration if we wanted to monetize it in the future1.

Throw advised to avoid using APIs when possible2.

Throw created most of the drs-data repository in about a week 🦾

James mentioned a simple view of issue-transfer agent data from the React app on whydrs.org/database, and the advanced view.

John brought up that he searched for TSLA, and it showed multiple transfer agents. The React app pulls data from multiple sources.

James advised that the GSheet has a column for the source of where the transfer agent information came from, which was peer-reviewed.

Throw and Bibic are going to work on Wix broker data; this will eventually be put into GitHub issues where applicable.

Bibic brought up Valor numbers as well as CUSIP and ISIN. Valor numbers are used in Switzerland and Belgium3.

Footnotes

Notes from John: Definitely could see this since we're collating public info. Email specifically is quite the weird thing from my view, as a kind of challenge protocol with questionable spam controls. ↩

This implicates these segregation choices. ↩

Quite the rabbit hole here! Seems the Commission is moving towards LEIs, too. Ideally, I think we could all just use CIKs, which implicates the SEC as a standardized global reporting toolkit. ↩

It would be a challenge to consolidate all those items into a single page/app.

However, I welcome that challenge.

I'm envisioning the react app that's currently displayed on whydrs.org/database, but it's on a separate page (maybe database.whydrs.org?). This would be the default view, and there could be an option for a more 'advanced' view that includes the full issuer/transfer agent/ir info/drs data table.
From there, we could have a slider or choice chips that lets end users switch tables to view broker data or transfer agent data.

I think it would make sense to have the app on its own page so that it can scale properly to the end user's browser.

Let me know if this makes sense or if I can clarify it in any way.

It would be a challenge to consolidate all those items into a single page/app.

However, I welcome that challenge.

I got chills!

I'm envisioning the react app that's currently displayed on whydrs.org/database, but it's on a separate page (maybe database.whydrs.org?). This would be the default view, and there could be an option for a more 'advanced' view that includes the full issuer/transfer agent/ir info/drs data table. From there, we could have a slider or choice chips that lets end users switch tables to view broker data or transfer agent data.

I think it would make sense to have the app on its own page so that it can scale properly to the end user's browser.

Let me know if this makes sense or if I can clarify it in any way.

Sounds like a fantastic approach to me. There's a ton of data and it's possible to be overwhelm users, so putting more detailed info behind a few tabs or an 'advanced' tab works for everyone. Generally, I think customization and accessibility are also very popular for end users, so that's another win.

Scaling properly to the browser is great proactive thinking, well done on that. I am ignorant of the details and thankful for your perception!

Stellar idea to have a basic introductory view, then some kind of pop-up or advanced view with all the known info when you click an entry. I'm partial to including an edit this data button that hrefs directly to the database entry in GitHub, as far as that might be feasible.¹ Perhaps we could just center our distributed development efforts in this repo, and see what it turns into?

There already seem to be so many interesting use-cases just waiting to be built by passionate community members. I understand that many data resources are dispersed in centralized silos right now. Perhaps we could migrate everything here (assuming rights check out), and return to the naming once we've started building incredible frontends like your user-friendly buttons?

In an effort to turn visitors into contributors (no matter the size of a change) with as few steps as possible. ↩

Stellar idea to have a basic introductory view, then some kind of pop-up or advanced view with all the known info when you click an entry. I'm partial to including an edit this data button that hrefs directly to the database entry in GitHub, as far as that might be feasible.1 Perhaps we could just center our distributed development efforts in this repo, and see what it turns into?

That would be fantastic to have a button that could take potential contributors directly to the row within a .db file they'd want to edit, streamlining the process. All they'd have to do is then submit a pull request.

Thinking on this further, the sheet/table containing Issuer, Transfer Agent, IR info etc. could be called the "Main Database" and labeled "Main_Database" on the Google Sheet and .db file.

@JamesAlfonse

@JamesAlfonse is it logistically efficient to have both the db file and the Sheet?

@JFWooten4

@JFWooten4 For now it's the easiest way non-technical contributors can submit data. The goal is to eventually deprecate the Google sheet once we have a way to simplify the process for contributors a la #37

This was successfully renamed in Google Sheets and throughout this repository.

Navigation Menu

Repository navigation

❓ Should Full_Database_Backend be renamed to Main_Database? #25

Meeting Takeaways

Embedded DRS-data React Frames

Prudent Notes from @JamesAlfonse

Meeting Takeaways

Embedded DRS-data React Frames

Prudent Notes from @JamesAlfonse

Footnotes

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

❓ Should Full_Database_Backend be renamed to Main_Database? #25

Description

Activity

bobmahalo commented on Oct 25, 2024

JamesAlfonse commented on Oct 25, 2024

tehchives commented on Oct 25, 2024

JamesAlfonse commented on Oct 25, 2024

JFWooten4 commented on Oct 25, 2024

JamesAlfonse commented on Oct 25, 2024

JFWooten4 commented on Oct 26, 2024

Meeting Takeaways

Embedded DRS-data React Frames

Prudent Notes from @JamesAlfonse

Footnotes

bobmahalo commented on Oct 27, 2024

JamesAlfonse commented on Oct 27, 2024

Meeting Takeaways

Embedded DRS-data React Frames

Prudent Notes from @JamesAlfonse

Footnotes

tehchives commented on Oct 28, 2024

JFWooten4 commented on Oct 29, 2024

Footnotes

JamesAlfonse commented on Oct 29, 2024

JamesAlfonse commented on Jan 12, 2025

JFWooten4 commented on Jan 13, 2025

JamesAlfonse commented on Jan 14, 2025

JamesAlfonse commented on Jan 30, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions