-
Notifications
You must be signed in to change notification settings - Fork 6
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
ConceptScheme to define subsets of the activity list #124
Comments
@nickevansuk just want to make sure I understand this first. Please correct me if I'm wrong about any of these points
At this point we have a clearly defined ConceptScheme. It inherits from the master list but only includes the results of "Group Exercise" and under. These are flattened, with one excluded and one hidden. This looks like a complete description of a collection of Concepts So why then is there also a In the example above, Concept "Azonto Fitness" is included with field If the above is true, then this is clearly a necessary extra piece of information, but why then is the "Dance Fitness" concept redefined this array given as it is already implicitly mentioned in the ConceptScheme's root |
@lukehesluke sorry the example IDs weren't accurate at all so I've updated them to make the example based on a real list, and I've edited your comment to match the updated example - so please read through and see if the questions you had still make sense / are needed? |
Hi @nickevansuk
We could replace |
We are working on an API serving Football events, so we created a subset including
This is how the response looks like:
|
Just saw your comment @jury89, great points:
@petewalker FYI ^ validator in real use! |
@nickevansuk thanks for updating everything. The questions I still have are:
|
Sure no problem:
So for this assertion:
The following are true:
Because There's some great diagrams on this here: https://www.w3.org/TR/skos-primer/#sectransitivebroader
The |
Additional suggestion based on a conversation with @domfennell:
|
Proposer
EMD, imin, MyLocalPitch
Use Case
Applying simple rules to the master list allows it to be reduced in size for specific applications. This allows the master list to serve multiple usecases while its editors share a common understanding of likely patterns of use.
Proposal
SKOS explicitly permits Concepts to be members more than one ConceptScheme: "One important feature of SKOS is that it is possible for the same concept to be linked to several concept schemes, using the skos:inScheme property." (ref)
In order to allow subsets of the master activity list to be published, this proposal suggests the use of ConceptScheme.
The arrays of
hasTopConcept
,inScheme
, andtopConceptOf
within SKOS already permit the idea of a repurposed hierarchy.Four specific rules are defined:
rootConcept
is distinct fromhasTopConcept
.ConceptSchemeRestriction
): Links thenarrower
Concepts of a Concept to itsbroader
Concept, so that they sit on the same level of the hierarchy as the itsbroader
Concept (already supported by SKOS usingbroaderTransitive
).ConceptSchemeRestriction
): Excludes either only the specific Concept (if that Concept is alsoflatten
ed), or the specific Concept and all narrower Concepts (if that Concept is notflatten
ed). Exclude means not including the concept(s) in any user-facing hierarchy view or activity auto-complete, and not including Events related to the Concept in search results.ConceptSchemeRestriction
): Hides either only the specific Concept (if that Concept is alsoflatten
ed), or the specific Concept and all narrower Concepts (if that Concept is notflatten
ed). Hides means not displaying the concept(s) in any user-facing hierarchy view or activity auto-complete, but still including Events related to the Concept in search results.Note that for a ConceptScheme no hierarchy is automatically inherrited from the parent ConceptScheme (master list) defined by the
parentScheme
, and that the hierarchy must be consistent with the constraints of theparentScheme
. Hence withinconcept
topConceptOf must be used to attach the top concepts to the ConceptScheme, andbroaderTransitive
must be used to define relationships within the ConceptScheme (consistent with the parentScheme).Also note that excluded Concepts are not present in the new ConceptScheme, and users of the ConceptScheme are not expected to include any such excluded Concepts in their query results.
So if the parentScheme includes A -> B -> C:
Hence
exclude
removes the Concept from use entirely. Whereashide
simply removes the Concept from any user-facing rendering of the ConceptScheme. For example, hiding has no effect on the results returned from a search.New properties defined
restriction
of new type ConceptSchemeRestrictionparentScheme
of type ConceptSchemerootConcept
flattenConcept
excludeConcept
hideConcept
hidden
Use in Opportunity API
Results for Events can contain
activity
including the new ConceptScheme as follows:Filtering can be achieved via:
activity.inScheme=https://example.com/schemes/emd
(activities not included in the ConceptScheme are not returned in the results)activity=9caeb442-2834-4859-b660-9172ed61ee71
(for exact match)activity[include-narrower]=9caeb442-2834-4859-b660-9172ed61ee71
(for including all activities in the hieriarchy below the match)Example
Using the following (abridged) master activity list:
The following defines a subset ConceptScheme:
Questions
flattenConcept
,excludeConcept
andhideConcept
be defined on ConceptScheme?parentScheme
the right name for that property?restriction
/ConceptSchemeRestriction
at all at this stage, or just extension props for that for now and just recognisebroaderTransitive
(array),inScheme
(array), andhasTopConcept
(array) in the modelling spec for now, along with the use of ConceptScheme for this purpose?The text was updated successfully, but these errors were encountered: