4. "NZGLS from an implementer's point of view"

Considering the issues that EGU have had in using NZGLS raises the question - has the Portal team been too literal in their interpretation of the Standard?

Metalogue is now in its 4th version (3 versions launched to users) giving a history of managing metadata to work for the Portal. EGU have developed their own data model and now treat NZGLS as an export strategy.

In the EGU data model there are three types of data : free text, CVL values, and relationships.

Relationships are with other records. Creator, Availability and Mandate are treated as relationships. So a service record has a 'created by' relationship with an agency. Availability is represented by a relationship - EGU have created a new record type "Agency Unit" - to help normalize the data.

Mandate does not use a CVL as the Portal team wanted to use URI, and as a design criteria avoid complex encoding schemes.

No record is referenced by name - references are by URN. This allows record names to be changed.

The Portal team may introduce other record types and relationship types. For example: "Minister".

Export from Metalogue is done as NZGLS metadata in XML, but concerned that there is no DTD (Document Type Definition), and therefore the XML cannot be readily validated, and there is a mix of encoding schemes.

Possible conflict with other sources of NZGLS metadata - which version is current?

Portlets will not be able to link to legislation.

Portal is likely to emphasise Portlets as the teams which support them have better subject understanding than the central Portal team can have.

John interpreted the DC view of the organization of metadata and related it to the view developed by the Portal team. John noted that the DC approach to metadata is to have simple records which list attributes for each resource. (This is essentially a 'flat file' database approach). However, the values of DC elements are themselves resources, and linking resources in this way (a relational database approach) is just a different way of modeling the same aspects of the real world.

Portal metadata still can be presented as NZGLS metadata indicating the abstract model of each is congruent.

John asked whether the NZGLS Working Group needs to review the obligations on elements for the different types - are they appropriate in each case? NZGLS was developed with three types of resource (Agency, Service, Document) in mind. If additional resource types are identified (e.g. legislation) the obligations and application of the elements may need to be modified for these new resource types.

Kaylene posed the question of how much of the structure of Government could the Portal usefully represent? For example - Ministers relationships with Agencies?

Derek suggested that Ministers should be described something like institutions - not as individual people who might hold the portfolio at any one time. So it could be another type of Agency record or a separate category.

John suggested that there might be needs for more types of resource. He noted that more complexity adds more power to the metadata model. The simplest approach is to have values as free text, but this can give rise to inconsistency and is difficult to maintain. Use of a CVL addresses these issues, but representing the value as a related resource provides the highest level of benefit. For example, a Minister could be free text, selected from a pick list, or from a list of related metadata records which describe Ministers.

Kaylene commented that the Portal may add more relationships. With any aspect the question is it an attribute, or is it a relationship needs to be considered. Often the aspect in question can be shown both ways, so the question is which is the better approach?

Derek asked if legislation is described. Kaylene answered that so far just links are provided (via 'dummy' records that do not include Descriptions, so are not valid NZGLS metadata).

[Douglas Campbell arrived]

Kaylene noted that the metadata is strong on functional context / relationship information, and especially for services this information cannot be found using other search tools.

Derek suggested that legislation should be described using metadata, then other records can just reference that metadata record. Kaylene thought this would mean using Metalogue to manage the legislation documents.

Kaylene summarized the Portal's XML problems for Douglas's information - primarily the lack of DTDs means the XML is fragile.

Douglas commented that the XML and RDF/XML advice from DC are very similar, but that RDF has a steep learning curve as it requires a different way of thinking about knowledge. Douglas advised to focus on creating the XML schema as that is reasonably stable.

Keitha asked about importing. Kaylene advised that importing metadata into Metalogue is not currently planned for. The Portal Team wish to limit the number of records to the most useful only.

John asked what new types of resource are being currently in place or under consideration? Kaylene noted legislation, and Ministers /MPs (Kaylene had found at least 3 lists of Ministers/MPs on the web, each presumably separately maintained. Criteria for assessing the need for a new type are:

• public expectations of the portal
• can they be used to show relationships?
• Ministers/MPs could be described as roles held by a person, the natural persons who have those roles would not be described.
• How to describe the transition of Bills to Acts is an issue.

John asked Douglas for lessons learned on XML imports as a result of experience with Matapihi. Matapihi provides a search spanning databases of digital collections from different agencies. Examples of:

• different uses / interpretations of metadata between libraries /other institutions e.g. how to describe a fossil - no Title or Creator.
• users interpretations - a house built in the 1960s in a 1930's style is seen by architects as having a 1930s creation date (i.e. the date of the creation of the style).
• data quality / consistency problems - different date formats, different degrees of specificity i.e. 1984 vs. 1980's.

Do relationships become entities that need to be modeled/ described, or is a CVL of relationships enough?

Action: Kaylene to discuss XML schema with Douglas.