Harmony discussion note 19991019-abc-draft

ABC

A Logical Model for Metadata Interoperability

Status of this document

This is a strawman document to initiate discussion of a common conceptual model to facilitate interoperability among application metadata vocabularies. The ABC document is a result of the JISC/NSF/DSTC sponsored Harmony project and is not an official working document of the Dublin Core, INDECS, MPEG-7 or any other metadata initiative. It does however draw heavily on the work of these groups in formalizing a variety of mechanisms to support interoperability. The modeling methodology builds on concepts from the Resource Description Framework (RDF) of the W3C, but should also be applicable in non-RDF contexts. The Acknowledgements section gives some further background to this work.

Principal Investigators of Harmony, and responsible parties for this document, are Dan Brickley (Daniel.Brickley@bristol.ac.uk), Jane Hunter (jane@dstc.edu.au), and Carl Lagoze (lagoze@cs.cornell.edu).  

Note to Readers: This is a draft document. As such, it is incomplete in many parts and not yet in a final form of organization.  The authors of this document expect this document to evolve as discussions and work on the ABC model proceed.  


Contents


1. Overview

The Warwick Framework [1] describes the concept of modular metadata - individual metadata packages created and maintained by separate communities of expertise. A fundamental motivation for this modularity is to scope individual metadata efforts and encourage them to avoid attempts at developing a universal ontology. Instead, individual metadata efforts should concentrate on classifying and expressing semantics tailored toward distinct functional and community needs. Warwick Framework-like modularity underlies the design of the W3C's Resource Description Framework (RDF), which is a modeling framework for the integration of diverse application and community-specific metadata vocabularies.

While the Warwick Framework proposes modularization as fundamental to a workable metadata strategy, it recognizes a number of challenges in the implementation of such. An outstanding one is the interoperability of multiple metadata packages that may be associated with and across resources. These packages are by nature not semantically distinct, but overlap and relate to each other in numerous ways. Achieving interoperability between these packages via one-to-one crosswalks [2] is useful, but this approach does not scale to the many metadata vocabularies that will inevitably develop.  .

A more scalable solution is to exploit the fact that many entities and relationships - for example, people, places, creations, organizations, events, certain relationships and the like - are so frequently encountered that they do not fall clearly into the domain of any particular metadata vocabulary but apply across all of them.

ABC is an attempt to:

The ABC logical model has a trivial mapping to RDF, but neither restricts itself solely to mechanisms built into the RDF core nor assumes an RDF-centric implementation environment.

The concepts and inter-relationships modeled in ABC could be used in a number of ways. In particular:

  1. Individual metadata communities could use these underlying concepts (the ABC vocabulary) to guide the development of community-specific vocabularies. These individual communities could use formalisms such as RDF to express the possibly complex relationships between the ABC model and their community-specific vocabularies.

  2. The formal expression of the relationships between community-specific vocabularies and the ABC model could provide the basis for a more scalable approach to interoperability among multiple metadata sets. Rather than one-to-one mappings among metadata vocabulary semantics, a more scalable basis for interoperability could be achieved by mapping through this common logical model.


2. Scope

In order to scope the ABC effort itself, it is important to state what ABC is not:

Below is an executive summary of the draft ABC model described in the remainder of the document:

This document includes two equally important components of the ABC model: an architecture and a vocabulary. The architectural overview introduces the descriptive machinery used in the ABC model; the vocabulary description makes use of this architectural machinery to characterise a set of abstract base classes for interoperable resource description. 


3. The ABC Architecture

The ABC architecture is the conceptual and logical framework within which we set out to describe the ABC vocabulary and its relationship to other metadata vocabularies. Architecturally, ABC borrows heavily from the RDF approach to resource description. While it is important to avoid entangling the creation of conceptual models (such as the ABC vocabulary) in implementation details such as syntax, it is also important to provide some basic infrastructure and terminology. The modeling primitives of RDF provide an adequate, although not necessarily complete, foundation for specifying the ABC architectural model. The RDF-inspired architectural model adopted for ABC is described in its entirety by this document; detailed knowledge of RDF is not needed to understand ABC.

The structure of this section is as follows.  First, there is an enumeration of basic assumptions that guide the architecture. Second, these assumptions are then refined into a set of data modeling principles that provide that basis for ABC metadata vocabulary description . Third, there is a description of the hierarchical relationships that provide the basis for mapping metadata vocabularies to the ABC model. Finally, there is the a description of the rules for moving between simple and complex views of relations.

3.1 Basic Assumptions

The following assumptions provide the basis for the ABC architecture.

Successful (meta)data management and modeling requires a framework for avoiding ambiguity when interchanging data or specifying the relationships that hold between diverse resources. In ABC, ambiguity is avoided through an emphasis on the central role played by unique identifiers. ABC uses unique identifiers to specify the elements of metadata vocabularies (attributes, categories, fields etc.), the relationships that hold between those elements, and for the real-world and digital resources described by those elements.

ABC assumes a single, hierarchically devolved model for the management of resource identifier namespaces. For this ABC adopts the URI system. The URI specification [3] provides a simple 'umbrella' or wrapper that can encompass any well-defined identification system within the global URI namespace. Examples of identification schemes that have representations as URIs include ISBNs, ISSNs, URNs, URLs, DOIs, Handles, phone numbers, UUIDs and PURLs.

In addition to uniquely identifying resources, ABC internally needs URIs to accurately name vocabulary elements, both within ABC and defined elsewhere. The URI approach fits with ABC's goals as it is decentralised and generalist in nature; a number of approaches to resource identification are possible within the encompassing framework provided by the URI specification.

ABC is intended to provide the 'semantic glue' for interrelating application-specific metadata sets. One well understood technique for aiding data interchange in a heterogeneous environment is the use of a 'dumbing down' or 'partial understanding' mechanism. When encountering some previously unknown construct or object, we should be able to mechanically acquire at least some partial understanding through knowledge of the broad 'type' or 'class' of things that it falls into.

By organizing objects into hierarchies of such types, it becomes possible to facilitate interoperability through partial understanding of common base classes. The ABC architecture provides for partial understanding by emphasising the importance of 'specialization' relationships between metadata vocabulary items. The ABC vocabulary presents a hierarchy of common base class definitions and relationship types that can be used as the foundation for more specialised metadata vocabularies.

ABC acknowledges that the same item of information may be represented in a number of different ways depending on the application context. A design goal for ABC is to facilitate the transformation of data structures between simple and complex representational models. ABC itself does not advocate 'complex' or 'simple' representations for application-level deployment. Instead, the ABC architecture provides a mechanism for making explicit the rich data structures often implicit in so-called simple metadata records. Conversely, these mechanisms can be used to generate simpler ('flattened', optimized) views of more complex (verbose) data structures.

ABC adopts a particular strategy for modeling complex metadata. It asserts that properties (attributes) can be associated with all resources (first-class objects) and thus describe those first class objects in greater detail. Furthermore, since ABC considers properties (eg. 'hasPart','illustrator') themselves as simply a specialized type of resource, we can (if needed) describe properties of properties (by 'promoting' a property to a first-class object), or use our uniquely identified properties to articulate rules for translating between different views of the same information content.

ABC is based around a simple logical core designed to provide a bridge between machine-processable data structures and intuitive, understandable conceptual models. As such, the working hypothesis for ABC's development has been that a few logically-oriented modeling principles (such as specialization, partial understanding, multiple views) provide a system within which independently managed metadata vocabularies can build upon a shared understanding of their common semantics. The use of a logically organised, hierarchical architecture allows for the articulation of simple rules, which are described in the next section, to guide modeling and other applications.

3.2 ABC Data Modeling

A handful of underlying assumptions, informed by the ABC principles already listed, provide the basis for the ABC approach to metadata vocabulary description.

Everything in ABC is a modeled as a 'resource'.  Resources include real world entities - physical and digital - as well as intangible entities such as concepts, performances or relationships (i.e. concepts that express connections between entities such as authorship or derivation).

This flavour of Entity/Relationship modeling provides us with a simple "directed labeled graph" system in which resources (entities) are represented by nodes which are connected by property (relationship) arcs to either value terminators or other resources (entities). This is both expressive and reasonably intuitive when represented in diagram form. ABC proposes a number of conventions for representing meta-information in this system, and for converting between complex and simple modeling styles.

By attending to the grouping of resources into sets ('classes'), and by giving unique names to those sets, we have a simple foundation upon which to build richer structures. By giving a name to the class-specialization relationship ('super class') we can provide explicit information about hierarchies of resource types. ABC builds upon these specialization relationships between classes of resource, and between types of property (or relationships). The ABC vocabulary described in this document consists of a hierarchy of entity class definitions and relationship types.

By representing entity types (classes) and relations (properties) as just another class of 'resource', we can re-apply our modeling approach to describe metadata vocabularies themselves. For example, the relationship hasBodyPart is a specialization of the relationship hasPart. Since these are simply two more identifiable resources, we can easily model the relationship that holds between them: hasPart is a 'super property' of hasBodyPart. The occurrence of the latter (specialized) property tells us everything that the former tells us, and more. Structures such as these provide the basis for 'dumbing down' mechanisms to support partial understanding across metadata applications.

3.3 ABC Mapping Rules

ABC encourages a hierarchically oriented approach to metadata vocabulary description. Wherever it is possible to state explicitly the relationships between metadata vocabularies (eg. that one class is a superset of another), ABC aims to do so. The rules provided here are intended primarily as a guide for vocabulary mapping applications.

3.3.1 Class Hierarchy Rules

By using the notion of resources belonging to classes, and classes forming hierarchies arranged by super-class relationships between classes, it is possible to write down some simple guiding rules to express claims such as 'all Songs are Musical Works':

Example: if we consider the class AudioRecording to be a specialization of the broader class Manifestation, which in turn has a super-class Creation, then we know that any resources that are AudioRecordings are also Manifestions and Creations.

3.3.2 Property Hierarchy Rules

Similarly, we can exploit knowledge of hierarchies of property (relation) types:

Example: consider a case where a property such as composer has been used to relate a creative work to some agency (most likely a person, although it could be a computer or even an animal) that composed it. If we know that the property composer has a super-property contributor then we implicitly know that the contributor relationship should also hold between the work and the agent. Phrased another way: if we know someone or something composed a work, we also know they contributed to it.

3.4 Multiple Views and ABC Rules

3.4.1 Simple Versus Complex Views

Sometimes  we want to further describe a relation of one resource to another.  ABC (by adopting RDF's graph data model) allows us to express this as follows. We create a model in which the resource that is the input to the relation, the resource that is the output of the relation, and the relationship between the two resources are all represented as 'resources'. Properties can then be associated with these resources, which more richly describe them. In this manner, we have promoted a simple relationship arc to a first class resource and associated properties with it. For certain applications, the complicated, explicit model is most useful; other times it is better to have a simple, flattened representation of the 'real' state of affairs. In both cases it is useful to understand how the two representations inter-relate.

The example below illustrates this point. We can either take a simple view and say just that some document has a translation into another document.

Or else we can take a complex view and promote the hasTranslation relationship to a first class event resource and then associate properties with that  resource to describe the full details of the event which transformed the one document into the other.

This policy of creating describable resources extends beyond events/dynamic relations to provide a general style for ABC modeling - for example, if we want to say something about the contribution a particular agent made to some event, we create a resource representing that contribution and describe its properties and relationships to other resources.  As another example, if we want to further describe a 'containment' relationship between two resources (the association between a movie and a component scenes), we can transform that relationship into a resource and associate properties with it (e.g., its starting and ending times).  

3.4.2 Event-centric versus Relation-centric Views

Certain types of events (such as those which have both input and output resources or which describe an agent's contribution to a resource) provide information that can be expressed as a simpler binary relation between resources. Examples of such event/relation pairings include...

In such cases, ABC provides two representational options and recipes for inter-conversion. When rich information is required, ABC provides the event model. This involves promoting the event through which that relationship was realised to first-class object status and describing the hidden detail implicit in a simple relation. When concise/simple metadata is needed, flatter relations are used. When an event-oriented analysis is inappropriate (static relations - such as descriptions of multimedia structures), an analagous approach may be applied by promoting the containment relation to a first-class object and attaching properties such as spatial or temporal extent to it.

The next section illustrates some rules for particular scenarios which illustrate the way in which we can switch between event-centric and relation-centric views.

3.4.3 Transformation Rules

This section attempts to articulate transformation rules which can be used for mapping between simple and complex representational views.

The notion of rules expressed over the ABC modeling formalism gives us some conceptual machinery for thinking and talking about how different representations relate to one another. However in addition to the rule mechanism we need a common understanding of how best to create interoperable complex representational models. It is inadequate to simply assert that complex and simple views of metadata models should interoperate by describing rules for their mappings. Without common conventions or patterns for dealing with this complexity, the number of rules required to map between vocabularies would be vast. The ABC approach is to build upon a handful of base classes (defined within the vocabulary), specializing them only when necessary, and to adopt a node-ification approach for complex representational challenges.

A basic level of cross-vocabulary interoperability can be facilitated using simple class and property hierarchies. The ABC vocabulary is targeted at supporting such applications. By providing an approach and a basic but useful core vocabulary, ABC encourages other vocabularies to express mappings to one another and to ABC using a common approach.

In support of the 'multiple views' philosophy behind ABC, it is useful to explore a generalisation of our simple rule mechanism to support representations of more complex vocabulary mappings. The current document does not provide a formal language for the specification of mapping rules; instead, simple prose rules are used, couched in terms of a template rule structure.

Generic ABC Rule Template:

IF we know [some state of affairs] THEN we can conclude [some more information]

The application of this template should become clearer as the ABC vocabulary is itself introduced. A brief example is presented here to give a sense of the possibilities. The ABC Rule template has placeholders for fairly arbitrary statements of affairs expressible within ABC's RDF-like modeling style, but represented in prose.

3.4.3.1 Example 1: Event/Relation Rule

If we know [that some Event has an input document and an output document, and we know that the event was of type TranslationEvent] then we can conclude that [the input document to that event stands in a hasTranslation relationship to the output document.]

Conversely, we might describe the opposite tranformation:

If we know [that some pair of resources are connected by the hasTranslation relation] then we can conclude that [there exists some event which had those two resources as input and output documents]

This rule-based approach to vocabulary description is designed to minimise ambiguity and to make explicit facts which are easily left unarticulated. Although ABC does not provide a machine-processable rules language, the use of prose in this vein (in the context of the actual ABC vocabulary) can provide for very precise specifications. Note that the rule above would hold even if the event were actually some particular specialized type of TranslationEvent defined in another metadata community, since the partial understanding mechanism provided by the class hierarchy ensures that the rule applies to all resources of type TranslationEvent.

3.4.3.2 Example 2: Output Property/Agent Rule

This rule expresses the concept illustrated in the above diagram where a translation event with a contributor whose role is translator then implies the property relationship translator between the resulting resource and the "resource" representing the illustrating agent.

If an abc:Event has an abc:contribution from some agency (where the agency is identified by an abc:agent property of the contribution), and if that contribution has an abc:role of X, then we can conclude that any abc:output resources associated with the event have a property of type X pointing to the contributing agent.


4. The ABC Vocabulary

Status Note:
This release of the ABC draft contains only a preliminary and tentative sketch of a complete vocabulary model. It is hoped that the preliminary vocabulary proposed here can provide a starting point for discussions at the ABC workshop which will lead to further refinement, extension and clarification.

4.1 Overview

The goal of the ABC vocabulary is to define and declare a core set of resource categories that are common across metadata communities - these are represented by ABC's abstract base classes.  These base classes are intended to provide the proper attachment points (i.e. entities) for different properties (or metadata) that are associated with information content and its lifecycle. 

Informally, the different metadata attachment points are:

4.2 The ABC Base Classes

The initial (and incomplete) ABC class hierarchy is as follows:

Included below are some initial definitions of the components of this class hierarchy to promote further discussion. RDF-like graphs are used to express these definitions in a manner consistent with the basic architectural assumptions of ABC.

4.2.1 Resources

'Resource' is the class of all things that are (in-principle) identifiable. The class 'Resource' might equally be called 'Stuff', 'Things', 'Entity'; ABC's notion of a Resource corresponds exactly to RDF's. Diagrammatically, Resources are represented by ovals.

Various specialized types of Resource are acknowledged by ABC. The more fundamental of these derive from the RDF approach including representations of 'class', 'property', 'super property', 'super class' and 'type'. 

 4.2.1.1 Creations

Creations are a subclass of Resources. Based on the IFLA [4] model, Concept, Expression, Manifestation are all subclasses of the Creation class. Items are a subclass of Manifestations.

4.2.2 Properties

ABC defines not only classes of resource, but also classes of properties. Sometimes ABC defines an actual type of property (eg. abc:contribution); other times, ABC simply provides a class that names a broad umbrella category of (community-defined) properties so that they can be treated systematically.

In the remainder of this document we will sometimes use the terms attribute and relation when referring to properties. The difference between these terms is as follows:

4.2.2.1 Attributes

These are simple properties which have a value such as a string or integer. Attributes hold information which is directly about a resource.

4.2.2.2 Relations

These are properties between two (or more) resources. They include properties which are complex attributes such as: abc:agent (which indicates agency with respect to some contribution), abc:contribution (which represents the contribution made by some agent to an event), and abc:role (indicating the role played by some agent's contribution to an event). But they also include relationships such as DerivedFrom, PartOf, Neighbours, Siblings and the temporal and spatial relationships encountered within audiovisual resources. Relationships can be unary, binary or n-ary and uni-directional or bi-directional. Initially we will restrict relationships to binary and assume that n-ary relationships can be expressed as multiple binary relationships. Ideally one could define a set of elements and express, using the data model, an n-to-n relationship between all of the elements within the set e.g., the n-to-n 'neighbours' relationship.

We propose 2 types of relations:

More details on these relations is given in the sections below.

4.2.3 Events

The interaction between events and resources can be informally described by dividing events into four sub-classes that are distinguished by the nature of the inputs and outputs to the event.

  1. Events which generate a new transformed or derived resource (e.g. translation, extraction, summarization).
  2. Events which don't transform a resource but which need to be recorded for reasons such as rights management e.g. change of ownership.  For this case, a simple flat view might then show that the "metadata" for the second resource has transformed with a new value for an owner element.
  3. A "creation" event that has no inputs other than the creative imagination of some agent.
  4. A "terminal" event that has no persistent result (something that can be acted on by another event).  Examples of these ephemeral disseminations might be a non-recorded performance or one-time display onto a computer screen.

The existence of the last two sub-classes, creation and terminal, are by definition open to some interpretation.  It can be argued that nothing is created without basis and every dissemination can be used as the basis for some further creation (e.g., a memoir of one's attendance at a non-recorded performance). 

The abc:event class has the following properties:

4.2.4 Contributions

The abc:Contribution class contains the information relating to the event contribution made by a particular agent. It includes the agent's metadata (abc:agent), the role of that agent in the event (abc:role) and the context (abc:context) of the contribution (Date and Place).

The contribution node is necessary to handle the situation of multiple agents contributing to a particular event. Each contribution property indicates a further resource that represents the Action (broadly conceived) undertaken by that agency with respect to the Event we're concerned with. If the identity of the agency is known, an 'abc:agent' property of the Action points to a representation of the agent. If the role or roles played by the agent regarding this contribution to the event are known, an 'abc:role' property is used to point from the Action to a resource that is of type 'abc:AgentRoleProperty'.

4.2.5 Agents

ABC tentatively defines a class 'Agent' with sub-classes for some basic kinds of agent. Agents represent the resources which act in an event - or the "actors" in an event

Some commonly-used agent types are:

In reality, however, any resource may take a causative role, thus allowing it to act as an agent. Additional possible agent types include: animals, fictional animals (Teletubbies), aliens, supernatural beings, imaginary creatures, inanimate objects (e.g., a painting that falls from a wall and strikes a sculpture, which shatters and then is presented as a new resource in a museum show), natural or environmental processes (storms, plagues, erosion, decay etc.)

4.2.6 Roles

The abc:Role class is a subclass of the property class. Roles are the set of possible ways to contribute to an event.

Each agent in an event can have their own set of specialized roles which ABC may or may not enumerate. For example the abc:Agent role can have a number of specializations. Corresponding to abc:Agent are a set of possible Role values such as 'creator', 'illustrator', 'producer', 'publisher' etc.

The AgentRoleProperties serve a dual function: members of this class can be used to annotate a contributory-action resource with details of the role played, but can also serve themselves as properties. A single agent may contribute to one or more events through a variety of roles; by modeling contributions (alternate term: actions) as first class resources, we avoid conflating an agency with particular roles they play. This model provides a foundation for switching between simple (flat) representations, for example a simple translator relationship, and richer event-oriented views in which the full interplay of multiple contributing agencies can be unambiguously expressed.  

4.2.7 Context

Context is a member of the property class which is commonly associated with Events. Subclasses of context include: abc:Time and abc:Place ("When" and "Where"). Context can be associated with either events or contributions.

4.2.8 Non-event-based Relations

While the event-based model is highly expressive, there are nevertheless cases in which it is not the most natural way of expressing information. An example is the need within the context of multimedia to describe complex n-ary relationships when characterising the details of some multimedia structure.

Some examples of non-event-centric relationships are: 

4.2.8.1 Reference and Contextual relations

These are relationships which are neither event-based nor structurally-based. These relationships are assumed to have been established at the time of creation e.g. References/isReferencedBy, RelatedBySubject.

While these are relatively simple cases, they indicate the limits of the natural expressiveness of the event model. While we could posit a 'referencing event' to describe the process whereby a reference came into being, this is not a particularly intuitive model to adopt.

This creates a challenge: if we want to describe additional features of the relationship between two resources, how can we best do this? It is at this point that modeling and architectural considerations interact. It could be argued that abstract data models should not concern themselves with such detail. Through being constrained to use simple binary relations, ABC (and RDF) does not provide a ready answer. The basic approach under investigation is that the same strategy as that employed with Events can be re-used: promote to first-class object status all things worthy of detailed descriptions.

4.2.8.2 Structural relations  

These are containment relationships which describe items within a collection or the sub-parts of a larger container or composite resource. For example structural relations can be used to specify the regions within an image, the scenes within a video sequence, the chapters in a book or the tracks on a CD. They may have spatial, temporal or spatio-temporal attributes which define the location of the parts relative to the whole.

Illustrated here is a preliminary attempt to create a reasonably intuitive directed labelled graph (resources and properties) view of a complex relationship. The approach shown creates a resource which itself represents the actual relationship that holds between two informational resources (in this case an image and an image-region). A number of additional items of information (associated with the region's spatial extent) are attached to this 'ContainmentRelation', which is a resource representing the 'hasPart' relationship we're describing.

The figure below illustrates the application of a 'ContainmentRelation' to a video which contains a sequence of segments. When multiple parts are being described, then the separate extent information must be attached to each individual part. In this case, each segment has an associated temporal extent, defined by the segment's start and end times (within the complete video).


5. ABC Open Issues

  1. What is the definition of a "first class entity"?
  2. How to handle N-to-N relationships e.g. a set of resources which are neighbours?
  3. How to describe activities/procedures/methodologies as raised by David Bearman in his feedback?


References

[1] Lagoze, C., C. A. Lynch, and R. Daniel Jr, "The Warwick Framework: A Container Architecture for Aggregating Sets of Metadata", Cornell University Computer Science Technical Report TR96-1593, June 1996, http://cs-tr.cs.cornell.edu/Dienst/UI/2.0/Describe/ncstrl.cornell/TR96-1593

[2] Library of Congress, Network Development and MARC Standards Office, "Dublin Core/MARC/GILS Crosswalk, 1997, http://lcweb/lc/gov/marc/dccross.html

[3] Berners-Lee, T, R. Fielding, and L. Masinter, "Uniform Resource Identifiers: Generic Syntax", IETF RFC 2396, August 1998, http://www.isi.edu/in-notes/rfc2396.txt

[4] International Federation of Library Associations and Institutions (IFLA), "Functional Requirements for Bibliographic Records", March 1998, http://www.ifla.org/VII/s13/frbr/frbr.pdf

[5] Bearman D., G. Rust, et. al., "A Common Model to Support Interoperable Metadata", D-lib Magazine, January 1999, http://www.dlib.org/dlib/january99/bearman/01bearman.html

[6] ICOM/CIDOC Documentation Standards Group, Revised Definition of the CIDOC Conceptual Reference Model, September 1999


Acknowledgements

Support for the work in this document came from a number of source including NSF Grant 9905955, JISC Grant 9906, and DSTC Pty Ltd.  This document, like many interoperability efforts, draws heavily upon ideas from a number of communities and individuals. In particular, it reflects ongoing discussions amongst members of the Dublin Core and INDECS initiatives as well as the thoughts of many in the RDF community. Eric Miller (DC/OCLC) and Godfrey Rust (INDECS) in particular have contributed greatly to discussions in this area and to this document through lengthy discussions with the authors prior to the creation of the first public draft. The FRBR/IFLA data model, ongoing work in the Dublin Core community, the INDECS Metadata model and the W3C's RDF were all major sources of inspiration for the (composite, derivative) model presented here.