1 / 28

Towards A Language for Metadata Schemas for Interoperability

Towards A Language for Metadata Schemas for Interoperability. Vilas Wuwongse 1 and Masatoshi Yoshikawa 2 1 Asian Institute of Technology, Thailand 2 Nagoya University, Japan. Outline. Introduction and Motivation Requirements for Metadata Schema Languages OWL/XDD Conclusions.

aric
Download Presentation

Towards A Language for Metadata Schemas for Interoperability

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Towards A Language for Metadata Schemas for Interoperability Vilas Wuwongse1and Masatoshi Yoshikawa2 1Asian Institute of Technology, Thailand 2Nagoya University, Japan

  2. Outline • Introduction and Motivation • Requirements for Metadata Schema Languages • OWL/XDD • Conclusions

  3. 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

  4. 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 andinteroperable. • 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.

  5. 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.

  6. 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.

  7. Introduction: A Layered Model • Sugimoto, et al.’s layered model of metadata schemas • Semantic Definition • Structural Constraints Definition • Implementation Dependent Syntax Definition

  8. 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

  9. 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,itssyntactic and, if possible, semantic checkers, processors or analyzers can be readily developed. • A good metadata schema language should be formal, precise and machine-processable.

  10. 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.

  11. Requirements(3): Term Relationships • There can be relationships between terms in a metadata term set: • Inverse: IsRequiredBy vs. Requires • Subsumption: Descriptionsubsumes Subject • 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: • Equivalence • Composition • A good metadata schema language should be able to express these relationships.

  12. Requirements(4): Constraints, Conditions and Rules • An application profile may impose certain constraints on existing metadata terms: • the range of a value type may be narrowed down • 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. • Dump-Down Principle • A good metadata schema language should be able to express these constraints, conditions and rules.

  13. 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.

  14. 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.

  15. 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 <Class ID=“Book”> <Property ID=“subject”> <domain resource=“#Book”> <range resource=“#Topic”> </Property> <Class ID=“FictionChild”> <subclassOf resource=“#Fiction”> <subclassOf resource=“#Childrens”> </Class> … Book Collection imports bookont ontology

  16. 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 XML-based information representation language with well-defined semantics and the capability of expressing constraints and rules.

  17. 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.

  18. 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.

  19. OWL/XDD AnOWL/XDD descriptionis 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 aconstraint.

  20. 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.

  21. 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>.

  22. 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.

  23. 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>

  24. 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>

  25. 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>

  26. 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).

  27. 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.

  28. 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.

More Related