andyjenkinson
commented
2 months ago Would you consider putting basic universal properties of a dataset/collection like ID, name, description, license not in a separate special FIBOA-specific object called "fiboa" but as normal properties (like they are for GeoJSON features)?
One reason is I am thinking we should try not to reinvent the wheel, eg align to existing dataset publishing standards that are well adopted in related communities that have thought about the domain much more, for example the Dublin Core covers I think all of the terms in the example (license, publisher, description): https://www.dublincore.org/specifications/dublin-core/dcmi-terms/ It makes FIBOA less 'demanding' if it limits spreading the word "FIBOA" over everything that isn't specific to FIBOA (eg "fiboa_version" is more reasonable than "fiboa->license" when you can just call it "license") and name it as an optional field in FIBOA that happens to be the same as the Dublin core term. Then I can make a single object that is compliant with JSON-LD, fiboa, GeoJSON and DCMI all in the same file/API endpoint.
The other reason is to avoid wherever possible forcing people to create separate fiboa-specific implementations of data distributions they already provide. My target really one of: a provider already has an API that provides FeatureCollections (eg we have one, Digifarm has one, planet has one, anyone who has implemented OGC Features API compliant API has one), or datasets that they already export. So, my assessment will be: what is the minimal I have to do to make what I already provide FIBOA compliant, and how proprietary is that? That is why it's different from STAC: here we're not starting from a green field, we have existing standards and existing implementations it would be advantageous to align to, because it gives us adoption very quickly. I would like to be able to make the native API and downloads we already provide to be FIBOA compliant, rather than create special FIBOA variants, which is what happens if you force me to repeat properties inside a special "fiboa" container. If we need to go down that route of separating out the fiboa domain, I would rather do it either namespaces (so make fiboa core its own namespace)
m-mohr
Related Issue(s): #4 #6
Proposed Changes:
Note: I need to merge this rather soon as otherwise I'm blocked with other work, so I may merge and release this as part of 0.2.0 and implement it in tooling, but this can always be discussed again in the future!
PR Checklist: