Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


PoolParty's convenient user interface hides much of the complexity of representing a vocabulary in RDF. However, you or your users need to know about this representation if you wish to use SPARQL to run queries.

The main thing to know is that PoolParty This page explains the cross-cutting concerns, and shows how PoolParty makes use of specific well-known RDF vocabularies.


During project creation, you specify one or more project languages, of which one must be designated as the "default language". The PoolParty user interface does not allow you to change the default language of a project once it has been created. However, you may subsequently add or remove other languages.

Almost all textual data you add to a project is added as an RDF "language-tagged string", i.e., as a string with an associated language code (RDF type ). See for further information about language-tagged strings. You can see this in practice by viewing a concept and then selecting the "Triples" tab. For example, every preferred label is shown with a language tag.

Some concept properties are added without a language tag. For example, if you add a SKOS notation, the value is added as an RDF "simple literal" (RDF type xsd:string). Conversely, the PoolParty user interface does not support adding language-specific SKOS notations for a concept.

Use of well-known RDF vocabularies

PoolParty creates and manages (user-defined) vocabularies using classes and properties drawn from a number of well-known RDF vocabularies; in particular:


SKOS is used as the overarching structure of vocabularies in PoolParty. The PoolParty user interface presents vocabularies as consisting of "concept schemes" which contain "concepts"; these are represented directly as skos:ConceptSchemes and skos:Concepts.

Please note the information given in the "Languages" section above. For example: preferred labels (and other types of labels) are stored as language-tagged strings; notations are stored as simple literals.




The RDF triples contained within each project constitute an RDF Dataset, and that dataset is stored in an individual repository within a triple store. The triple store of ANDSARDC's PoolParty server is an instance of OpenRDF Sesame.


You typically don't have to pay attention to named graphs; RVA takes care of the details for you when necessary. How this applies during importing a vocabulary is explained in the next section. If you use the ANDS ARDC Vocabulary Editor Admin Tool, the predefined queries and updates are automatically adjusted to use the correct named graphs before they are sent to the PoolParty server.


RVA provides convenient support for importing and publishing a vocabulary you have created in the ANDS ARDC PoolParty server. The process for doing this is described at the page Publishing a PoolParty vocabulary to the RVA portal. It is important to note that in order to import any vocabulary data into RVA, you must specify the creation of a version (using the "Add a version" button) as follows:

  • The version's status must may be either "current" or "superseded".
  • The version must have access points generated from PoolParty. (On : on the "Add a new version" dialog, click "Import Version from the toggle to select "Harvest version from from PoolParty".)

The following sections describes how the RDF data stored in PoolParty is transformed into the RDF data presented through RVA.


The first step in the process is to fetch the vocabulary from data; within RVA, this is known as "harvesting". RVA uses PoolParty's own API to export the vocabulary data; it fetches both current and deleted/deprecated concepts.

There are were major changes in the representation of vocabulary data in PoolParty Release 5.5. The harvest process has been was modified so as to preserve the "end result" achieved with earlier releases. In particular, Release Releases from 5.5 makes onwards make extensive use of named graphs. Therefore, the harvester invokes the PoolParty export API in such a way that the assignment of triples to named graphs is discarded: the triples are exported in a format that represents triples as belonging only to the default graph.

Another change in Release 5.5 is was to the representation of creator and contributor data represented using DC Terms. In earlier releases, the objects of triples with property dcterms:creator and dcterms:publisher were string literals; they are now resources. During harvest, those resources are transformed so as to have a triple of type foaf:name with object that is the (string) value you typed in.