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

Feature, FeatureType and external Features #40

Open
KathiSchleidt opened this issue Nov 13, 2024 · 3 comments
Open

Feature, FeatureType and external Features #40

KathiSchleidt opened this issue Nov 13, 2024 · 3 comments
Assignees

Comments

@KathiSchleidt
Copy link
Collaborator

When we have a Feature in STA that is a parallel twin of a Feature in an external system, the FeatureType of the STA Feature should point to the conceptual (or logical or physical?) model of the featureType of the external Feature.

Could we do an example of this under the WQ IE?

@sgrellet
Copy link
Member

I'd point to the corresponding Object instance in the externalFeature.

This sounds a lot what we prototyped during the API4INSPIRE project see here https://github.com/INSIDE-information-systems/API4INSPIRE where we crosswalked between ST API and a WFS/OGC API Features

Theoretical example to have a clearer view before implementation:

  • that Feature could be a ultimateFeatureOfInterest. Say the 'Rhine' river
  • ST API contains some info about it as a STAPI:Feature
  • API4INSPIRE approach : thanks to the URI we could ask for more traversing it and asking for GeoJSON/GML serialisation (which will redirect in our system to a Geoserver query). Still, that solution is based on the behaviour of a HTTP URI resolver + a specific infrastructure. Looks really nice from a LinkedData/SemanticWeb persepective but maybe too 'SemWeb geeky' for many.
  • => Should we complement that architecture pattern with a STAPI:property based behaviour ? for example using the Property:Definition field to also contain that URI (+ expected serialization ?). This could be consistent with the recommendation we write in the report for observable property (using the Property:Definition to point to LinkedDataRegistry describing the property in all its glory)

@hylkevds
Copy link

That covers the Feature, but what about the new FeatureType?
What does the FeatureType/definition point to?

@sgrellet
Copy link
Member

sgrellet commented Nov 14, 2024

but what about the new FeatureType?

good point, I overlooked this. IMHO the overall target would be

What does the FeatureType/definition point to?

to a URI serving the feature itself (for example from an OGC API Feature service). When our URIs are back on track I'll add one for the 'Rhine'

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

3 participants