Summary of Requirements and Demands
• Incorporation of any type of resource as defined in Section 2.1, with means for resource examination
• Realisation of a repository
• Realisation of a referatory
4.3 Resource Metadata
Several quality criteria and the question of what constitutes “good” metadata were already discussed in Section 2.5. To identify the requirements concerning the metadata to be used for digital resources in a Social Resource and Metadata Hub, the focus will now be put on the aspects most relevant for the presented approach approach:
• subjectivity and diversity,
• interpretability,
• core metadata and extensibility, and
• interoperability.
4.3.1 Subjectivity and Diversity
We have already shown that metadata about a resource can not capture the “true meaning of a document”, and that there are objective and subjective metadata.
We always have to consider that metadata is created for certain purposes in cer-tain contexts, and that it is impossible to anticipate for whom and for what rea-sons a resource might be considered as relevant in the future. We have to accept and to embrace the fact that there is no “single and correct” way to describe a resource. As a consequence we should allow subjectivity, and also diversity in the metadata about resources, instead of a metadata monoculture8. The need to sup-port diversity is also motivated by the fact that we aim to supsup-port the access to digital resources in a variety of application scenarios, especially with heteroge-neous components and most likely also heterogeheteroge-neous metadata formats used
8The term metadata monoculture was coined by Randy Goebel in 2008.
for resources. Furthermore, we identified independence and diversity of con-tributions as two of the challenges when aiming to support the access to digital resources by means of social media technologies in Chapter 3.
These requirements are also supported by Nilsson et al. in [NPN02], where the authors identified the needs for a Semantic Web architecture, concluding that it should be:
• Evolving, supporting a dynamic metadata eco-system
• Extensible, allowing introduction of new vocabulary with new semantics
• Distributed, supporting descriptions by anyone about anything, anywhere
• Flexible, supporting unforeseen uses of resources
• Conceptual, supporting the evolution of human knowledge
It is clear that a one-size-fits-all solution for metadata about resources will not fit these needs. Instead, an ideal infrastructure would be generic in a way that allows for the generation of adequate resource descriptions for different users in different scenarios. Therefore, potentially any existing metadata might be incor-porated. As we have shown in Section 2.6, the different approaches to generate metadata can only be applied successfully in certain scenarios and for certain types of digital resources and metadata, and each of them has its benefits and limitations. Ideally, a digital environment should allow in each scenario to com-bine the benefits of each of the metadata generation approaches and to avoid the limitations. To allow for subjectivity and diversity, human generated meta-data is most important, as only humans can contribute with different views and opinions. The need for diversity demands a non-authoritarian approach, sup-porting different views of the same resource. Thus, social metadata as defined in Section 3.5 is most likely to meet these requirements, because it allows any user to contribute metadata about a resource.
What are the consequences for a Social Resource and Metadata Hub? Of course social metadata has to be supported. But beyond that, we should be able to make use of potentially any metadata existing in the environment where the hub is introduced. Moreover, it should be possible to contribute a variety of different metadata for digital resources. Such metadata can immediately be helpful for end users (e.g., bibliographic information about a resource), and it can also be an important source for several functionalities (e.g, search or recom-mendations).
4.3 Resource Metadata
4.3.2 Interpretability
Besides subjectivity and diversity, we also have to consider that relevance can only be estimated to a small extent by a machine. A lot depends on the inter-pretation of the end user. Thus, provenance metadata should exist that can be interpreted by humans to judge the relevance of a resource. When we want to be able to interpret the metadata about a resource, this means it must be human-understandable, and it is also very important to know who created and contributed the resource as well as the metadata (credibility was already intro-duced in Section 2.3.2 as an important concept when judging the relevance of a resource). So any information that allows the user to get an understanding of the respective creator or contributor is important.
4.3.3 Core Metadata and Extensibility
We identified that we should offer the possibility to annotate various metadata from different sources for each digital resource. Nevertheless, a minimal set of core metadata elements (not necessarily mandatory) has to be defined. This is required for realizing a standalone component with means for resource contri-bution, resource display, and functionalities to (efficiently) compute and process information in a meaningful way, and furthermore to support interoperability with other components.
Such a core set can, e.g., be based on Dublin Core (see Section 2.4.3), and it should cover all metadata types as introduced in Section 2.4.1. Such basic metadata is required, among others,
• to enable basic functionalities such as search, retrieval and display (includ-ing, e.g., the identifier, title, and location of a resource),
• to allow the generation of different views on resources (e.g., ordered by rat-ing or ordered by number of views),
• to allow users to get an understanding about who provided a resource and metadata,
• to information users about the technical format of a digital resources and the technical requirements to use it, and
• to provide information about intellectual property rights with information about the way in which a digital resources may be used.
In order to improve the probability of cross-disciplinary interoperability and to allow for an easy generation of metadata, such a basic schema should be kept as simple as possible, although this may result in more effort in the part of searchers to identify relevant resources [DHSW02]. While complex schemas might result in better services, they require a higher investment in the creation of metadata, and make it more difficult to promote consistency. The metadata schema as provided for resources in the DaMiT system provides a good example for a partly too complex and too fine-grained specification (cf. [GLM03, JGLM04, JDG+04]). For example, DaMiT aimed to offer four different presentation styles for learning objects, ranging from “formal” to “informal”. During the project, it turned out that it was an impossible task for the authors of the different courses and objects to realise a consistent use of these classifications. A quality control process that was introduced turned out to be an over complex and very time-consuming task. As a consequence, the DaMiT consortium agreed to reduce the available presentation styles to “formal” and “informal” only.
Extensibility In order to enable the support of specific scenarios and resource types in a Social Resource and Metadata Hub, it should be possible to extend the defined core metadata set accordingly. Typical examples for such extensions can concern all metadata types as identified in Section 2.4.1:
• creation and rights metadata (e.g., involving scenario-specific user groups and roles),
• technical information (e.g., for multimedia contents of a specific type),
• content information (e.g., for domain-specific attributes),
• relation metadata (e.g., for classifying resources with respect to a given vocabulary or taxonomy), and
• usage metadata (e.g., taking into account actions involving scenario-specific extensions).
4.3.4 Interoperability
As already stated, a Social Resource and Metadata Hub should allow to inte-grate social media technologies in existing environments. Thus, interoperability
4.3 Resource Metadata
is a key issue, because it must be able to provide the metadata about digital re-sources in the hub to other components. The IEEE9 defines interoperability as follows [Ger91]:
Term 4.1 Interoperability is the ability of two or more systems or components to