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

Directory Structure #2

Open
emilbayes opened this issue Sep 25, 2015 · 1 comment
Open

Directory Structure #2

emilbayes opened this issue Sep 25, 2015 · 1 comment

Comments

@emilbayes
Copy link
Member

Let's discuss how we should organise the repo now that we've decided that using the wiki feature wasn't ideal.

I imagine a folder structure along these lines?

.
├── LICENSE.md
├── README.md
├── government
│   ├── README.md
│   ├── bbr.md
│   ├── dawa.md
│   ├── dst.md
│   ├── ft.md
│   ├── kortforsyningen.md
│   ├── miljoeportal.md
│   ├── uddannelsesstatistik.md
│   ├── uni-c.md
│   └── virk.md
├── museums-and-archives
│   ├── README.md
│   ├── kb.md
│   ├── natmus.md
│   ├── politietsregisterblade.md
│   ├── ppt-museum.md
│   └── smk.md
└── private-companies
    ├── README.md
    ├── dr.md
    └── postdanmark.md

However there are some unsolved problems with this structure. Should each dataset have its own file, or should they be grouped by organisation? I've based file names on FQDN, but then organisations like AU which have many diverse datasets might become hard to get an overview of. Or maybe we should try and group by categories like Infrastructure, History, Environment, Media etc. ?

@AndreasMadsen
Copy link
Contributor

Should each dataset have its own file, or should they be grouped by organisation

I think it would be best to add a file for each resource in general. But there are nice cases like dawa.aws.dk where a single file for dawa is enough. In that case it shouldn't get its own directory.

I've based file names on FQDN

I like that. Maybe we should add .dk but it might be redundant in this case. But I definitely think dawa should be dawa.aws.md.

but then organisations like AU which have many diverse datasets might become hard to get an overview of.

I don't think they have that many datasets them self. Its is more a documentation on what are the social issues and what organizations provides datasets that can describe them. So lets revisit that if it becomes an issue.

Or maybe we should try and group by categories like Infrastructure, History, Environment, Media etc. ?

If the purpose is to have an internal documentation of the raw APIs and then later provide module/API on top of that, then it makes sense to do the (organization-type, organization, resource).

If the purpose is to have an overview of other dataminers, then the data types makes more sense. However doing this means we can't organize the files using FQDN.

I prefer the organization-type, as it makes it easier to edit the file (involves a finding a file I already know about). Browsing the files using data-types can then be done by creating an external index.

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

2 participants