...

• 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.
• 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's skos:memberList. An ordered collection must specify its members using the skos:memberList property. It may also specify those values using skos:member, since SKOS S36 says: "For any resource, every item in the list given as the value of the skos:memberList property is also a value of the skos: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 triples my:C1 a skos:Concept and my:C2 a skos:Concept are inferred.)

...

• 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 and includeCollections browse flags.
  • If includeConceptSchemes is false, and includeCollections 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., because includeConceptSchemes is false.)
  • If includeConceptSchemes is true, and includeCollections 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, and includeCollections 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.
    • (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.)
  • If includeConceptSchemes is true, and includeCollections 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.)
• 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.
• 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.
• 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.
• 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.

...