Handling of "type" links

[hvdsomp]

Over the past months, concerns arose regarding the handling of "type" links:

• At the level of Content Resources, "type" links are not following the same pattern as links with other relation types. e.g. cite-as, describedby, license. For these latter links, the pattern is that they are only provided for a Content Resource if they provide information that is different from what is provided for the scholarly object as a whole at the Landing Page. For example, if a Content Resource has its own PID, different than the PID of the scholarly object as a whole, a "cite-as" link is provided for the Content Resource pointing at its own distinct PID. If the Content Resource has no own PID, no "cite-as" link is provided. For "type" links, the specification had no provision for providing a type for the scholarly object as a whole and required (1) providing the specific type of each Content Resource by means of a "type" link for the Content Resource and (2) Providing schema.org's AboutPage type for the Landing Page.
• Two ongoing implementations revealed that the platforms involved (B2Share, Dataverse) do not have provisions for type information at the level of Content Resources. The assumption is that this holds true for a variety of platforms. The two platforms actually do not have type information for the scholarly object as a whole either. This may hold true for some other platforms too. The platforms doing the implementations were able to set system-wide type defaults though (i.e. schema.org's Dataset). Other platforms (lacking type information) with uniform collections could do the same (e.g schema.org's Dataset or ScholarlyArticle or SoftwareSourceCode) whereas heterogeneous collections could use schema.org's catchall CreativeWork as default or an appropriate term from another vocabulary.

These observations led to revised thinking regarding the use of "type" links, which resulted from discussions with the implementers that were involved:

• At the Landing Page, provide two "type" links: (1) one with AboutPage to convey that - from a web perspective - a Landing Page is concerned (2) another to convey the type of the scholarly object as a whole (e.g. Dataset or ScholarlyArticle or SoftwareSourceCode ...).
• At the Content Resources only provide a "type" link when its type is different than that of the scholarly object as a whole; this assumes, of course, that type information for Content Resources is known by the platform.

These changes are reflected in a new version of the specification. It is understood that making such changes prior to broader discussion is not best practice, but it kind of just happened organically and:

• The new proposed approach did result from discussions with active implementers
• Assessing the actual impact of such conceptual changes is hard without concretely writing them out in the form of a specification
• Implementers were involved in reviewing the revised specification
• The version of the specification prior to the proposed changes is available and reverting back to it is possible, if needed

Feedback to the proposed change and the new version of the specification is very welcome.

[hvdsomp]

approach seems to be accepted. closing.