Open asonnenschein opened 10 years ago
lets discuss in May
@smrazgs @ccaudill @jessica-azgs We should discuss this before refactoring the contribute form. I think this is a much more organic way to organize our data within CKAN's database structure and would require minimal effort.
all makes good sense
@asonnenschein Was this considered in the new contribute form?
Yup. The backend should be all set, but the UI still needs to be able to handle resource distributions.
@FuhuXia Is any of this useful? If not, we can close this issue.
CKAN uses a parent/child relationship system for organizing uploaded and harvested data. Parents are called 'Packages' and children are called 'Resources'. Packages have a horizontal relationship with other packages; resources have a vertical relationship with their package and a horizontal relationship with other resources within the same package.
The NGDS package distinguishes between Tier 1, 2 and 3 datasets. Tier 3 data conforms to a USGIN content model.
As of now, the package level of CKAN is completely ignorant of anything regarding USGIN. Once a user creates their package, they can add resources to that package. At the resource level, the user can start binding USGIN content model information to the resource object. The content model URI, version URI and layer are all recorded.
Just like CKAN's system of data management, USGIN content models have parent/child relationships. Content model URIs have horizontal relationships with other content model URIs. Version URIs have two-way vertical relationships with a single model URI and one or more layers, and horizontal relationships with other version URIs of the same model URI. Layers have a vertical relationship with a version URI and can have a horizontal relationship with one or more layers within the same version URI.
A more organic approach to data management in CKAN with USGIN would probably be for the user to bind a content model URI/ version URI to the package level of CKAN and then at the resource level they start binding individual layers to datasets. This would also enforce some kind of solidarity within packages that does not exist right now. Organizing data as just described would prohibit users from duplicating layers in content models; if they had a duplicate dataset they would have to upload it as a tier 2 dataset.