gavo.registry.builders module

Functions returning xmlstan for various OAI/VOR documents.

This comprises basic VOResource elements; capabilities and interfaces (i.e. everything to do with renderers) are in registry.capabilities.

All this only becomes difficult when actually generating VOResource metadata (OAI is plain). For every type of VO resource (CatalogService, Registry, etc), there’s a XYResourceMaker, all inheriting ResourceMaker.

The decision what VOResource type a given service has is passed using common.getResType; this means the resType meta is tried first, using resob.resType as a fallback.

class gavo.registry.builders.AuthResourceMaker

Bases: ResourceMaker

resType = 'authority'

resourceClass

alias of Authority

class gavo.registry.builders.CatalogServiceResourceMaker

Bases: DataServiceResourceMaker

resType = 'catalogService'

resourceClass

alias of CatalogService

class gavo.registry.builders.DataCollectionResourceMaker

Bases: ResourceMaker

A base class for Table- and DataResourceMaker.

resourceClass

alias of CatalogResource

class gavo.registry.builders.DataResourceMaker

Bases: DataCollectionResourceMaker

A ResourceMaker for rscdef.DataDescriptor items (yielding reformed DataCollections)

resType = 'data'

class gavo.registry.builders.DataServiceResourceMaker

Bases: ServiceResourceMaker

A ResourceMaker for DataServices.

These are services that may have instrument, facility, and coverage metas but have no associated tables. This is not generated by the service classifier currently since we always have a table. You can force generation of such records via setMeta(“resType”, “dataService”).

resType = 'dataService'

resourceClass

alias of DataService

class gavo.registry.builders.DeletedResourceMaker

Bases: ResourceMaker

resType = 'deleted'

class gavo.registry.builders.DocResourceMaker

Bases: CatalogServiceResourceMaker

resType = 'document'

resourceClass

alias of Document

class gavo.registry.builders.OrgResourceMaker

Bases: ResourceMaker

resType = 'organization'

resourceClass

alias of Organisation

class gavo.registry.builders.RegistryResourceMaker

Bases: ServiceResourceMaker

resType = 'registry'

resourceClass

alias of Resource

class gavo.registry.builders.ResourceMaker

Bases: object

A base class for the generation of VOResource elements.

These have a resType attribute specifying which resource type they work for. These types are computed by the getResourceType helper function.

The makeResource function below tries the ResourceMakers in turn for the “best” one that matches.

If you create new ResourceMakers, you will have to enter them in the correct sequence in the _resourceMakers list below.

ResourceMaker instances are called with a resob argument and a set of set names. You will want to override the _makeResource(resob) -> xmlstan method and probably the resourceClass element.

resType = None

resourceClass

alias of Resource

class gavo.registry.builders.ServiceResourceMaker

Bases: ResourceMaker

A ResourceMaker adding rights and capabilities.

resType = 'nonTabularService'

resourceClass

alias of DataService

class gavo.registry.builders.StandardsResourceMaker

Bases: ResourceMaker

resType = 'standard'

resourceClass

alias of Standard

class gavo.registry.builders.TableResourceMaker

Bases: DataCollectionResourceMaker

A ResourceMaker for rscdef.TableDef items (yielding reformed DataCollections)

resType = 'table'

gavo.registry.builders.getDCGetRecordElement(resob)

gavo.registry.builders.getDCListRecordsElement(resobs, setNames, makeRecord=<function getDCResourceElement>)

returns stanxml for ListRecords in dublin core format.

resobs is a sequence of res objects. makeRecord(resob, setNames) -> stanxml is a function that returns an OAI.record element. For ivo_vor metadata prefixes, this is overridden. by getVOListRecordsElement.

gavo.registry.builders.getDCMetadataElement(resob, setNames)

gavo.registry.builders.getDCResourceElement(resob, setNames={'ivo_managed'})

gavo.registry.builders.getIdentifyElement(registryService)

returns OAI Identify stanxml.

registryService is the registry we’re identifying, i.e. typically __system__/services#registry

gavo.registry.builders.getListIdentifiersElement(restups)

returns an OAI ListIdentifiers element for the rec tuples recs.

gavo.registry.builders.getListMetadataFormatsElement()

gavo.registry.builders.getListSetsElement()

gavo.registry.builders.getOAIHeaderElementForRestup(restup)

gavo.registry.builders.getResourceArgs(resob)

returns the mandatory attributes for constructing a Resource record for service in a dictionary.

gavo.registry.builders.getResourceElement(resob, setNames, metadataMaker)

helps get[VO|DC]ResourceElement.

gavo.registry.builders.getVOGetRecordElement(resob)

gavo.registry.builders.getVOListRecordsElement(resobs, setNames)

gavo.registry.builders.getVORMetadataElement(resob, setNames={'ivo_managed'})

gavo.registry.builders.getVOResourceElement(resob, setNames={'ivo_managed'})

returns a stanxml for Resource in VOR format.

There’s trouble here in that we have set management on the level of renderers (capabilities). Thus, to come up with capabilities for a given ivorn, we have to know what set is queried. However, OAI GetRecord doesn’t specify sets. So, we provide a default set of ivo_managed, assuming that the registry is only interested in records actually VO-registred. This may fly into our face, but I can’t see a way around it given the way our services are described.