Implementation of Metadata for OmniPaper RDF Prototype
Tomoko Yaginuma, Teresa Susana Mendes Pereira, César E. Ariza Ávila, Ana Alice Baptista
Department of Information Systems, School of Engineering, University of Minho, Portugal{tomoko, tpereira, cariza, analice}@dsi.uminho.pt
Abstract
Information Society Technologies (IST) funded
OmniPaper project investigates efficient ways foraccess to distributed and heterogeneous digital newsarchives using state-of-the-art technologies such as
RDF, XTM and SOAP. An approach taken is tocreate small prototypes based on each of them. This
paper presents the first stage of the prototype
development, particularly of RDF approach,including analysis on existing news text format
standards and metadata vocabularies, definition of
metadata elements for OmniPaper, implementationof application profile and RDF schema anddevelopment of the RDF prototype in a web-based
RDF specific application. The elaborated analysis
shows that Dublin Core Metadata Element Set has
to be a principal vocabulary to implement the
OmniPaper application profile as it provides greaterinteroperability. The RDF prototype provides RDF“metadatabase” with searchable interface forsimple and advance search on the defined metadata
elements.
Keywords: Metadata, Dublin Core, Application
Profile, Schema, RDF, OmniPaper.

1. Introduction
OmniPaper (Smart Access to European
Newspapers, IST-2001-32174) [1] is a project fromtheEuropeanCommission
IST
program(Information
Society
Technologies),that
investigates and proposes ways for access todifferent types of distributed information sources.
We intend to achieve the implementation of a
prototype that enables users (professional journalists
and occasional users) to have simultaneous andstructured access to the articles of a large number ofdigital European news providers.
One of the principal aspects of the project is thewhole metadata layer of the system. Conceptually,
there are two metadata layers: (1) the first layer(Local Knowledge Layer) that is added to the local
archives where the main purpose is to provide astandard semantic description of all the existentarticles in order to enable a structured and uniform
access to the available distributed archives; and (2) asecond layer (Overall Knowledge Layer), an higher
abstraction level that will provide a common accessuser interface by integrating and relating themetadata information coming from the local

knowledge layer. Furthermore, this interface ismeant to be personalized and multilingual. Figure 1
shows the conceptual view of OmniPaperarchitecture.
User-friendly
presentation

Overall Knowledge
Layer

Distributed Information
Retrieval (Local
Knowledge Layer)
Distributed Archives

Figure 1. Concept of OmniPaper Architecture
In the OmniPaper project we are developing
simultaneously two different metadata approaches toboth layers: the Resource Description Framework(RDF) [2] approach, and the Topic Maps (TM) [3]approach.
The implemented work related to the RDF
approach in the OmniPaper project has already taken
the following steps:(1) Elaborated analysis of several XML
applications and vocabularies, such as XML News
Industry Text Format (NITF) [4], NewsML (NewsAgency Implementation Guidelines) [5] developed
by International Press Telecommunications Council(IPTC) [6], XMLNews [7], RDF Site Summary(RSS) 1.0 [8], Dublin Core Metadata Element Set(DCMES) [9], and Dublin Core Qualifiers (DCQ)[10];(2) Selection or filter of the metadata elementsthat best define the features of the newspaper articles.
These elements will be included in the application
profile;(3) Definition of other elements, that arenecessary, and are not found in any widely usedvocabulary. These will also be included in theapplication profile;(4) Definition of the vocabulary mentioned in(3) in an RDF schema;(5) Definition of the rules for the RDF/XML
documents’ description;(6) Template of the documents’ description in
RDF/XML;(7) Development of “Metadatabase” prototype
using a native RDF Database Management System(DBMS) - RDF Gateway [11];(8) Transformation of Article XML files andkeyword XML files into RDF/XML files and(9) Implementation of full prototype.
This paper focuses on the RDF approach to the
Local knowledge Layer, and deepens each step
shown above.

2. Analysis of the Existing News Text
Format Standards and Metadata
Vocabularies
For development of application profile for
OmniPaper, major news text formats and metadata
vocabularies were thoroughly studied and analysed.
Those examined formats and vocabularies are as
follows.
•
•
•
•
•

NITF
NewsML
XMLNews
RSS
DCMES and DCQ

In this section, each standard will be briefly
introduced, and then advantages and disadvantages
for OmniPaper application use will be discussed.
Lastly, a decision for the selection will be made.
2.1 NITF
NITF is a text format standard which defines thecontent and structure of news articles. It was firstcreated based on SGML and then after 1998 updated to be compliant with XML. NITF supports theidentification and description of a number of news
characteristics with rich in-line markups. It identifies,
for instance, structural pieces of news article such asheadings, bylines, paragraphs, tables, columns andfootnotes. Metadata tags are also applied fordescribing the news content.
2.2 NewsML
NewsML is a one level higher standard for news
representation and management. It is also based on
XML. The main function of NewsML is the
management of news item throughout its lifelong,including production, interchange and consumer use.
It can contain many different types of objects
including multimedia items such as images, videos,etc. The text written in NITF can be accommodated
within NewsML in self-contained manner. Likewise,other formats like SportML and JPEG can bewrapped by NewsML. While NITF is a standardised
format for description and structuring of news text,
NewsML is used as an information wrapper andmanagement tool.

2.3 XMLNews
XMLNews is a pair of specifications(XMLNews-Story and XMLNews-Meta) maintainedby Megginson Technologies Ltd. XMLNews-Storydefines the content of textual news stories while
XMLNews-Meta defines a set of metadata
information about news objects. Both specifications
are developed based on XML in 1999. XMLNewsStory is a fully-compatible subset of the NITF.
XMLNews-Meta is a news industry metadata format
conforming to RDF. It is used as a single, common
format to provide metadata about any kind of news
object, whether textual or non-textual, separated
from the news objects themselves.
2.4 RSSRSS is an XML-based multipurpose extensible
metadata description and syndication format. The
latest version 1.0 is fully conforming to RDF. A
typical RSS document describes a “channel”
consisting of URL-retrievable items. Each item
consists of a title, link and brief description. While
items have traditionally been news headlines, RSS
has been evolved to be used for multiple purposessuch as aggregation, discussion threads, job listings,
document cataloging, etc.
2.5 DCMES and DCQ
DCMES, which is now in line with the ISO
standards, is a well-known metadata standard forcross-domain information resource description,
developed and maintained by Dublin Core Metadata
Initiatives (DCMI) [12]. DCMES is relatively simple
15 metadata elements set, easy to understand andextend to richer semantic description standards.
DCQ was developed to qualify DCMES in ways thatthese qualifiers either make the meaning of anelement narrower or more specific, or identify
schemes that aid in the interpretation of an element
value. DCQ has been incorporated with the DCMI
type vocabulary and other legacy documents related
to element refinements, and superseded by the
DCMI Metadata Terms document [13].
2.6 Analysis
A close examination shows different aims of
those existing standards: One is for mark-up of news
article and the other is for metadata description ofnews article or any kind of resources. NITF,
NewsML and XMLNews-Story belong to the former
type of purpose while RSS, XMLNews-Meta,
DCMES and DCQ belong to the latter.
A document written according to the former
standards contains a full text (content) of a news
article. Although NITF and NewsML-based
documents can also include metadata elements, themain purpose of the standards is to provide a welldefined and structured in-line mark-up for news text
itself. This makes it easy to handle appearance andtransformation of news article throughout its lifelong,that seems to be one of the main advantages. The
other advantages are explained in details by
Yaginuma, et al [14].
On the other hand, the documents based on RSS,
XMLNews-Meta or DCMES include only metadata
description about a particular resource. Obviously,
the metadata document is independent and separated
from the original resource. This way, metadata
extracted or transformed from an original resource iseasily handled for further development. The size of
document is much less than the one with news
content, which is also preferable.
For OmniPaper application, as explained in theprevious section, only metadata of news articles areimportant in the development of Local Knowledge
Layer prototypes. Therefore, the formats such as
RSS and XMLNews-Meta or the vocabulary like
DCMES may be preferable for the selection of
metadata elements for OmniPaper. Nevertheless,elements from NITF and XMLNews are worth
analysing for the possible use in RDF.
Further analysis indicated that RSS, as its name
“Site Summary” implies, is more suitable fordescribing news “site” rather than details of eachnews article. Probably, it might be better used forsyndication of completed OmniPaper site or
personalisation of user interface.
In terms of XMLNews-Meta, it appears to besuitable for the OmniPaper purpose in a way that it
can provide metadata separately from news content.
Conformance to RDF seems to be beneficial for
implementation of the RDF prototype. Specification
introduces more than 40 metadata elements, which isrich enough to describe news objects.
However, our first priority for metadata
description was given to DCMES and DCQ becauseof their simplicity and interoperability. They are
rather general and abstract standards but have been
widely used across the boundaries of disciplines orapplication domains. This means news articles
described with DCMES have higher possibility to bediscovered by external applications in different area,
not only in news industry, which is very attractive toachieve Tim Berners Lee’s Semantic Web concept[15]. Main reason why we did not make a full use of
XMLNews-Meta results largely in that point.
To sum up, DCMES and DCQ are taken as
OmniPaper’s principal metadata vocabularies.
Furthermore, when no appropriate element was
found in DCMES or DCQ, we would refer to as
many standards commonly used as possible. The last
option has to be a creation of OmniPaper-original
metadata elements. This must be avoided unlessthere is strong necessity.
2.7 Related Work
Along with the study of existing standards, wehave examined the metadata elements that our news
providing partners currently use for their systems. It
is highly important to know what metadata elements

are in use in the real world. Close examination
showed several characteristics of the elements fordescribing news articles.
(1) Article identification: There are somecommon and essential metadata that all thecompanies use. They refer to the title of an article,
author, issue date and the unique ID for an article.
(2) Article classification and linking: There
are some kind of classification elements which sortthe articles into categories, or reference elements
which link the articles related to each other or in thesame series. Each company has its own way ofclassifying and linking articles, using an existing ororiginal thesaurus or other criteria.
(3) Other media: One company has several
elements that describe the photos used for an article
in details. Another company has an element which
only describes the caption of the photo. Theseelements brought out the issue of how to deal withother media included in the news articles.
(4) Edition and section: Some elements arehighly based on the paper version of news articles.
For instance, they describe from which edition(s) thearticle came from, or in which section of thenewspaper the article belongs to.
These factors were greatly useful for theselection of metadata elements. According to theanalysis described in this section, our initial
metadata elements were chosen.
2.8 Namespaces
Figure 2 summarises metadata sources for
OmniPaper.
Metadata vocabularies or DTD’s already established

DCMES

DCQ

vCard

OmniPaper metadata
vocabularies

Omni

Figure 2. Metadata Sources for OmniPaper
The namespaces for these four sources are listed
below:••••

Dublin Core Metadata Element Set(DCMES) - http://purl.org/dc/elements/1.1/
Dublin Core Qualifiers (DCQ) http://purl.org/dc/terms
OmniPaper RDF Schema (omni) http://www.dsi.uminho.pt/omn/schemas/om
n-schema#vCard - http://www.w3.org/2001/vcardrdf/3.0#

The following section introduces the final set of
metadata elements used for OmniPaper.

3. Metadata Elements Used in
OmniPaper
We have defined 27 elements for OmniPaper.
The tables below show all the elements sorted into 6
categories:• Article Identification;• Article Ownership;• Article Location (Storage);• Article Relevance/Audience;• Article Classification;• Link Information.
Each element is described with name, definitionof the element, the source of the element andrecommended encoding scheme. The encoding
schemes are the qualifiers used for expressing theelement value. These schemes include controlled
vocabulary and formal notation. For the metadata
elements taken from DCMES and DCQ, wefollowed the encoding schemes recommended byDCMI.
As can be seen in the following tables, 18
elements are taken from Dublin Core, either
DCMES or DCQ, and the rest 9 elements are
OmniPaper-original. Majority of elements are takenfrom Dublin Core, which is ideal for maximisinginteroperability.

DCMES

Contributor

An entity responsible
for making
contributions to thecontent of theresource.

DCQ

ExtentSize of an article.

Table 2. Article Ownership
SourceElement

Description

OMNI

Copyright

Container for copyrightinformation.

OMNI

Supplier

The local archive thatowns article.

Table 3. Article Location (Storage)
SourceElement

Description

Encoding
Scheme(s)DCQ

MediumThe physical or digital
carrier of an article.

IMT

DCMES

SourceA reference to an article
from which the present
article is derived.

URI

Table 4. Article Relevance/Audience
SourceElement

OMNI

OfInterestTo The target audience foran article, based on
demographic,
geographic or othergroups.

DCQ

Valid

Date (often a range) ofvalidity of an article.

W3C-DTF

DCQ

SpatialGeographical locationthat an article treats oris related to.

ISO 3166

Table 1. Article Identification
SourceElement

Definition

Encoding
Scheme(s)

DCMES

Identifier

An unambiguousreference to a
resource.

URI

OMNI

UniqueId

An OmniPaper
specific ID for a
resource.

DCMES

Creator

Author(s) of anarticle.

DCQ

IssuedDate of publication of W3C-DTF
an article.

DCMES

Title

Title of an article.

DCQ

Alternative

Substitute oralternative to theformal title of article.

DCMES

Publisher

The entity responsible
for making theresource available.

DCMES

Language

The language inwhich an article iswritten.

OMNI

KindOfArticle Nature or genre of anarticle.

OMNISectionNamed section of apublication where an
article appears.

OMNI

Edition

The name(s) ofedition(s) in which an
article is distributed.

Encoding
Scheme(s)Description

Encoding
Scheme(s)Table 5. Article Classification

ISO 1766& 639

SourceElement

Description

DCQ

Abstract

A summary of the content
of an article.

OMNI

Key_list

A list of most relevant
keywords extracted froman article document.

DCMES

Subject

Topic of the content of anarticle, specified
according to the IPTC
Subject Code.

Encoding
Scheme(s)IPTC
Subject
Code
SystemTable 6. Link Information
SourceElement

Description

Encoding
Scheme(s)DCQ

HasPartThe described article URI
includes the referenced
resource
physically,such as photo, table,
diagram, etc.

DCQ

IsVersionOf

The described article is URI
a version, edition or
adaptationofthereferenced version.

OMNI

SeriesThe name of series thatan article belongs to.

DCQ

References

The described article URI
references, cites orpoints to the referenced
article.

All the elements are repeatable and optional,
though, some basic elements such as Title, Issued
and so on should preferably be provided. Additional
explanation is given to the elements below.
UniqueID: UniqueID is an OmniPaper-original
element. The purpose of this element is to identify acertain article with OmniPaper specific string-based
ID for the process within the OmniPaper system.
The main difference from the Identifier element isthat UniqueId should not be public to the outside of
the system.
KindOfArticle: The purpose of the element is
to classify the form of the article as genre. Thiselement is an OmniPaper original so that the
vocabulary for the values of the property such as
interview has to be also defined (see Figure 4).
Supplier: This element has to describe theorganisation which supplies news articles to the
OmniPaper system. It can be called “Local archive”
as conventionally used in the OmniPaperarchitecture and consortium. It has to be clearly
distinguished from the author of the article, news
companies or distributors which provide news to the“local archives”. NITF Distributor element was oneof the candidates but we took the original “Supplier”
to emphasise the specific meaning.
Spatial: Previously, there were several moreelements which refer to the semantic content of the
document, namely, Doc_scope (NITF), Location(NITF), Company and Organisation. Doc-scopeindicates an area where the article may be of interest.
Location defines a relationship between an article
and a geographical location about which the article
treats. Company and Organisation define therelationshipbetweenanarticleandacompany/organisation about which the article treats.
The first two are very similar so that we had to have
only one element which describes the geographicalspace. Then, the Spatial element, the qualifier of
Coverage (DCMES) was chosen instead of NITF
based Doc_space and Location. The latter twoelements are rather too specific and we decided todiscard them.
It is also worth noting that some of the
OmniPaper-original elements are inspired in otherformats (NITF or NewsML). As these formats are
not metadata vocabularies but DTD's or XML
Schemas and have not yet got the respective
schemas or namespace schemas, they have been
included in our schema always with reference to theoriginal context in which they were developed andare widely used. The elements referenced to NITF
are Section, Edition, Copyright, Key-list andSeries. The element referenced to NewsML is

OfInterestTo. In the next section, we will discuss
about application profile and RDF Schema.

4. OmniPaper Application Profile and
RDF Schema
4.1. OmniPaper Application Profile
The concept of application profiles has emergedin discussions on metadata schemas, in relation towork that is being done on metadata registries,
specifically in DCMI. The application profiles grewout of UKOLN's work [16] on the DESIRE project[17].
Heery and Patel define application profiles asschemas which consist of data elements drawn fromone or more namespace schemas, combined together
by implementers and optimised for a particular local
application [18]. They distinguish namespace
schema from application profile schema.
Namespace is defined within the W3C XML
schema activity [19] and allows for unique
identification of elements, that may be defined
through an RDF Schema. Within the W3C XML and
RDF Schema Specifications [20], namespaces are
the domain names associated with elements which,along with the individual element name, produce a
URL that uniquely identifies the element [18].
According to Heery and Patel [18], with‘namespace’, it is possible to:•••identify the management authority for anelement set;
support definition of unique identifiers forelements;
uniquely define particular data element sets
or vocabularies.

In application profiles, it is possible to [18]:••••use elements of one or more namespaces;
not introduce new elements;
specify schemas and allowed values;
refine normalized definitions.

In the context of the OmniPaper project, thedefinition of the application profile is intended todescribe not only the elements from different
metadata vocabularies but also to describe theelements defined in our own schema implemented
according to the implementation of the RDF/XML
metadata structure that is fully described by
Yaginuma et al. [21].
After an elaborated analysis on the elements for
OmniPaper, described in the previous section, an
RDF/XML application profile [22] based on
vocabulary SMES [23] was developed in the scopeof OmniPaper project. The complete OmniPaper
application profile can be seen in CORES registry[24, 25].

4.2. OmniPaper RDF Schema
The Resource Description Framework SchemaSpecification (RDFSS) [20] is a proposed
recommendation of the World Wide Web
Consortium (W3C) [26]. The schema specification
language is a declarative representation language
influenced by ideas from knowledge representation(e.g. semantic nets, frames, predicate logic) as well
as database schema specification languages andgraph data models [20].
The main goal of the RDFSS consists of thedefinition of a schema specification language thatallows the definition of mechanisms needed todefine elements from specific vocabularies, to define
classes of resources which those elements may be
used with, according to restriction mechanisms,
based on the constraint rdfs:domain, and in thedefinition of values for the properties through therdfs:range.
The RDFSS provides mechanisms ofextensibility of RDF vocabularies, through the useof classes and specific properties of the RDF
Schema. We can define our own vocabularies thatare not more than specializations of vocabularies
normalised as it is the case of DCMES.
In the OmniPaper project, some metadata
elements that were not previously defined neither instandard vocabularies nor in widely-usedvocabularies are used. For this purpose, a specificOmniPaper vocabulary containing these metadata
elements was created using RDF Schema.
In Figure 3, illustrated below, we show theproperties defined in the OmniPaper RDF Schema[27].

In order to support this properties’ definition, a
set of classes was defined in the RDF Schema as
explained below.
The constraint rdfs:range indicates the classes
that the values of a property must be members of.
Each property can only have at maximum one
rdfs:range constraint. “Although it is possible toexpress two or more range constraints on a property,
a similar outcome can achieve by defining acommon super class for any classes that represent
appropriate values for some property” [20]. For thispurpose were defined the classes Article andLocalArchivesSupplier where the classes Interview,
Review, OpinionLetter and News were defined as
subclasses of the class Article, and the classes PTE,
MyNews and Mediargus were defined as subclassesof the class LocalArchivesSupplier, as shown in the
Figure 4 and 5.
rdfs:Classdctype:text

rdf:type

rdfs:subClassOf

Articlerdfs:subClassOf

Interviewrdfs:subClassOf
rdfs:subClassOf

rdfs:subClassOf

Review

OpinionLetter

News

Figure 4. OmniPaper Schema – Relationships
between classes
dctype:text

rdfs:Class

rdfs:subClassOf

rdf:type

LocalArchiveSupplierrdfs:subClassOf

rdfs:subClassOf
rdfs:subClassOf

PTE

Figure 3. Schema Properties
UniqueID, Section, Copyright, Edition, Keylist, Series and OfInterestTo: Applies to all kindsof articles.
KindOfArticle: Applies to all kinds of articles,
may have a value of any kind of article (any or its
subclasses).
Supplier: Applies to all kind of local archive
suppliers. May have a value of any kind of Local
Archive Supplier (any of its subclasses).
Each property has a specific meaning, defines
its permitted values, the types of resources it can
describe, and its relationships with other properties[28].

MyNewsMediargus

Figure 5. Omnipaper Schema – Relationshipbetween LocalArchieveSupplier class

5. RDF Prototype
5.1. Functionalities
To recap, the main purpose of the Local
Knowledge Layer is to provide a standard semantic
description of all the existent articles in order tomake a structured and uniform access to theavailable distributed archives. The RDF approachtries to achieve the best way to describe and storemetadata of provided news articles using RDF andrelated technologies.
The first phase of RDF prototype has thefollowing functionalities:(1) Metadata transformation: the prototype
gets metadata from a XML file (newsarticle document) and transforms into RDF
file structured with the predefined
RDF/XML template using XSLT.
(2) Search:• Simple search (single query input
field): full-text search in all metadatafields.
• Advanced search: full-text search inselected metadata fields. Fields are
combined by default using the AND
operator. Used fields are Title,
Creator, Issued (Date), Key-list andPublisher.
(3) Search results:• Display of article info (Title, Issued
and Publisher)• Display of search time
• Display of number of search results• Ranking of search results• Case sensitiveness• Query keyword stemming(4) Article retrieval: from XML file using
XSLT.
5.2. System Architecture
The RDF prototype is a web-oriented
application that the user will send and receive
information through the HTTP protocol. The HTMLpages are generated by a RDF Server pages (an ASP
fashioned server).
The code inside RDF Server Pages (RSP) files
interacts with users and the database engine,
executing queries within the metadatabase andsending answers to the users. The system design isshown in Figure 6.
ArticleArticleArticle
XML
XML
XML
Files
Files
Files

Key
Key
Key
XML
XML
XML
Files
Files
Files

Metadata
Database.net XSLT
program

RDF
Files

XSL

RDF Database
Engine/RDF Server Pages

User Interface

SOAP Interface

Figure 6. System Design
For this prototype’s implementation, 1881
English news articles are used as a test sample.
Keywords are extracted in advance by automatic
keyword extraction module, and stored in XML
formatted files. Metadata already exist in the news

articles are mapped to OmniPaper metadata
elements when transformed to RDF/XML files.
The prototype (metadatabase) stores these
metadata extracted or transformed from news
articles in a form of triples. Each RDF file holds one
description about one article. An RDF/XML
template has also been built. Figure 7 presents
formats and relations of data in the RDF prototype.
In the final prototype, SOAP interface willallow the communication with all the distributed
archives. Each archive has to map its own metadata
to OmniPaper metadata and also implement SOAP
interface to respond to the server’s SOAP requests.

Figure 7. Format and Relation of Data
The RDF prototype was developed over RDFGateway, since RDF-Gateway can generate HTMLpages to users by its Network IO Module, and also
can create a Native Database and a Package that areby themselves the applications.
The application was developed in a scripting
language called RDFQL. RDFQL is based on
ECMA Script (Java Script) with query extensions toperform federated searches across multiple data
sources. More details of the system architecture aredescribed by Pereira, et al [29].

6. Future Work
The work for the Local Knowledge Layer, theconstruction of rich metadata layer to access the
distributed heterogeneous digital news archives, iscurrently in the last stage. The RDF prototype forthis layer will be cross-tested and compared with the
Topic Maps prototype and Direct Retrieval approach.
An extension of the RDF prototype for theOverall Knowledge Layer has also been executed. In
this stage, navigation of subject and concept of news
articles are underlined.
All the metadata elements are common to all the
distributed archives so that the common thesaurus isalso used for cross-archive browsing and navigation.
Particularly, IPTC Subject Code [30] is used for
Subject View, and Euro Word Net [31] is used forConcept View of news articles. Currently, mappingof metadata to the common thesaurus is one of the
major problems.

7. Conclusion
In the first year of the OmniPaper project, anumber of significant works have been done fordefinition of metadata element set for the descriptionof digital news articles and development ofsearchable uniformed metadatabase.
Having defined 27 metadata elements for the
OmniPaper, these semantically rich elements arecovering various aspects of news articles that might
result in a valuable contribution for futureapplications related to digital libraries. In this sense,
it was important to create OmniPaper Application
Profile and Schema which are now public through
CORES registry [25].
Choice of DCMES as a principal vocabulary for
the OmniPaper metadata set is ideal as it has alreadywidely been used across the different application
domains. This must lead to greater interoperability
particularly on Internet.
The RDF prototype brings all works done
together into one application. It will be one of thefirst studies on how metadata and RDF contribute to
information retrieval for heterogeneous digital
resources when compared with the other approaches
in the OmniPaper project. Furthermore, integrationof ontologies will have to make the prototype much
more powerful in navigation of information
resources.

References[1] OmniPaper – Smart Access to European Newspapers,EU
project
IST
2001-32174.
http://www.omnipaper.org/, 2002.
[2] Resource
Description
Framework.
http://www.w3.org/RDF/[3] Pepper, S. and Moore, G. (2001) XML Topic Maps
(XTM) 1.0. from http://www.topicmaps.org/xtm/1.0/[4] News Industry Text Format. http://www.nitf.org/[5] News ML. http://www.newsml.org/[6] International Press Telecommunications Council.
http://www.iptc.org/[7] XMLNews. http://www.xmlnews.org/[8] RDF
Site
Summary
(RSS)
1.0.
from
http://www.purl.org/rss/1.0/spec[9] Dublin Core Metadata Elements Set, Version 1.1:
Reference
Description.
from
http://dublincore.org/documents/dces/[10] Dublin
Core
Qualifiers.
from
http://dublincore.org/documents/dcmes-qualifiers/[11] RDFGateway.
from
http://www.intellidimension.com/[12] Dublin
Core
Metadata
Initiative.
http://dublincore.org/[13] DCMI Metadata Terms. From http://purl.org/dc/terms[14] Yaginuma, T., Pereira, T. and Baptista, A. A. (2003)
Design of Metadata Elements for Digital News
Articles in the OmniPaper Project. From theproceedings of the 7th International Conference on
Electronic Publishing, Portugal.

[15] Berners-Lee, T., Hendler, J. and Lassila, O. (2001).
The
SemanticWeb.
from
http://www.scientificamerican.com/article.cfm?article
ID=00048144-10D2-1C7084A9809EC588EF21&catID=2[16] UKOLN. http://www.ukoln.ac.uk/[17] DESIRE. http://www.lub.lu.se/desire/[18] Heery, R. and Patel, M. (2002), Application Profiles:
Mixing and Matching Metadata Schemas. Ariadne,
Issue 25. Retrieved May 12, 2003, fromhttp://www.ariadne.ac.uk/issue25/[19] Extensive Markup Language (XML) Activity
Statement. from http://www.w3.org/XML/Activity[20] Brickley, D. and Guha, R. V. (2003) RDF Schema.
from http://www.w3.org/TR/rdf-schema/[21] Yaginuma, T., Pereira, T. S. M. and Baptista, A. A.
(2003) Metadata Elements for Digital News Resource
Description. From the proceedings of the III
Congresso Luso-Moçambicano de Engenharia,
Maputo, Mozambique.
[22] Pereira, T. and Baptista, A. A. (2002) OmniPaper
Application
Profile.
http://www.dsi.uminho.pt/omn/schemas/Omnipaperap.rdf[23] SCHEMAS: Forum for Metadata Schema
Implementors.
From
http://www.ukoln.ac.uk/metadata/schemas/[24] CORES. http://www.cores-eu.net/[25] OmniPaper Application Profile registered in CORES.
(2003)
Availableat
http://cores.dsd.sztaki.hu/?class=http%3A%2F%2Fw
ww.cores-eu.net%2Fregistry%2Freg%2FAppProfile[26] World Wide Web Consortium. http://www.w3.org/[27] Pereira, T. and Baptista, A. A. OmniPaper Schema
Namespace.
http://www.dsi.uminho.pt/omn/schemas/omn-schema[28] Lassila, O. and Swick, R. R. (1999) RDF Model and
Syntax Specification. http://www.w3.org/TR/RECrdf-syntax/[29] Pereira, T. and Baptista, A. A. (2003) The
OmniPaper
Metadata
RDF/XML
Prototype
Implementation. From the proceedings of the 7thInternational Conference on Electronic Publishing,
Portugal.
[30] IPTC
Subject
Codes.
Availableat
http://www.iptc.org/metadata/index.php[31] EuroWordNet. http://www.illc.uva.nl/EuroWordNet/