skos narrower not added for a new concept in the tree

[Henk Laloli]

Hello,

When I add a narrower concept B to A 

B skos:broader A is assigned, 

but A skos:narrower B, is not automatically assigned. Why not? (using the GUI tree). I never worried about this while using VocBench alone, but when I am going to use it with others, with no knowledge of SKOS, this will be a real show stopper. 

This is with a vocabulary in SKOS model and lexicalization. I am using VocBench 11.2.0. 

Henk

[Armando Stellato]

Dear Henk,

 

For inverse property computation, and specific for your case, there are two things that can be done:

 

• In general, you can use a reasoner. Inverse property expansion is quite the minimum you can expect from an OWL reasoner of any type.
  Check here: http://vocbench.uniroma2.it/doc/user/projects.jsf#repository_configuration
  and here for GDB reasoning settings: http://graphdb.ontotext.com/documentation/standard/configuring-a-repository.html
  while RDF4J should not have an OWL reasoner, only RDFS one
• If you like to see any inverse triple (i.e. any tripe materialized after any property which either is symmetric or has an inverse which has been asserted) as explicit, then you can use VB3’s trivial inference:
  check here: http://vocbench.uniroma2.it/doc/user/projects.jsf#project_creation

 

Furthermore, pls consider that VocBench takes into account skos:broader by reading it in both verses. Indeed, even though it doesn’t write skos:narrower, it reads that as well, so here are what it does:

• Reading: both skos:broader and skos:narrower and in both directions (e.g can use skos:broader to read children of a concept and skos:narrower to read parents)
• Deleting: deletes both skos:broader and skos:narrower (this is merely in case there are from the imported data)
• Adding: it writes only skos:broader

In general, I’m not a big fan of the redundancy introduced by skos:broader and skos:narrower: I believe these two props were added to the SKOS specs because these were, at the time, too much bent to satisfy the demand of what thesaurists were literally used to see and should have been avoided instead.
I consider their combined existence merely a possibility for publication (so, besides the other options discussed above, skos:broader can be materialized later, on export).

There are cases in which skos:narrower would cause problems, think about the CBD for a concept having 2000 children…

Anyway, the options for immediate materialization (in the inference graph or asserted) are there and the support for easily materializing them on export are there as well, so you can keep the show going on ;-)

..and possibly I will surrender in the near future and allow for an even more specific option (i.e. without support for trivial inference or a full reasoner) to assert the inverse of the broader property being selected (VB allows seamlessly for the adoption of any subproperty of skos:broader, so this needs to be done on a more general scale )

 

Kind Regards,

 

Armando

 

 

--
You received this message because you are subscribed to the Google Groups "vocbench-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vocbench-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vocbench-user/0a41def5-033f-4e45-819b-7c060fa4822dn%40googlegroups.com.

[cbs bibliotheek]

Dear Armando,

thanks very much for the explanation. That relieves my worries. I think I can manage it with these solutions. 

Especially in presentation tools both skos properties broader and narrower are demanded. 

Kind regards,

Henk