Richly interlinked, machine-understandable data constitute the basis for the Semantic Web. We provide a framework, SCREAM, that allows for creation of metadata and is trainable for a speci c domain. Annotating web documents is one of the major techniques for creating metadata on the web. The implementation of S-CREAM, OntoMat supports now the semi-automatic annotation of web pages. This semi-automatic annotation is based on the information extraction component Amilcare. OntoMat extract with the help of Amilcare knowledge structure from web pages through the use of knowledge extraction rules. These rules are the result of a learningcycle based on already annotated pages.
The Semantic Web builds on metadata describing the contents of
Web pages. In particular, the Semantic Web requires relational
metadata, i.e. metadata that describe how resource descriptions instantiate
class de nitions and how they are semantically interlinked by
properties. To support the construction of relational metadata, we have
provided an annotation [
Though there existed the high-level idea that wrappers and
information extraction components could be used to facilitate the work
[
Amilcare is a system that learns information extraction rules from manually marked-up input. S-CREAM aligns conceptual markup, which de nes relational metadata, (such as provided through OntoMat) with semantic and indicative tagging (such as produced by Amilcare).
There are two major type of problems that we had to solve for this purpose: 1. When comparing the desired relational metadata from manual markup and the semantic tagging provided by information extraction systems, one recognizes that the output of this type of systems is underspeci ed for the purpose of the Semantic Web. In particular, the nesting of relationships between different types of concept instances is unde ned and, hence, more comprehensive graph structures may not be produced (further elaboration in Section 4). In order to overcome this problem, we introduce a new processing component, viz. a lightweight module for discourse representation (Section 5). 2
CREAM is an annotation and authoring framework suited for the easy and comfortable creation of relational metadata. OntoMat is its concrete implementation. Before we sketch some of the capabilities of CREAM/OntoMat, we rst describe its assumptions on its output representation and some terminology we use subsequently. 2.1
We elaborate the terminology here because many of the terms that are
used with regard to metadata creation tools carry several, ambiguous
connotations that imply conceptually important differences:
Ontology: An ontology is a formal, explicit speci cation of a
shared conceptualization of a domain of interest [
Annotations: An annotation in our context is a set of instantiations attached to an HTML document. We distinguish (i) instantiations of DAML+OIL classes, (ii) instantiated properties from one class instance to a datatype instance henceforth called attribute instance (of the class instance), and (iii) instantiated properties from one class instance to another class instance henceforth called relationship instance.
Class instances have unique URIs, e.g. like 'urn:rdf:936694d5ca907974ea16565de20c997a-0'.3 They frequently come with attribute instances, such as a human-readable label like `Dobbertin'.
Metadata: Metadata are data about data. In our context the annotations are metadata about the HTML documents.
Relational Metadata: We use the term relational metadata to denote the annotations that contain relationship instances.
Often, the term annotation is used to mean something like private or shared note, comment or Dublin Core metadata. This alternative meaning of annotation may be emulated in our approach by modelling these notes with attribute instances. For instance, a comment note I like this paper would be related to the URL of the paper via an attribute instance `hasComment'. In contrast, relational metadata also contain statements like: The hotel Zwei Linden is located in the city Dobbertin., i.e. relational metadata contain relationships between class instances rather than only textual notes.
currently only available in German at http://ontobroker.semanticweb.org/ontos/compontos/tourism I1.daml 2.2
The objective of CREAM is to allow for the easy generation of
target representations such as just illustrated. This objective should be
achieved irrespective of the mode of interaction. In the latest version
of CREAM [
OntoMat usually embeds the resulting annotation into the HTML document, but it can also be stored in a separate le or database. 3
Amilcare is a tool for adaptive Information Extraction from text (IE) designed for supporting active annotation of documents for Knowledge Management (KM). It performs IE by enriching texts with XML annotations, i.e. the system marks the extracted information with XML annotations. The only knowledge required for porting Amilcare to new applications or domains is the ability of manually annotating the information to be extracted in a training corpus. No knowledge of Human Language technology is necessary. Adaptation starts with the de nition of a tagset for annotation. Then users have to manually annotate a corpus for training the learner. As will be later explained in detail, OntoMat may be also used as the annotation interface to annotate texts in a user friendly manner. OntoMat provides user annotations as XML tags to train the learner. Amilcare's learner induces rules that are able to reproduce the text annotation.
Amilcare can work in two modes: training, used to adapt to a new application, and extraction, used to actually annotate texts.
In both modes, Amilcare rst of all preprocesses texts using
Annie, the shallow IE system included in the Gate package ([
When operating in training mode, Amilcare induces rules for
information extraction. The learner is based on , a covering
algorithm for supervised learning of IE rules based on Lazy-NLP [
The learner induces two types of rules: tagging rules and correction rules. A tagging rule is composed of a left hand side, containing a pattern of conditions on a connected sequence of words, and a right hand side that is an action inserting an XML tag in the texts. Each rule inserts a single XML tag, e.g. /hotel . This makes the approach different from many adaptive IE algorithms, whose rules recognize whole pieces of information (i.e. they insert both hotel and /hotel , or even multi slots. Correction rules shift misplaced annotations (inserted by tagging rules) to the correct position. They are learnt from the mistakes made in attempting to re-annotate the training corpus using the induced tagging rules. Correction rules are identical to tagging rules, but (1) their patterns match also the tags inserted by the tagging rules and (2) their actions shift misplaced tags rather than adding new ones. The output of the training phase is a collection of rules for IE that are associated to the speci c scenario.
When working in extraction mode, Amilcare receives as input
a (collection of) text(s) with the associated scenario (including the
rules induced during the training phase). It preprocesses the text(s)
by using Annie and then it applies its rules and returns the original
text with the added annotations. The Gate annotation schema is used
for annotation [
Amilcare is designed to accommodate the needs of different user
types. While naive users can build new applications without
delving into the complexity of Human Language Technology, IE experts
are provided with a number of facilities for tuning the nal
application. Induced rules can be inspected, monitored and edited to
obtain some additional accuracy, if needed. The interface also allows
balancing precision (P) and recall (R). The system is run on an
annotated unseen corpus and users are presented with statistics on
accuracy, together with details on correct matches and mistakes (using
the MUCscorer [
In order to synthesize S-CREAM out of the existing frameworks CREAM and Amilcare, we consider their core processes in terms of input and output, as well as the process of the yet unde ned SCREAM. Figure 2 surveys the three processes.
The rst process is indicated by a circled M. It is manual
annotation and authoring of metadata, which turns a document into
relational metadata that corresponds to the given ontology (as sketched
in Section 2 and described in detail in [
The second process is indicated by a circled A1. It is information
extraction, e.g. provided by Amilcare [
The obvious questions that come up at this point are: Is the result of Table 1(b) equivalent to the one in Table 1(a)? How can Table 1(b) be turned into the result of Table 1(a)? The latter is a requirement for the Semantic Web.
The Semantic Web answer to this is: The difference between A1 Document IE tagged
A2 DR
A3
region
accommodation located_at Table 1(a) and Table 1(b) is analogous to the difference between an RDF structure and a very particular serialization of data in XML. This means that assuming a very particular serialization of information on Web pages, the Amilcare tags can be speci ed so precisely5 that indeed Table 1(b) can be rather easily mapped into Table 1(a). The only requirement may be a very precise speci cation of tags, e.g. 43,46 may need to be tagged as lowerprice-of-doublebedroomof-hotel 43,46 /lowerprice-of-doubleroom-of-hotel in order to cope with its relation to a doubleroom of a hotel.
The Natural Language Analysis answer to the above questions is: Learnable information extraction approaches like Amilcare do not have an explicit discourse model for relating tagged entities at least for now. Their implicit discourse model is that each tag corresponds to a place in a template6 and every document (or document analogon) corresponds to exactly one template. This is ne as long as the discourse structures in the text are simple enough to be mapped into the template and from the template into the target RDF structure.
In practice, however, the assumption that the underlying graph structures/ discourse structures are quite similar, often does not hold. Then the direct mapping from XML tagged output to target RDF structure becomes awkward and dif cult to do.
The third process given in Figure 2 is indicated by the composition
of A1, A2 and A3. It bridges from the tagged output of the
information extraction system to the target graph structures via an explicit
discourse representation. Our discourse representation is based on a
very lightweight version of Centering [
The principal task of discourse representation is to describe coherence between different sentences. The core idea is that during the interpretation of a text (or, more general, a document), there is always a logical description (e.g., a RDF(S) graph) of the content that has been read so far. The current sentence updates this logical description by: 1. Introducing new discourse referents: I.e. introducing new entities. E.g., nding the term `Hotel & Inn Zwei Linden ' to denote a new object.
2. Resolving anaphora: I.e. describing denotational equivalence between different entities in the text. E.g. `Hotel & Inn Zwei Linden ' and `Country inn' refers to the same object. 3. Establishing new logical relationships: I.e. relating the two objects refered to by `Hotel & Inn Zwei Linden ' and `Dobbertin' via LOCATEDAT. ! to one of the forward-looking centers, . For instance,
The problem with information extraction output is that it is not clear what constitutes a new discourse entity. Though information extraction may provide some typing (e.g. city Dobbertin /city ), it does not describe whether this constitutes an attribute value (of another entity) or an entity of its own. Neither do information extraction systems like Amilcare treat coherence between different pieces of tagged text.
Grosz & Sidner [
The centering model allows for relating a given entity in utterance when reading The chef of the restaurant in Figure 1 the centering model allows relationships with Country inn, but not with Dobbertin.
The drawback of the centering model is that, rst, it has only been devised for full text and not for semi-structured text such as appears in Figure 1 and, second, it often needs more syntactic information than shallow information extraction can provide.
Therefore, we use only an extremly lightweight, degraded version of centering, where we formulate the rules on an ad hoc basis as needed by the annotation task. The underlying ideas of the degrading are that S-CREAM is intended to work in restricted, though adaptable, domains. It is not even necessary to have a complete model, because we analyse only a very small part of the text. For instance, we analyse only the part about hotels with rooms, prices, addresses and hotel facilities. Note that thereby, hotel facilities are found in full texts rather than tables and not every type of hotel facility is known singleroom Single room /singleroom Further information that could be included is, e.g., adjacency information, etc. Thus, one may produce Table 1(a) out of the discourse representation from a numbered Table 2(a).
The strategy that we follow here is to make simple things simple and complex tasks possible. The experienced user will be able to handcraft logical rules in order to de ne the discourse model to his needs. The standard user, will only exploit the simple template strategy. When the resulting graph structures are simple enough to allow for the latter strategy and a simple mapping, the mapping can also be hotel Zwei Linden /hotel city Dobbertin /city beforehand.
We specify the discourse model by logical rules, the effects of
which we illustrate in the following paragraphs. Thereby, we use the
same inferencing mechanisms that we have already exploited for
supporting annotation [
As our baseline model, we assume the single template stragey, viz. only one type of tag, e.g. hotel , is determined to really introduce a new discourse referent. Every other pair of tag name and tag value is attached to this entity as an attribute lled by the tag value. E.g. Zwei Linden is recognized as an instance of Hotel, every other entity (like Dobbertin, etc.) is attached to this instance resulting in a very shallow discourse representation by logical facts illustrated in Table 2(a).7 This is probably the shallowest discourse representation possible at all, because it does not include ordering constraints or other soft constraints. However, it is already adequate to map some of the relations in the discourse namespace (dr:) to relations in the target space, thus resulting in Table 2(b). However, given this restricted tag set, not every relation can be detected.
For more complex models, we may also include ordering information (e.g. simply by augmenting the discourse representation tuples given in Table 2 by numbers; this may be modelled as 4-arity predicates in F-Logic used by Ontobroker) and a set of rules that maps the discourse representation into the target structure integrating rules to only attach instances where they are allowed to become attached (e.g., prices are only attached where they are allowed) rules to attach tag values to the nearest preceding, conceptually possible entity (thus, prices for single and double room may be distinguished without further ado). rules to create a new complex object when two simple ones are adjacent, e.g., to create a rate when it founds adjacent number and currencies.
single room1 INSTOF Single Room
double room3 INSTOF Double Room (a) Discourse Representation (b) Target Graph Structure de ned by directly aligning relevant concepts and relations by drag and drop, while in the general case one must write logical rules. 6
This section describe a usage scenario. The rst step is the project de nition. A domain ontology can be the basis for the annotation of different types of documents. Likewise a certain kind of documents can be annotated in reference to different ontologies. Therefore a project de nes the combination of a domain ontology (e.g. about tourism) with a certain text type (e.g. hotel homepages). Further the user have do de ne which part of the ontology is relevant for the learning task, e.g. which attributes of the several concepts will be used for tagging the corpus. The mapping of the Ontology to the Amilcare tags works as follows: concepts: concepts are mapped by the name of the concept, e.g. the concept with the name Hotel results in a hotel tag. inheritance: the concepts of the ontology represents a hierarchical structure. To emulate the different levels of conceptualization OnO-Mat allows to map a concept in multiple tags, e.g. the concept Hotel in company , accommodation , and hotel . attributes: The mapping of attributes to tags is a tradeoff between an speci c and a general naming. The speci c naming ease the mapping to the ontology concepts but at the same time it results in more complex extraction rules. These rules are less general and less robust. For example a speci c naming of the attribute phone would result in tags like hotel phone , room phone , and person phone in comparison to the general tag phone . Therefore the user have to decide for every attribute the adequate accuracy of the naming, because it in uences the learning results.
After the de nition of the project parameters one needs a corpus, a set of certain type of documents, e.g. hotel homepages.
If there exist already enough annotated documents in the web the user can perform a crawl with OntoMat and collect the necessary documents. The crawl can be limited here to documents which are annotated with the desired ontology. If necessary the ontology subset and the mapping to the Amilcare tags must be re-adjusted according to the existing annotations in the crawled documents. Afterwards the desired type of document must be checked still manually.
If there are no annotated documents, one can produce the necessary corpus with OntoMat themselves. The user have to collect and annotate documents of a certain type by the sub-set of the ontology that is chosen in the project de nition phase. The document are annotated by OntoMat with RDF facts. These facts are linked by an XPointer description to the annotated text part. Because Amilcare needs as a corpus XML tagged les, these RDF annotations will be transformed into corresponding XML tags according to the mapping done in the project de nition. Only these tags are used to train. Other Tags like HTML tags will be used as contextual information.
The learning phase is executed by Amilcare, which is embedded as a plugin into OntoMat. Amilcare processes each document of the corpus and generates extraction rules as described in section 3. After the training Amilcare stores the annotation rules in a certain le which belongs to the project.
Now it is possible to use the induced rules for semi-automatic annotation. Based on the rules the Amilcare plugin produces XML annotation results (cf. A1 in Figure 2). Here a mapping (A2) is done from OntoMat from the at markup to the conceptual markup in order to create new RDF facts (A3). These mapping is undertaken by the discourse representation (cf. section 5).
These mapping results in several automatic generated proposals for the RDF annotation of the document. The user can interact with these annotation proposals in three different ways of automation: (i) a highlighting of the annotation candidates or (ii) interactive suggestion of each annotation or (iii) a rst full automatic annotation of the document and a later re nement by the user. highlighting mode: First of all the user opens a document he would like to annotate in the OntoMat document editor. Then the highlighting mode marks all annotation candidates by a colored underline. The user can decide on his own if he use this hint for an annotation or not. interactive mode: This mode is also meant for the individual document processing. The interactive suggestion is a step by step process. Every possible annotation candidate will be suggested to the user and he can refuse, accept or change the suggestion in a dialog window. automatic mode: The fully automatic approach is useful if there is a bunch of documents that needs to be annotated, so it can be done in batch mode. All selected documents are annotated automatically. 7
S-CREAM can be compared along four dimensions: First, it is a
framework for mark-up in the Semantic Web. Second, it may be
considered as a particular knowledge acquisition framework very
vaguely similar to Prote´ge´-2000[
The approaches from this line of research that are closest to SCREAM is the SHOE Knowledge Annotator8 and the WebKB annotation tool.
The SHOE Knowledge Annotator is a Java program that allows
users to mark-up webpages with the SHOE ontology. The SHOE
system [
WebKB uses conceptual graphs for representing the semantic
content of Web documents. It embeds conceptual graph statements into
HTML pages. Essentially they offer a Web-based template like
interface like knowledge acquisition frameworks described next.
The S-CREAM framework allows for creating class and property
instances to populate HTML pages. Thus it has a target roughly similar
to the instance acquisition phase in the Prote´ge´-2000 framework [
There are a number of even commercial annotation tools like
ThirdVoice9, Yawas [
Annotea actually goes one step further. It allows to rely on an RDF
schema as a kind of template that is lled by the annotator. For
instance, Annotea users may use a schema for Dublin Core and ll the
author-slot of a particular document with a name. This annotation,
however, is again restricted to attribute instances. The user may also
decide to use complex RDF descriptions instead of simple strings
for lling such a template. However, no further help is provided by
Amaya for syntactically correct statements with proper references.
#$ hhttttpp::////wwwwww..tchsi.rudmvodi.ecde.uc/opmrojects/plus/SHOE/KnowledgeAnnotator.html
The only other system we know that produce semantic markup
with support from information extraction is the annotation tool cited
in [
CREAM is a comprehensive framework for creating annotations, relational metadata in particular the foundation of the future Semantic Web. The new version of S-CREAM presented here supports metadata creation with the help of information extraction in addition to all the other nice features of CREAM, like comprises inference services, crawler, document management system, ontology guidance/fact browser, document editors/viewers, and a meta ontology.
OntoMat is the reference implementation of the S-CREAM framework. It is Java-based and provides a plugin interface for extensions for further advancements, e.g. collaborative metadata creation or integrated ontology editing and evolution. The plugin interface has already been used by third parties, e.g. for creating annotation for Microsoft WordTM documents. Along similar lines, we are now investigating how different tools may be brought together, e.g. to allow for the creation of relational metadata in PDF, SVG, or SMIL with OntoMat.