PoolParty Import Errors

18 views
Skip to first unread message

Hans Aasman

unread,
Dec 5, 2022, 8:55:05 AM12/5/22
to vocbench-user
Hi all,
I was wondering if anyone had any experience importing taxonomies from PoolParty. I was attempting to import a taxonomy of about 5,000 concepts with ~5 different languages and it goes around 6 or 7 levels deep. In the 'concept tree' window of vocbench I have a flat list of concepts, however, they are not all of the concepts either. In the concept info screen, I can see that some concepts have 'broader concepts' defined, but often those concepts do not exist within vocbench.

Hans

Armando Stellato

unread,
Dec 5, 2022, 1:02:38 PM12/5/22
to Hans Aasman, vocbench-user

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:

  1. You have different settings for what you are seeing (e.g. in PoolParty you set it to watch concepts from concept scheme A, while in VB it is set to see concepts from concept scheme B)
  2. Something is managed in the data in the source tool using assumptions different from what the specs of SKOS say (or VB has a bug, but the tree view is so common and widely used, that if there were any bug, we surely would know about it).

 

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:

 

  1. Send a link to your data, if this is public and can be accessed by anybody
  2. Or send us some screenshots that show what you saw in VB, what you saw in PoolParty, and some exceprts of one or more concepts not appearing in VB.

 

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.

Richard Walker

unread,
Dec 7, 2022, 1:21:29 AM12/7/22
to vocbench-user
On Tuesday, December 6, 2022 at 5:02:38 AM UTC+11 stel...@uniroma2.it wrote:

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.

Well, it is relevant for PoolParty. And this turned out to be so important for us, that we already worked with SWC to have them support this a lot better in PoolParty. And it is a lot better ... but it's still not the default behaviour for a project. You need to implement a "standard operating procedure" when using PoolParty, to ask it to manage the skos:inScheme property correctly. Otherwise, the RDF you get is indeed not consistent with what you'd expect from the hierarchical display of concepts under the concept scheme nodes.


<quote>
By default, PoolParty doesn't add the skos:inScheme property to concepts. The consequence is that as one creates and populates a concept scheme using the user interface, only the top concepts are marked as belonging to the containing concept scheme (i.e., using the skos:topConceptOf and skos:hasTopConcept properties.). In order to make use of the functionality to display SKOS concept schemes as described here, it's necessary to configure each PoolParty project to add the skos:inScheme property to concepts. To do this, open the project in PoolParty, use the "Advanced" menu to select "In Scheme Settings" → "Enable In Scheme". Then, again in the "Advanced" menu, turn on "In Scheme Settings" → "Add In Scheme Relations to All Concepts", and also enable "Add In Scheme Relations On Concept Creation" and "Update In Scheme Relations On Concept Changes".
</quote>

... and you have to do this for every project.

Question for Armando: when you say "The skos:inScheme triple needs to be asserted for each concept present in the thesaurus ..." does this include the topConcepts?

Richard Walker
Australian Research Data Commons

Armando Stellato

unread,
Dec 7, 2022, 4:20:56 AM12/7/22
to Richard Walker, vocbench-user

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.

Reply all
Reply to author
Forward
0 new messages