I am also wondering what percentage of SKOS users actually doesn't use
skos:ConceptSchemes, and instead just defines "root" concepts to be
those that have no broader concept.
In either case, one reason why the taxonomy tree in our current
implementation only supports explicit schemes as roots is performance:
it is much faster to find the (few) instances of skos:ConceptScheme than
iterating over all skos:Concepts and filtering out those that don't have
a value for skos:broader. Querying for the absence of a triple at a set
of instances is quite hard (which is also a problem in the class tree,
where some ontologies don't have explicit rdfs:subClassOf links to a
root and thus classes cannot be reached).
Holger
On 18/02/2019 12:41 pm, Irene Polikoff wrote:
There is a constraint check that looks for all concepts that are
neither top concept in a scheme nor have any broader parents. This
implements a common requirement for taxonomies and has been requested
by users.
SKOS could be used in a different ways e.g., one could use it for
datasets that are not taxonomies, but collections and collection
members. However, the UI needs to make some assumptions one way or
there other. If it is optimized for one way of using SKOS and will not
be be optimized for other ways of using SKOS. If you are wanting to
manage such flat lists, you are probably better of to do so as a
reference dataset or as an enumeration as opposed to a SKOS taxonomy.
On Feb 17, 2019, at 8:29 PM, [email protected]
<mailto:[email protected]> wrote:
While you are looking at overriding here - I have collections of
terms that that don't logically have broader concepts - lets say I
have 500 such "code lists" I want to manage as a single reference
collection, then create property value selectors as needed.
If i model them as skos:Collections I see no way to navigate in the
Taxonomy or Ontology editors. So Creating an override of the class
selector for a specific collection would be cool - I'd be happy to
create a graph with the relevant selectors - if I could see a way to
bind it to the given collection.
On Saturday, February 16, 2019 at 5:04:47 AM UTC+11, Adam Kimball wrote:
Hi,
I have two taxonomy projects:
Taxonomy_1 = http://my.example/tax/people#
Taxonomy_2 = http://my.example/tax/locations#
<http://my.example/tax/locations#>
Note: Taxonomy_1 contains links to Taxonomy_2 with predicates
like ex:lives_in
When a user in EDG goes to Taxonomy_2, they see their curated
location terms underneath the one scheme.
When a user in EDG goes to Taxonomy_2, they see the locations
scheme (imported) and the people scheme (primary).
What I'd like is to somehow keep Taxonomy_1 from showing up at
all, though any IRIs should still be available to navigate. I
just want the scheme to be hidden.
One way is to factor out the schemes and import them separately
but that strikes me as a lot of maintenance.
Suggestions for me?
Thanks,
Adam
--
You received this message because you are subscribed to the Google
Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "TopBraid
Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
