Towards A Language for
Metadata Schemas for
Interoperability
Vilas Wuwongse1 and Masatoshi Yoshikawa2
Asian Institute of Technology, Thailand
2Nagoya University, Japan
1
Outline




Introduction and Motivation
Requirements for Metadata Schema
Languages
OWL/XDD
Conclusions
2
Introduction: Metadata



Metadata: the information required to make data useful and
widely usable.
It is an important technology for the storage, management,
discovery, access and utilization of data resources on the
Internet.
Types: metadata for







cataloguing
usage terms and conditions
administration
content ratings
structural description
system/service objects
service/process management objects
3
Introduction: Metadata





Metadata is typically expressed as a set of pairs of property
type and value.
A property type characterizes a feature of data that should be
described as part of its metadata and is normally called a
metadata term or metadata element.
The meaning of a term must be precisely provided for it to be
shareable and interoperable.
A property value can be a simple, atomic literal, or it can be a
complex structure representing a group of related values or
another data resource.
There can be a constraint on the range of a property value.
4
Introduction: Metadata Schemas


All this underlying information about
metadata, i.e., its terms and values as well as
their semantics, syntaxes and constraints are
described in its schema.
A metadata schema is required for metadata to
be analyzed and understood by other
applications.
5
Introduction: Application Profiles


An application profile is a metadata schema
which specifies required terms drawn from
parts of one or more metadata sets, combined
and optimized or constrained for a particular
application.
An application profile could be very
complicated.
6
Introduction: A Layered Model

Sugimoto, et al.’s layered model of metadata
schemas



Semantic Definition
Structural Constraints Definition
Implementation Dependent Syntax Definition
7
Introduction: Summary






There are many types of metadata on the Web
There are many metadata schemas
Metadata schemas are also data
To be sharable and interoperable, metadata schemas
need a common representation framework
Metadata Schema Registry is a database; hence
requires a data model language
Therefore it is desirable to have one common
framework to describe metadata, metadata schemas
as well as their databases
8
Requirements(1): Formal and Precise




A metadata schema is the grammar for the verification of the
well-formedness and validity of its metadata instances.
It is used by other application profiles for their schema
definitions, and by other applications for their analysis and
understanding of metadata instances.
Hence, it must be formally and precisely described so that,
given a metadata schema, its syntactic and, if possible,
semantic checkers, processors or analyzers can be readily
developed.
A good metadata schema language should be formal, precise
and machine-processable.
9
Requirements(2): Complex Definitions



For correct interoperability, there is a need for
detailed definitions of terms for properties, value
types and qualifiers to avoid such problems as
homonyms and synonyms.
There is also a need to define terms at different
levels: metadata term set and application profile
levels.
A good metadata schema language must provide
necessary constructs for these complex term
definitions and refinements.
10
Requirements(3): Term Relationships

There can be relationships between terms in a metadata term
set:



There can also exist relationships across different term types:


between a property type and a value type
Relationships among terms indifferent metadata sets in an
application profile:



Inverse: IsRequiredBy vs. Requires
Subsumption: Description subsumes Subject
Equivalence
Composition
A good metadata schema language should be able to express
these relationships.
11
Requirements(4): Constraints,
Conditions and Rules

An application profile may impose certain constraints on
existing metadata terms:


An application profile may introduce conditions on how its
adopted and refined terms can be used in metadata instances:




mandatory or optional
minimal and maximal occurrences
repeatable
Some general rules or guidelines may need to be described so
that only proper metadata instances are created.


the range of a value type may be narrowed down
Dump-Down Principle
A good metadata schema language should be able to express
these constraints, conditions and rules.
12
Requirements(5): Syntactic
Transformation



A sharable metadata instance of a data resource may
simultaneously appear in many syntactic forms.
The metadata schema of an application must be able
to specify how its metadata instances may be
transformed from their internal syntax into a
required syntactic format.
A good metadata schema language must also be a
flexible syntactic transformation specification
language.
13
OWL/XDD



OWL/XDD is a language which combines
OWL (Web Ontology Language) and XDD
(XML Declarative Description).
OWL, a W3C’s recommendation released in
Feb. 2004, is a language for describing
ontologies as well as their schemas.
OWL can formally and precisely specify
concepts or terms and their various
relationships.
14
OWL
<rdf:Description rdf:about=“”>
<imports resource=“www.books.com/bookont”>
</rdf:Description>
<Book rdf:ID=“book19147”>
<dc:creator>William Golding</dc:creator>
<dc:title>Lord of the Flies</dc:title>
<dc:subject rdf:resource=“&bookont”>FictionChild</dc:subject>
<price currency=“UK Pond”>6.99</price>
</Book>
Metadata Instance
Ontology Instance
Book Collection
imports
bookont ontology
<Class ID=“Book”>
<Property ID=“subject”>
<domain resource=“#Book”>
<range resource=“#Topic”>
</Property>
<Class ID=“FictionChild”>
<subclassOf resource=“#Fiction”>
<subclassOf resource=“#Childrens”>
</Class>
…
15
OWL/XDD



OWL can formally and precisely specify
concepts or terms and their various
relationships.
However, it cannot express complex
constraints and rules.
On the other hand, XDD is a general XMLbased information representation language
with well-defined semantics and the
capability of expressing constraints and rules.
16
OWL/XDD


OWL/XDD incorporates OWL into XDD by
basing XDD’s basic constructs, i.e., XML
expressions or XML elements with variables,
on OWL elements and their semantics.
OWL/XDD is an extension of OWL in which
its elements are allowed to have variables and
their relationships expressed as constraints
and rules.
17
OWL/XDD



Ordinary OWL elements and those with
variables are together called OWL expressions.
An ordinary OWL element without any
variable is specifically called a ground OWL
expression.
Every variable is prefixed by ‘$T:’, where T
denotes its type.
18
OWL/XDD
An OWL/XDD description is a set of OWL
clauses, each of which has the form:
H  B1, B2, ..., Bn
where n  0, H is an OWL expression , and Bi is
an OWL expression, or a constraint.
19
OWL/XDD
As an example, if a property type R is an inverse
of a property type P, then, for any resource X the
value of a property type P of which is a resource
Y, one can infer that Y also has a property type
R the value of which is the resource X.
20
OWL/XDD
<$N:classB rdf:about=$S:ResourceY>
$E:instance1Elmt
<$S:propertyR rdf:resource=$S:ResourceX/>
</$N:classB>

<owl:ObjectProperty rdf:ID=$S:propertyR>
<owl:inverseOf rdf:resource=$S:propertyP/>
$E:inversePropertyElmt
</owl:ObjectProperty>,
<$N:classA rdf:ID=$S:resourceX>
<$S:propertyP rdf:resource=$S:ResourceY/>
$E:XProperties
</$N:classA>,
<$N:classB rdf:ID=$S:ResourceY>
$E:YProperties
</$N:classB>.
21
Satisfaction of Requirements (1)


As shown, OWL/XDD is a combination of
two formal languages, both of which possess
well-defined semantics.
Therefore, OWL/XDD is formal and precise.
22
Satisfaction of Requirements (2)


OWL/XDD can define meaning of various
types and domain-specific terms
For example, a general definition of property
type Creator can given as:
<owl:DatatypeProperty rdf:ID="Creator">
<rdfs:domain rdf:resource="#GeneralDataResource"/>
<rdfs:range rdf:resource="#string"/>
</owl:DatatypeProperty>
23
Satisfaction of Requirements (2)

An application profile component specifying
Creator occurrence number
<owl:Class rdf:ID="MyCollection">
<rdfs:subClassOf rdf:resource="#GeneralDataResource"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#Creator"/>
<owl:minCardinality rdf:datatype= "#nonNegativeInteger">0</owl:minCardinality>
<owl:maxCardinality rdf:datatype="#nonNegativeInteger">5</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
24
Satisfaction of Requirements (3)


Expression of term relationships
For example, equivalence relationship between
Creator and Painter.
<owl:DatatypeProperty rdf:ID="Painter">
<owl:equivalentProperty rdf:resource="http://pur1.org/metadata/dublin-core#Creator"/>
<rdfs:domain rdf:resource="#PaintingCollection"/>
<rdfs:range rdf:resource="#string"/>
</owl:DatatypeProperty>
25
Satisfaction of Requirements (4)

Expression of constraints, conditions and rules
<c:Proceedings>
<c:name>$S:procName</c:name>
<c:editors>$E:pcChairList</c:pcChair>
<c:price>$S:price</c:price>
</c:Proceedings>
 <c:Conference rdf:about=$S:conf>
<c:name>$S:confName</c:name>
<c:year>$S:year</c:year>
<c:country>Thailand</c:country>
<c:pcChairs>$E:pcChairList</c:pcChairs>
<c:registrationFee> $S:regFee</c:registrationFee>
$E:confProperties
</c:Conference>,
[$S:year >= 2002],
[$S:price := $S:regFee * 0.25],
(Concat, "Proceedings of ", $S:confName, $S:procName).
26
Satisfaction of Requirements (5)



Specification of syntactic transformation
An OWL/XDD can also be interpreted as a
rewriting rule in which its body is an input
and its head an output.
It can function like a rule in XSLT and
perform syntax transformation.
27
Conclusions




Metadata will certainly be an indispensable
technology for efficient sharing of information
resources.
Its usage will spread horizontally to cover a variety
of domains and applications, and vertically to
include both simple metadata as well as complex,
structured-value and multi-layer metadata.
A language employed to specify the schemas of such
metadata must be expressive and readily extensible.
Such a language has been sketched.
28