Page tree

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Contents

PoolParty is an editor for SKOS vocabularies; it is not an editor for generic RDF. That means:

  • Vocabularies created using the PoolParty editor use SKOS in a particular way.
  • If you have existing RDF and wish to import it into a PoolParty project, that RDF must satisfy certain prerequisites.

The SWC web site has some background information on how PoolParty uses SKOS:

https://grips.semantic-web.at/display/public/POOLDOKU/PoolParty%2C+SKOS%2C+RDF+and+URIs

More specifically, here are some details about what must be included in a SKOS file that is to be imported into PoolParty:

https://grips.semantic-web.at/display/public/POOLDOKU/Prerequisites+for+Importing+non-PoolParty+SKOS+Thesauri+or+Zthes+thesauri

ANDS staff have experience in working with RDF imported into PoolParty. Here are some practical observations based on this experience:

  • Use of the skos:hasTopConcept property is necessary and sufficient to link a concept into the hierarchy at the top level. That is, the skos:topConceptOf property plays no role in determining what PoolParty considers to be a top concept.
    • This has been tested by importing some RDF that defines a concept and specifies skos:topConceptOf the concept scheme. It did not appear in the hierarchy. Importing more RDF that specifies that the concept scheme skos:hasTopConcept the concept causes the concept to appear in the hierarchy.
    • PoolParty does not add the skos:hasTopConcept property for imported top concepts. If you wish an imported concept to have the skos:hasTopConcept property, this must also be included in the imported data.
    • PoolParty does not add the skos:topConceptOf property for imported top concepts. If you wish an imported concept to have the skos:topConceptOf property, this must also be included in the imported data.
    • A top concept created within the PoolParty user interface is linked to the concept scheme with both the skos:hasTopConcept and skos:topConceptOf properties.
  • Use of a chain of skos:narrower properties from a top concept down to a concept is necessary and sufficient to link such a non-top concept into the hierarchy. That is, the skos:broader property plays no role in determining what PoolParty considers to be a broader concept.
    • This has been tested by importing some RDF that defines a concept and specifies skos:broader to a top concept that is already visible in the user interface. The new concept did not appear in the hierarchy. Importing more RDF that specifies that the existing top concept has skos:narrower the new concept causes the new concept to appear in the hierarchy.
    • In another test, some RDF was imported that defines a concept and specifies skos:narrower from a top concept that is already visible in the user interface, but does not include the corresponding skos:broader property. The new concept did appear in the hierarchy.
    • PoolParty does not add the skos:narrower property for imported concepts that are otherwise linked to another concept using skos:broader. If you wish an imported concept to have the skos:narrower property, this must also be included in the imported data.
    • PoolParty does not add the skos:broader property for imported concepts that are otherwise linked to another concept using skos:narrower. If you wish an imported concept to have the skos:broader property, this must also be included in the imported data.
    • A non-top concept created within the PoolParty user interface is linked to its parent concept with both the skos:broader and skos:narrower properties.
  • No labels

This page has no comments.