-
Notifications
You must be signed in to change notification settings - Fork 13
Description
Some of the endpoints are based on SPARQL queries that produce predicates not defined in the ontology.
For example (a calculated value) in https://github.com/ukparliament/Data.Api.FixedQuery/blob/170a32813446ff4f0312ba9c1fa1e5b6bd407a97/Parliament.Data.Api.FixedQuery/Sparql/group_by_id.sparql#L22 and https://id.parliament.uk/schema/memberCount (a marker property) in https://github.com/ukparliament/Data.Api.FixedQuery/blob/4b2f02ad361d07a5393fb27a6d93a5a4099de76d/Parliament.Data.Api.FixedQuery/Sparql/member_a_to_z.sparql#L3https://id.parliament.uk/schema/value
This is legal and doesn't cause any functional problems, but it's unfortunate in that these predicates are not further described. Their meaning is from their name, their query context and their use by consumers.
This practice also increases the likelihood of a naming collision (where a query author uses a property name not as intended by the ontology).
I think query authors should be free to shape their output as they wish (although I'd recommend using ontology properties as intended wherever possible). I also think we should have a policy for bespoke predicates: Don't use the Parliamentary namespace (id.parliament.uk).
Alternatives I see are
- URNs:
urn:uk-parliament:website-query:memberCount - Example URIs:
http://example.com/uk-parliament/website-query/memberCount
Important is not to reuse a namespace and not to appear to be dereferencable.
We should definitely consider the impact on GROM and its decorators.
@christopheralcock, @mattrayner, what do you think?