-
Notifications
You must be signed in to change notification settings - Fork 31
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
What is the proposed way to retrieve available schemata or schema/id combinations for different identifiers #109
Comments
My thoughts on this: In #129 there is a first proposal for this kind of meta data. There, my suggestion is to expand @MetroMarv 's suggestion:
That solves a (small) part of this ticket: retrieving the id's for a specific scheme for locations. This is sort of trivial since this scheme is part of the URI and it thus (more or less by accident) has a name. Building on that, we could then have very detailed api's exploring schemata:
However, this feels a bit heavy for something that is quite possibly very static. We could combine all this in a single 'schemata' message. I'd expect only the actual available identifiers to be quite dynamic and thus warranting its own endpoint. For
These also fit into the schemata scheme:
But we do not have a way to retrieve the values, unless we do this (or combine it into the previous uri's):
To summarize:
Do we treat them all as equal or is it fine to differentiate exploring the actual available identifiers between these schemata? |
I want to rise this issue back to live :) We are also running into the situation now where we need to pass an information about schemes and also in some cases (for example breeds) a values inside the scheme. I like the proposal and solution presented by @alamers with small adjustments maybe: for retrieving list of supported schemas and the values we could use:
Could this be an acceptable and common solution for scheme information retrieving? |
I like Antons approach to retrieve schemata. I was thinking whether we could leave "locations" out here because we could just have a look at the /locations endpoint to see which schemata are available. But after thinking about it a littel bit more I prefer to list location schemata as well because the schemata/locations/ endpoint would then (in contrast to the /locations/ endpoint) provide a list of all supported schemata. This makes a lot of sense to me as this provides some information about the capabilities of the system. |
As discussed on today's meeting for schemata - going with #109 (comment) proposal, but placing endpoints behind /locations:
Is it proper terminology {schemata} for schema type and {schema} for specific schema? For messaged it would be probably enough to have string based values for /schemata and /schemata/{schemata}, but perhaps more complex message for scheme values? icarResource inheritance needed? {
"type": "object",
"description": "Schema id value type",
"properties": {
"id": {
"type": "string",
"description": "Id/identifier for scheme value"
},
"name": {
"type": "string",
"description": "Friendly name for identifier (maybe translation?)"
}
}
} |
Well, values could just be a list of strings (except for identifiers as Anton suggested), however, we would maybe loose paging and consistency, so I'D still go for (very simple) objects. I'd not make any of those inherit from resources. Apart from that I'm all good with Antons approach. |
Simple object for 'schema type' and 'schema' could be something like: {
"type": "object",
"description": "Schema type/schema name type",
"properties": {
"name": {
"type": "string",
"description": "Schema type/schema name"
}
}
} and for schema values: {
"type": "object",
"description": "Schema id value type",
"properties": {
"id": {
"type": "string",
"description": "Id/identifier for scheme value"
},
"name": {
"type": "string",
"description": "Friendly name for identifier (maybe translation?)"
}
}
} any notes, feedback on that @cookeac @alamers @erwinspeybroeck ? |
Feedback from me:
|
Fixed by #196 |
While implementing the ICAR interface, we came across the issue that we need to know location schemata and ids beforehand, especially if we want to allow the user to choose a specific location.
We will now implement an endpoint where we will deliver all available schema/id combinations for locations together with a "name" (the same that we use in our application) so that the user can identify the locations in an external tool.
However, this seems to be a more general issue. Getting information about the supported schemata for e.g. location ids, animal ids etc. for automatic data exchange whould be very helpful.
My proposal would be to support at least these features:
For locations (as these are a very central aspect of the interface) I'd even propose to have at least a list of available schema/id combinations. Also possible would be a list of locations, each identified by a name, and each having a collection of alternative identifiers (similar to what animals currently have).
The text was updated successfully, but these errors were encountered: