|Discuss Query specification reference set|
Alejandro has asked us to consider extensions to the |Query specification reference set| for better support of the computable languages.
- How many query refsets?
- Should everyone add their query rows to the same query refset? Alternatively, we could define one query refset per computable language and restrict the type of the query appropriately (e.g. create an |Expression constraint query refset|, where the query is of type |Expression constraint parsable string|)
- Potential query refset attributes
- referencedComponentId: |Concept type component| (or more specifically |Reference set concept type component|)
- This defines the reference set into which the expansion of the query (executed against the given substrate) is populated. Initially, this will always be a simple type refset - however, we may wish to consider populating other types of refsets in future versions of the query language.
- query: |String| (... or perhaps more specifically |SNOMED CT parsable string|)
- queryLanguage: |Concept type component| (e.g. |Expression constraint language|)
- Note: This attribute could be deleted if (a) we create separate query refsets for each of the main languages, or (b) rely on parsing the queryLanguageVersion URI to determine the language used
- queryLanguageVersion: |Uniform resource identifier|
- Defines the query language version (and perhaps profile if relevant) used by the query
- expansionGenerated: Boolean (mutable)
- A boolean flag that indicates whether or not the refset referred to by referencedComponentId has been populated by executing the query against the given substrate
- Note: Would it be an error to have expansionGenerated = 0, but still have members in the refset referred to by the referencedComponentId?
- substrate: |Uniform resource identifier| ... http://snomed.info
- The edition and/or version of the substrate used to generate the expansion into the refset identified by referencedComponentId. If no specific substrate is defined, then "http://snomed.info" could be used as a generic value.
- Note: This attribute could be deleted if we assume that this will be defined in the query itself - however doing this will only be possible using the full SNOMED query language (with the filter substrate = "....")
- How many rows in the query refset?
- Since executing a query on different substrates may result in a different expansion (and therefore require a different referencedComponentId to indicate a different expansion refset), a separate row of the query refset should be created for each different query+substrate combination.
Alternative suggestion from Harold - 2 reference sets
- Query ref set (refsetId = |query refset|)
- id: UUID
- referencedComponentId - Query definition ref set
- query - string
- <metadata>Name, author, (etc ... Dublincore)
- edition/substrate: URI (It was suggested that if the query is written based on a specific national/local edition, then we may need to identify which edition it was based on)
2. Query Expansion ref set (refsetId = |query refset|)
- query: UUID
- queryLanguage: URI
Based on the notes from this week's meeting (2017-03-15 - SLPG Meeting), could all members of the SLPG please give me their thoughts on how we could modify the |Query specification reference set| (22.214.171.124 Query Specification Reference Set) to better support the computable languages. Please be as specific as you can - and name any new reference sets, reference set attributes and their attribute types that you think are required. Please also explain your reasoning.
Thank you! Linda.