Suggested schema change
A service may have multiple types.Option A
a new field is added to <service>, “secondary type”, of cardinality 0..*, and with values drawn from the Service Type Vocabulary.Option B
service records are still constrained to have only one type; a separate service record is contributed for each service type of the record. The different service records are identified as referring to the same service instance through a shared identifier or location.Option C
allow multiple space delimited type values to be assigned to the type attribute of a service record.Problem this suggestion addresses
RIF-CS entities only have a single type, which is realised as an attribute on elements Collection, Service, Party, Activity. This works because in most instances, types are mutually exclusive. However software described as a service typically has multiple functionalities, as described in http://ands.org.au/guides/cpguide/cpgservice.html
. So while a web service may provide only harvest or only search functionality, software may offer both analysis (transform) and visualisation (report) functionality. The range of functionality of software cannot currently be described through the service type attribute, and the recommendation in place is: “the service description of software tools shall have a single type, reflecting the primary use of the tool in the research community.” The choice of primary functionality can be arbitrary.
Allowing multiple types in service will lead to more accurate discovery of services by type.
Note that this change only impacts services (which are uncommon: 58 in Sandbox), and within services it only impacts software services (which are even less common: by my count, 6 of the 58).
RIF-CS schema components affected
Attribute “type” of element “service”Impact on content providers
Impact depends on implementation. Option A will require no change to existing feeds: users have the option of picking secondary types that also apply to their software. Option B also requires no change, but it will require content providers to identify their multiple service descriptions as referring to the same service.
Allows multiple types to be specified.
Does not disrupt existing implementation or feeds: existing records will continue to work as is, added types are optional. Option A
a single service instance is only identified with a single record: no added mechanisms for deduplication are needed.Option B:
the current entry processes for RIF-CS and the RIF-CS schema are unchanged.Option C:
the current rif-cs schema definition is unchanged: a single service instance is only identified with a single record
no added mechanisms for deduplication are needed.
No distinction between primary and secondary service types.ConsOption A
search for types will need to look in two places to discover service type.
preserves possibly artificial distinction between primary and secondary service types. (Minor impact, affects only a few software records)Option B:
there will need to be deduplication/co-location infrastructure in RDA, to establish that the multiple records refer to the same thing. This also applies to any objects related to those service records.
there is no established mechanism for identifying two record as referring to the same service; by analogy with activities and parties, they would need to share an authoritative identifier. (In the case of services, a common URL may be enough.)
no precedent for the same partner giving two descriptions of the selfsame entity.Option C
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."Technical options
Have moved tech options up into main body, since they have different impacts.
The following options are to be rejected, as too disruptive to existing use of service objects:
• The type attribute of <service> is ignored but not removed. Types are read from a new field, “type”, of cardinality 0..*, and with values drawn from the Service Type Vocabulary.
• The type attribute of <service> is removed. Types are read from a new field, “type”, of cardinality 0..*, and with values drawn from the Service Type Vocabulary.