Meta Data Services

About: Meta Data Services is a research topic. Over the lifetime, 2564 publications have been published within this topic receiving 40102 citations.

Standardizing a Component Metadata Infrastructure

Abstract: This paper describes the status of the standardization efforts of a Component Metadata approach for describing Language Resources with metadata. Different linguistic and Language & Technology communities as CLARIN, META-SHARE and NaLiDa use this component approach and see its standardization of as a matter for cooperation that has the possibility to create a large interoperable domain of joint metadata. Starting with an overview of the component metadata approach together with the related semantic interoperability tools and services as the ISOcat data category registry and the relation registry we explain the standardization plan and efforts for component metadata within ISO TC37/SC4. Finally, we present information about uptake and plans of the use of component metadata within the three mentioned linguistic and L&T communities.

Exposing and harvesting metadata using the OAI metadata harvesting protocol: A tutorial

Abstract: In this article I outline the ideas behind the Open Archives Initiative metadata harvesting protocol (OAIMH), and attempt to clarify some common misconceptions. I then consider how the OAIMH protocol can be used to expose and harvest metadata. Perl code examples are given as practical illustration.

Metadata management in statistical information processing

Abstract: ing from definite functional programming languages, function definitions will, if at all (cf. Appx. A), be given in a pseudo-language called FooL (for Functional 00 Language), a deliberate merge of applicative and relational specification elements resembling the MIRANDA system [Turner, 1986] and specifically inspired by the FOOPlog language [Goguen and Meseguer, 1987]. Note that all domains used implicitly contain an undefined value, denoted as '.l', which is returned by functions if applied outside their domain. In particular, accessing object components not (yet) initialized properly at access time will result in '..L'. Computable expressions are stated in a message format, that is, computations are conceived as messages sent to objects returning answers to messages. Conforming to 00 notation standards, the object receiving a message is always stated first, followed by a (simple or composite) message actually defining the operation; a message consists of a message selector followed possibly by an argument (simple message) or a predefined sequence of message selector/ argument pairs. Simple messages are either unary (postfix; without an argument following) or binary (infix; positioned between receiver object and argument). As a general message selector naming convention, simple message selectors end in a question mark if used as a predicate (that is, as Boolean messages returning •1• -TRUEor 'L• -FALSE) or in inquiry/access mode, and unary imperative messages in an exclamation mark; other keyword message selectors are always designated by a trailing semicolon. To highlight messages, they are typed in italicized boldface font. Operation definitions make use of so-called type polymorphism, that is, the same operation names are introduced for like operations irrespective of the objects they are applied to. Following common usage, the different stances of an operation are termed methods. This convention favourably reduces the number of operation names by building classes of operations with comparable effect though for different (yet related) object types. The general format of a method definition is as follows: first, the message selector (without arguments) is stated followed by the method preamble defining the message type (either of 'infix', 'postfix', or 'arg'), the argument domains including the domain of the receiving object this information resolves the methods' type polymorphism as well as the domain (range) of the returned method output (function value); a method applies only in case of all input argument domains matching its preamble definition. The preamble text, delimited by brackets, does not belong to the functional method definition and uses standard mathematical .I PREMISES AND DESIGN PRINCIPLES 103 notation not to be confused with clause definitions possibly looking rather similar. The preamble terminates with a semicolon. Most of the time, methods (functions) distinguish several cases governing the definite output generation; thus, method definitions consist of one clause for each of its distinguished cases. A clause consists of three parts: an instantiation pattern, a body, and a guard (which may be omitted formally, if it represents a Boolean expression reducing to 'l ', that is being constantly TRUE). Instantiation pattern and clause body are separated by a ·~·;guards always begin with a vertical bar, '1'. Clauses are ordered by definition; in order to enhance readability of method definitions, clauses, in general, are ordered with instantiation patterns ranging from most to least specific. The formal, or execution part of a method definition consists of a sequence of clauses, each of which terminates with a full stop. Clause bodies may consist of any well-formed expression composed of defined messages including explicit and implicit object constructors. In case of nested message expressions, the ordering of argument evaluation is indicated by parentheses wherever suitable to avoid ambiguity and enhance clarity of expression meanings. Although not distinguished typographically, parentheses around message arguments are strictly discerned from tuple parentheses (for instance, assuming a fictitious binary message msg, in the expression '((a msg b),c msg d)', the parentheses around sub-expression 'a msg b' are argument parentheses and thus dropped whereas the outer parentheses are tuple parentheses and thus determining, in fact, a resulting tuple structure as output argument. Guards may be composed just like clause bodies albeit being restricted to expressions returning a Boolean value eventually. FooL Method Execution During method execution, as a first step the active clause of the method is determined; the active clause is the first one in the defined clause sequence for which • the instantiation pattern complies with the arguments of the received message in terms of term unification, and • the attached guard (with arguments instantiated to values obtained from the instantiation pattern unification step) evaluates to 'l ', that is TRUE. Formal arguments in instantiation patterns not referred to any further, may be designated by '_', meaning that such a formal argument matches any actual value in the calling message. Next, the body of the active clause is executed, that is, after instantiation of the formal body arguments the current object submits the active clause's body as a message to be processed. Upon receipt of the value returned in response to this message, its value is passed on to the calling object. Frequently, the output value of a method is augmented with one or more object attributes which, in general, are passed on from the set of the input arguments' attributes. Which attributes a method assigns to its output objects is indicated in the method preamble as a subscript to the mapping arrow separating the domains of input and output arguments. In a few cases, the attribute value passed on to the output argument

Handbook Of Metadata, Semantics And Ontologies

Abstract: Foundations Metadata and Ontology Languages Metadata and Ontologies by Domain Technologies and Systems for Managing Metadata.

Extended metadata and adaptive program service providing system and method for providing digital broadcast program service

Abstract: The present invention relates to extend metadata for providing a digital broadcast program service to diverse kinds of terminals, and a system and method for providing an adaptive program service to the terminals by using the extended metadata. The system and method performs integrated management of resource information suitable for a combination of all (terminal, program and user) conditions of the personal terminal, manages resource-related information separately from temporal/spatial location information, and thus provides an adaptive program service by using extended metadata and recomposing an adaptive scene for a personal terminal so as to provide the digital broadcast service adaptively to diverse terminal environments on a home network. The extended metadata include: segmentation metadata including description information on a significant segment that forms the broadcast program; and resource description metadata including description information on lower composition resources of the segment in order to provide a broadcast program to the diverse kinds of terminals.