...
- RDF Lists used as the object of the
skos:memberList
property, in which there is not exactly one first element. - RDF Lists used as the object of the
skos:memberList
property, that have members that are themselves RDF Lists. - Cycles of the
skos:broader
/skos:narrower
relations. We reject the entire vocabulary if we find such a cycle. - If the
includeConceptSchemes
browse flag is set:- Concept scheme members that are concept schemes or collections. (We do expect to "cope" with members that are things other than concepts, as explained in the subsection for the
skos:inScheme
property below.) - For each concept scheme, there may not be a top concept of that concept scheme that has a broader concept that is also in the same concept scheme. We have this as an exclusion by permission of the SKOS Reference, section 4.6.3: "An application may reject such data but is not required to." NB: this is different from what we call the "classic" behaviour of the browse visualization, in which the top concept properties are ignored, and the hierarchy is displayed based solely on the broader/narrower properties.
- Concept scheme members that are concept schemes or collections. (We do expect to "cope" with members that are things other than concepts, as explained in the subsection for the
- If the
includeCollections
browse flag is set:- Cycles of collection membership. (Collections may be nested to an arbitrary depth, and membership may induce a polyhierarchy, but the nesting must not induce a cycle.)
- An ordered collection that has values specified using
skos:member
that are not also included in the collection'sskos:memberList
. An ordered collection must specify its members using theskos:memberList
property. It may also specify those values usingskos:member
, since SKOS S36 says: "For any resource, every item in the list given as the value of theskos:memberList property
is also a value of theskos:member property
."
- Type inference based on the presence of triples with the
rdf:subClassOf
predicate, and the defined domain/range of user-defined predicates.- (But there is some type inference at the level of individual triples based on the rules stated in the SKOS Reference. For example, from the triple
my:C1 skos:broader my:C2
, the two additional triplesmy:C1 a skos:Concept
andmy:C2 a skos:Concept
are inferred.)
- (But there is some type inference at the level of individual triples based on the rules stated in the SKOS Reference. For example, from the triple
...
- Under what circumstances should a concept C appear at the top level of the visualization?
- There are a couple of "big ideas" or guiding principles:
- A concept C is shown at the top level if it would otherwise not be shown anywhere else in the visualization, i.e., as a descendant of some other node (whether that node is another concept, or a concept scheme, or a collection).
- We want to show as much of the broader/narrower hierarchy information in the visualization as we can. If that might otherwise be "lost" or "hidden" (e.g., through the setting of the
includeCollections
flag and the fact that concepts in a broader/narrower hierarchy may also be members of collections), then a concept C may also be shown at the top level to enable this information to be plain to the user. (The exact circumstances under which it will be shown at the top level are explained below.)
- We distinguish four cases based on the values of the
includeConceptSchemes
andincludeCollections
browse flags. - If
includeConceptSchemes
is false, andincludeCollections
is false.- This is the "classic", default case. No attention is paid to the
skos:inScheme
or top concept properties, either their presence or absence. The concept C appears at the top level if and only if there does not exist any other concept marked as broader. NB: this means that a concept marked as a top concept does not necessarily appear at the top level: it won't, if it has a broader concept, a situation explicitly permitted by the SKOS model. (See the SKOS Reference, section 4.6.3 and Example 8. Note that the exclusion mentioned in the Exclusions section above doesn't apply in this case, i.e., becauseincludeConceptSchemes
is false.)
- This is the "classic", default case. No attention is paid to the
- If
includeConceptSchemes
is true, andincludeCollections
is false.- If the concept C is marked as belonging to any concept scheme, then the concept will not appear at the top level. (The concept schemes will appear at the top level, and the concept will appear (somewhere) as a descendant of every concept scheme to which it is marked as belonging.)
- If the concept C is not marked as belonging to any concept scheme, then a situation similar to the "classic", default case above applies: the concept C will appear at the top level if and only if there does not exist any other concept marked as broader and which is also not marked as belonging to any concept scheme.
- If
includeConceptSchemes
is false, andincludeCollections
is true.- This is like, but not the same as, the "classic", default case above. Hierarchy information from the broader/narrower properties is reflected in the visualization, and no attention is paid to the inScheme or top concept properties. The concept C appears at the top level if and only if either of the following applies:
- The concept C is marked as a broader concept than another concept, and there does not exist any other concept marked as broader than concept C. NB: this means that a concept marked as a top concept does not necessarily appear at the top level: it won't, if it has a broader concept, a situation explicitly permitted by the SKOS model. (See the SKOS Reference, section 4.6.3 and Example 8. Note that the exclusion mentioned in the Exclusions section above doesn't apply in this case, i.e., because
includeConceptSchemes
is false.) - The concept C is not marked as a broader concept than another concept, nor is any other concept marked as a broader concept than C, and C is not marked as belonging to any collection. In other words, concept C is shown at the top level if it is completely "isolated" from all other concepts and from all collections.
- The concept C is marked as a broader concept than another concept, and there does not exist any other concept marked as broader than concept C. NB: this means that a concept marked as a top concept does not necessarily appear at the top level: it won't, if it has a broader concept, a situation explicitly permitted by the SKOS model. (See the SKOS Reference, section 4.6.3 and Example 8. Note that the exclusion mentioned in the Exclusions section above doesn't apply in this case, i.e., because
- (If the concept C is marked as belonging to a collection, then the concept will appear (somewhere) as a descendant of the collection. Concept C's membership of a collection prevents its appearance at the top level in the case that concept C is not also involved in a broader/narrower hierarchy, as explained in the previous point.)
- (Does this mean that if there are collections, and all concepts are members of at least one collection, then a concept will nevertheless always be shown at least twice, e.g., by traversal from a concept at the top level, and as a descendant of a collection? No, not necessarily. In this case, if there is no use of the broader/narrower hierarchy, then all concepts will appear only as descendants of collections.)
- This is like, but not the same as, the "classic", default case above. Hierarchy information from the broader/narrower properties is reflected in the visualization, and no attention is paid to the inScheme or top concept properties. The concept C appears at the top level if and only if either of the following applies:
- If
includeConceptSchemes
is true, andincludeCollections
is true.- If the concept C is marked as belonging to any concept scheme, then the concept will not appear at the top level. (The concept schemes will appear at the top level, and the concept will appear (somewhere) as a descendant of every concept scheme to which it is marked as belonging.)
- If the concept C is not marked as belonging to any concept scheme, and it is not marked as belonging to any collection, then a modification of the "classic" first case applies: the concept C appears at the top level if and only if there does not exist any other concept marked as broader and which is also not marked as belonging to any concept scheme. (In this case, concept C might or might not be marked as being broader than other concepts, which might or might not be marked as belonging to any concept schemes, but this plays no part in the determination of whether or not concept C is shown at the top level.)
- If the concept C is not marked as belonging to any concept scheme, but it is marked as belonging to any collection, then a different modification of the "classic" first case applies: the concept C appears at the top level if and only if both of the following conditions apply:
- There does not exist any other concept marked as broader and which is also not marked as belonging to any concept scheme.
- The concept C is marked as a broader concept of any other concept which is not marked as belonging to any concept scheme. In other words, concept C will not appear at the top level if it can be "swallowed up" by a collection, without any loss of broader/narrower hierarchy information that would be displayed below a concept scheme node. (Oops, yes, we will lose broader/narrower hierarchy information in the case that C has one or more narrower concepts, each of which is marked as belonging to any concept scheme.)
- (If the concept C is marked as belonging to a collection, then the concept will appear (somewhere) as a descendant of the collection. Concept C's membership of a collection prevents its appearance at the top level in the case that concept C is not also involved in the broader/narrower hierarchy, as explained in the previous point.)
- There are a couple of "big ideas" or guiding principles:
- Under what circumstances should a concept scheme CS appear at the top level of the visualization?
- The concept scheme CS appears at the top level of the visualization if and only if
includeConceptSchemes
is true.
- The concept scheme CS appears at the top level of the visualization if and only if
- Under what circumstances should a collection CO appear at the top level of the visualization?
- The collection CO appears at the top level of the visualization if and only if
includeCollections
is true, and CO is not itself marked as belonging to any collection.
- The collection CO appears at the top level of the visualization if and only if
- If
includeConceptSchemes
is true, under what circumstances should a concept C appear as a direct descendant of a concept scheme CS?- The "big ideas" for this are:
- The concepts that appear as descendants of CS are precisely those concepts that are marked as belonging to CS.
- Only broader/narrower relations between pairs of concepts that are both in CS are considered when determining the direct descendants. See the section "The graph of resources and relations" for the description of the edge-colouring of the graph of broader/narrower relations.
- For every concept C:
- If concept C is not marked as belonging to CS, then C will not appear as a direct descendant of CS.
- If concept C is marked as a top concept of CS, then C will appear as a direct descendant of CS. (Reminder: in this case, there can not be a concept B marked as belonging to CS which is also marked as broader than C; see the section "Exclusions" above.)
- If concept C is marked as belonging to CS, but not marked as a top concept of CS, then a situation similar to the "classic", default case above applies: the concept C will appear as a direct descendant of CS if and only if there does not exist any other concept marked as belonging to CS and which is marked as broader than C.
- The "big ideas" for this are:
- If
includeCollections
is true, under what circumstances should a resource C appear as a direct descendant of a collection CO?- The resources that appear as direct descendants of CO are precisely those resources that are marked as directly belonging to CO.
- If
includeConceptSchemes
is true, under what circumstances should a concept C appear as a descendant of a concept scheme CS?- The concept C will appear as a descendant of CS if and only if it is marked as belonging to CS.
- If
includeCollections
is true, under what circumstances should a resource R appear as a descendant of a collection CO?- The resource R will appear as a descendant of CO if and only if it is marked as belonging to CO.
...