View unanswered posts | View active topics It is currently Wed Aug 15, 2018 9:54 am

All times are UTC + 10 hours [ DST ]




Reply to topic  [ 1 post ] 
Select multiple collection types for a 'collection 
Author Message
ANDS Staff
User avatar

Joined: Thu Feb 10, 2011 11:18 am
Posts: 76
Suggested schema change
Multiple collection types should be able to be recorded for a collection. (Similar issue for services is canvassed in Multiple service types).

Problem this suggestion addresses
Only one collection type (currently "collection", "dataset", "registry", "repository", and "catalogueOrIndex" are suggested) can be recorded. This is a problem because these are not mutually exclusive categories, therefore more than one valid choice could be made, resulting in inconsistent metadata. A given collection may potentially be described using all of these types.
The core types ("collection" and "dataset") are sufficient for distinguishing structured data from other data. The other types are descriptive of the functions of different kinds of aggregations and can be regarded more as descriptive keywords, of value primarily for discovery and search.
One or more collection types should be permitted.
Also for discussion: what collection types need to be specified? who would use this information for what purpose?

Identified by
ANDS Staff (Sally Goodenough)

RIF-CS schema components affected
Collection types

Impact on content providers
No impact; the change would allow but not require multiple types to be provided.

Pros
Over time this will result in more meaningful metadata to support searching.

Cons
None identified

Technical options

Option A:
a new field is added to <collection>, “secondaryType”, of cardinality 0..*, and with values drawn from the Service Type Vocabulary.
    <xsd:element name="secondaryType" minOccurs="0" maxOccurs="unbounded" type="secondaryTypeType">
      <xsd:annotation>
        <xsd:documentation xml:lang="en">
        Type(s) relevant to the collection.
        </xsd:documentation
      >
      </xsd:annotation>
    </xsd:element>
    <xsd:complexType name="secondaryTypeType">
      <xsd:simpleContent>
        <xsd:extension base="xsd:string">
          <xsd:annotation>
            <xsd:documentation>A value taken from a controlled vocabulary indicating the secondary type of the collection.</xsd:documentation>
          </xsd:annotation>
        </xsd:extension>
      </xsd:simpleContent>

    </xsd:complexType>
Business rules would need to be defined to determine how multiple types would be used in faceted display groupings relating to collection type resulting from a search in RDA.
Changes would be required to “Register My Data” to allow multiple selects from the “Type” drop-down list.
Pros: No changes to existing feeds and no legacy issues
Cons: Implies a hierarchy of typing that may not suit all providers
Issues with displaying faceted search results in RDA based on subtyping

Option B: collection records are still constrained to have only one type; a separate collection record is contributed for each collection type of the record. The different collection records are identified as referring to the same collection instance through a shared identifier or location.
Pros: No change to existing schema or feeds.
Cons: Difficulty in displaying these collections accurately in RDA based on the facet of type

Option C:Enable multiple types to be defined for a collection by allowing space delimited values to be passed as a single string to the type attribute. This solution requires no changes to the rif-cs schema definition as the type attribute is of type string.
Changes would be required to “Register My Data” to allow multiple selects from the “Type” drop-down list.
Business rules would need to be defined to determine how multiple types would be used in faceted display groupings relating to collection type resulting from a search in RDA.
Pros:
This option has no legacy data problems or migration and transition arrangements to consider.
Cons:
Some systems will strongly prefer to maintain a primary service type. (In VITRO, for example, the plan is to assign each service type to a subclass of Service.)
More difficult to treat service type as a controlled vocabulary: validation will involve tokenising the type string."


Tue Jun 28, 2011 12:37 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 1 post ] 

All times are UTC + 10 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software for PTF.