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

Working a different example into the model #6

Open
skybristol opened this issue Jul 25, 2016 · 0 comments
Open

Working a different example into the model #6

skybristol opened this issue Jul 25, 2016 · 0 comments

Comments

@skybristol
Copy link

In USGS, we are working on the data transformation pipeline as part of this overall project. The Registry this project is establishing (current working instance at http://23.23.228.241:32781/) is a dependency where we need to consult it for properties and schemas that the pipeline encounters and wants to better understand in order to aid data integration efforts.

I'm trying to back into the model you've proposed using one of our own examples that I re-hosted as an ontology in the ESIP COR here:

http://cor.esipfed.org/ont/?uri=http://mmisw.org/ont/ioos/marine_biogeography

If I understand correctly, you would refer to this as a data-object that would be registered here:

http://resources.usgin.org/uri-gin/dtr/class/data-object

The properties in that data-object would ultimately be found in...

http://resources.usgin.org/uri-gin/dtr/def/property

We might find some cases where the conceptual properties in what we call the MBG schema are already in the registry you've started with the USGIN schemas, but then some things that don't line up. For instance, it looks like you are considering geometry...

http://resources.usgin.org/uri-gin/dtr/class/data-type/geometry

...to always be a blob...

http://resources.usgin.org/uri-gin/dtr/class/data-type/blob

...but we have cases like "footprintWKT" that we pull from Darwin Core...

http://rs.tdwg.org/dwc/terms/#footprintWKT

...that is a different data type entirely but represents the same concept. How would we expand the geometry concept in the Digital Crust Registry to accommodate tying a property to a WKT formatted geometry?

Am I also following the logical construction of the model appropriately so far?

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

1 participant