Typically, a project will use a single file using the same format as a manifest file that defines alternative configurations that can be loaded. This file is loaded at program startup using rdf_attach_library/1. Users can now list the available libraries using rdf_list_library/0 and rdf_list_library/1:
1 ?- rdf_list_library. ec-core-vocabularies E-Culture core vocabularies ec-all-vocabularies All E-Culture vocabularies ec-hacks Specific hacks ec-mappings E-Culture ontology mappings ec-core-collections E-Culture core collections ec-all-collections E-Culture all collections ec-medium E-Culture medium sized data (artchive+aria) ec-all E-Culture all data
Now we can list a specific category using rdf_list_library/1.
Note this loads two additional manifests referenced by resources
ec-mappings. If a resource does not exist is is flagged
2 ?- rdf_list_library('ec-mappings'). % Loaded RDF manifest /home/jan/src/eculture/vocabularies/mappings/Manifest.ttl % Loaded RDF manifest /home/jan/src/eculture/collections/aul/Manifest.ttl <file:///home/jan/src/eculture/src/server/ec-mappings> . <file:///home/jan/src/eculture/vocabularies/mappings/mappings> . . <file:///home/jan/src/eculture/vocabularies/mappings/interface> . . . file:///home/jan/src/eculture/vocabularies/mappings/interface_class_mapping.ttl . . . file:///home/jan/src/eculture/vocabularies/mappings/interface_property_mapping.ttl . . <file:///home/jan/src/eculture/vocabularies/mappings/properties> . . . file:///home/jan/src/eculture/vocabularies/mappings/ethnographic_property_mapping.ttl . . . file:///home/jan/src/eculture/vocabularies/mappings/eculture_properties.ttl . . . file:///home/jan/src/eculture/vocabularies/mappings/eculture_property_semantics.ttl . . <file:///home/jan/src/eculture/vocabularies/mappings/situations> . . . file:///home/jan/src/eculture/vocabularies/mappings/eculture_situations.ttl . <file:///home/jan/src/eculture/collections/aul/aul> . . file:///home/jan/src/eculture/collections/aul/aul.rdfs . . file:///home/jan/src/eculture/collections/aul/aul.rdf . . file:///home/jan/src/eculture/collections/aul/aul9styles.rdf . . file:///home/jan/src/eculture/collections/aul/extractedperiods.rdf . . file:///home/jan/src/eculture/collections/aul/manual-periods.rdf
Resources and manifests are located either on the local filesystem or
on a network resource. The initial manifest can also be loaded from a
file or a URL. This defines the initial base URL of the
document. The base URL can be overruled using the Turtle @base
directive. Other documents can be referenced relative to this base URL
by exploiting Turtle's URI expansion rules. Turtle resources can be
specified in three ways, as absolute URLs (e.g.
as relative URL to the base (e.g.
or following a
prefix (e.g. prefix:ontology).
The prefix notation is powerful as we can define multiple of them and
define resources relative to them. Unfortunately, prefixes can only be
defined as absolute URLs or URLs relative to the base URL. Notably, they
cannot be defined relative to other prefixes. In addition, a prefix can
only be followed by a Qname, which excludes
Easily relocatable manifests must define all resources relative to the base URL. Relocation is automatic if the manifest remains in the same hierarchy as the resources it references. If the manifest is copied elsewhere (i.e. for creating a local version) it can use @base to refer to the resource hierarchy. We can point to directories holding manifest files using @prefix declarations. There, we can reference Virtual resources using prefix:name. Here is an example, were we first give some line from the initial manifest followed by the definition of the virtual RDFS resource.
@base <http://gollem.science.uva.nl/e-culture/rdf/> . @prefix base: <base_ontologies/> . <ec-core-vocabularies> a lib:Ontology ; a lib:Virtual ; dc:title "E-Culture core vocabularies" ; owl:imports base:rdfs , base:owl , base:dc , base:vra , ...
<rdfs> a lib:Schema ; a lib:Virtual ; rdfs:comment "RDF Schema" ; lib:source rdfs: ; lib:schema <rdfs.rdfs> .