Dear Hans,
the general assumption is that if it is proper SKOS content, it will be properly shown in VocBench. If you are not seeing it properly in VB3 and it comes from another SKOS editing tool, there are two possibilities:
I would suggest to quickly review our page on SKOS [1], as it could clarify on the interpretation of data that is ingested and shown in VocBench.
If you need any help, I would suggest to:
A common cause (in general, with no reference to the specific tool you were using) of issues in viewing thesaurus data is a misuse of the concept schemes. See this [2]. The skos:inScheme triple needs to be asserted for each concept present in the thesaurus and *should not* be inferred from the top concepts. If wrong inference is assumed in the source data, then you might experience that apparent loss of data in VB3. Restoring the missing skos:inScheme triples would do the job. One experiment you can do is to go to the concept scheme tab and deselect all schemes then go back to the concept tree view. If you are seeing all concepts and arranged in a tree as you would expect, you might have incurred in this issue in the data.
Kind Regards,
Armando
[1] http://vocbench.uniroma2.it/doc/skos.jsf
[2] https://www.w3.org/TR/skos-reference/#L2577
--
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/cb85cf48-5a77-475d-8474-9793b5158c58n%40googlegroups.com.
A common cause (in general, with no reference to the specific tool you were using) of issues in viewing thesaurus data is a misuse of the concept schemes. See this [2]. The skos:inScheme triple needs to be asserted for each concept present in the thesaurus and *should not* be inferred from the top concepts. If wrong inference is assumed in the source data, then you might experience that apparent loss of data in VB3. Restoring the missing skos:inScheme triples would do the job. One experiment you can do is to go to the concept scheme tab and deselect all schemes then go back to the concept tree view. If you are seeing all concepts and arranged in a tree as you would expect, you might have incurred in this issue in the data.
Armando
Dear Richard,
thanks so much about the detailed and complete information your provided! This would really help any person here with the same needs.
I wasn’t so precise in my reply as I’m not updated in every detail on the evolutions of all other tools, so I just made an hypotheses, based also on my memories.
Quick answer (not so quick, what is lacking is that I could not test it) on your question as I’m literally throwing myself into a day of lectures…
I can’t recall 100%, as VB will write both skos:inScheme and skos:topConcept for top concepts of a certain scheme, but our general policy in dealing with the services is that some trivial reasoning is embedded in the queries we make to implement them. So, as skos:topConceptOf implies skos:inScheme, we would robustly show any concept that is only represented through skos:topConceptOf as part of the scheme (in this case, it’s even easier, because this is limited to not filter the concept before it is lacking skos:inScheme, which amounts to simply use only the skos:topConceptOf property when retrieving top concepts). Of this I’m pretty sure. I can’t assure instead that the concept will be shown in the middle of a hierarchy in case it is present both as a top concept and in the middle…for the same scheme (a rare case which most people would like to avoid as a modeling policy, but still allowed by SKOS in principle). Pls notice that only this case would be meaningful for your question. If instead we are considering a concept which is top of scheme A and in the middle of scheme B, then yes, they are two different cases and it needs to be made explicit that it is skos:inScheme B even if it is skos:topConceptOf A.
As a general rule of thumb for users as well: VB3 is meant to be robust, it is very strict in what it writes but quite flexible (providing that the semantics are respected) in what it accepts (Postel said something about it..), so if there are cases that would be implied by some trivial reasoning and are not covered by VB3’s services (I mean, without using a reasoner), then we gladly welcome feedback and we will make it even more robust :-)
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/58ebadec-b912-4d45-9397-f22776a1535an%40googlegroups.com.