Open Geospatial Consortium
Approval Date: 2012-09-07
Publication Date: 2012-10-10®

External identifier of this OGC docu ment: http://www.opengis.net/doc/bp/s emantic-annotations

Reference number of this document: OGC 08-167r2
Version: 2.0
Category: OGC® Best Practice
Editor: Frédéric Houbie, Philippe Duchesne, Patrick Maué

Semantic annotations in OGC standards

Copyright © 2012 Open Geospatial Consortium.
T o obtain additional rights of use, visit http://www.opengeospatial.org/legal/.

Warning

T his document defines an OGC Best Practices on a particular technology or approach
related to an OGC standar d. T his document is not an OGC Standar d and may not bereferred to as an OGC Standar d. It is subject to change without notice. However, thisdocument is an official position of the OGC mem bership on this particular technology
topic.
Document type:
Document subt ype:
Document st age:
Document language:

OGC ® Best PracticeNA
Approved for public release
English1

OGC 08-167r2
License Agreement
Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set for th below,
to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property
without restriction (except as set forth below), including w itho ut limitation the rights to implement, use, copy , modify , mer ge, publish,
distribu te, and/or su blicense copies of the Intellectua l Property , and to permit persons to w hom the Intellectual Property is furnished to
do so, prov ided that all copy right notices on the in tellectual property are retained intact and that each person to whom the Intellectual
Property is furnished agrees to the terms of this Agreement.
If y ou modify the Intellectual Property , all copies of the modified Intellectual Property must include, in addition to the ab ove
copy right notice, a notice that the Intellectual Property includes modifications that have no t been approved or adopted by LICEN SOR.
THIS LICEN SE IS A COPYRIGHT LI CENSE ONLY, AND DOE S NOT CONVEY ANY RIGHT S UNDE R ANY PATENT S
THAT MAY BE IN FO RCE ANYWHE RE IN THE WO RLD.
THE INTELLECTUAL P ROPERTY IS P ROVIDED "A S IS", WITHOUT WARRANTY O F ANY KIND, EXPRE SS O R IMPLIED,INCLUDING BUT NOT LI MITED TO THE WARRANTIE S OF MERCHANTA BILITY, FITNE SS FO R A PARTI CULARPURPOSE, AND NONINFRINGEMENT O F THI RD PARTY RIGHTS. TH E COPYRIGHT HOLD ER O R HOLDE RS IN CLUDEDIN THIS NOTICE DO NOT WA RRANT THAT THE FUNCTION S CONTAINED IN THE INTELLE CTUAL PROPERTY WILLMEET YOUR REQUIREMENT S OR THAT THE OPERATION O F THE INTELL ECTUAL P ROPERTY WILL BE
UNINTERRUPTED O R ERROR FREE. ANY U SE O F THE INTELLE CTUAL PROPE RTY SHAL L BE MADE ENTIRELY AT
THE USE R’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT H O LDER O R ANY CONTRI BUTOR O F
INTELLECTUAL PROPE RTY RIGHT S TO THE INTELL ECTUAL P ROPERTY BE LIABLE FO R ANY CLAIM, OR ANY
DIRECT, SPECIAL, INDIRE CT O R CON SEQUENTIAL DA MAGES, OR ANY DA MAGE S WHATSOEVE R RESUL TING
FRO M ANY ALLEGED IN FRINGE MENT OR A NY LOSS O F USE, DATA OR PROFIT S, WHETHE R IN AN ACTION O F
CONTRA CT, NEGLIGEN CE OR UNDER ANY O THER LEGA L THEORY, ARI SING OUT OF O R IN CONN ECTION WITH
THE IMPLEMENTATION, U SE, CO MME RCIALIZATION O R PERFORMANCE O F THI S INTELLECTUAL PROPERTY.
This license is effective until terminated. You may terminate it at any time by destroy ing the Intellectual Property together with all
copies in any form. The license will also terminate if y ou fail to comply with any term or condition of this Agreement. Excep t as
provided in the follow ing sentence, no s uch termination of this license shall require the termination of any third party end-user
sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In add itio n, sho uld t he Intellectual
Property , or the operation of the Intellectual Property , infringe, or in LICEN SOR’s s ole opinion be likely to infringe, any patent,
copy right, trademark or other right of a th ird party , y ou agree that LICENSO R, in its sole discretion, may terminate this lic ense
without any compensation or liability to y ou, y our licensees or any other party . You agree upon termination of any kind to destroy orcause to be destroy ed the Intellectual Property together with all copies in any form, whether held by y ou or by any third par ty .
Except as contained in this notice, the name of LICENSO R or of any other holder of a copy right in all or part of the Intellec tual
Property shall not be used in advertising or o therwise to promote the sale, use or other dealing s in this In tellectual Prope rty without
prior written author ization of LICEN SO R or such copy right ho lder. LICEN SOR is and s hall at all times be the sole entity that may
authorize y ou or any third party to use certification marks, trademarks or other special desig nations to indicate c ompliance with any
LICENSO R standards or specifications. T his Agreement is governed by the laws of the Commonwealth of Massachusetts. The
application to this Agreement of the United Natio ns Convention on Contracts for the In ternational Sale of Goods is her eby expressly
excluded. In the event any provision of this A greement shall be deemed unenforceable, void or invalid, such prov isio n shall b e
modified so as to ma ke it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No
decision, action or inaction by LICEN SOR shall be con strued to be a waiver of any rights or remedies available to it.

2

Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2

Outline1.

INTRO DUCING ANNOTATIO N ........................................................................................ 11
1.1 Why semantic annot ations ................................................................................................... 13
1.2 Different perspectives on annotations .................................................................................... 15
1.3 Semantics of the Reference.................................................................................................. 16
1.4 Ontologies as Formali zed Knowledge ................................................................................... 18
1.5 Applications ...................................................................................................................... 22
1.5.1 Geographic Inf ormation dis cover y and retri eval .............................................................. 23
1.5.2 Geographic Inf ormation validation ................................................................................ 24
1.5.3 Validation of Servi ce Workflows .................................................................................... 24
1.5.4 Semanti cally supported int egration of geospatial data sets ................................................ 24

2.

SEMANTIC ANNOT ATIONS AT THREE DIFFE RENT LEVELS ....................................... 25
2.1 Implications for geospatial applications ................................................................................. 26
2.1.1 Level 1 - Ser vice Metadat a ............................................................................................ 26
2.1.2 Level 2 - Data Models .................................................................................................. 28
2.1.3 Level 2 - Geospatial Processes ...................................................................................... 29
2.1.4 Level 3 - Data Entiti es .................................................................................................. 30
2.2 Technical realization of the individual levels .......................................................................... 31
2.2.1 Level 1 - Ser vice Metadat a ............................................................................................ 31
2.2.2 Level 2 - Data Models .................................................................................................. 32
2.2.3 Level 2 - Geospatial Processes ...................................................................................... 35
2.2.4 Level 3 - Data Entiti es .................................................................................................. 36
2.3 Comparing the capabilities of the three approaches ................................................................. 36

3.

IMPLI CATIO NS FOR EXISTI NG GIS STANDARDS ......................................................... 37
3.1 Expressing sem antic annot ations .......................................................................................... 37
3.2 Metadata st andards ............................................................................................................. 38
3.2.1 ISO 19115 & 19119 ..................................................................................................... 38
3.2.2 OWS Capabilities ........................................................................................................ 41
3.2.3 WMS Capabilities ........................................................................................................ 42
3.2.4 ebXML ....................................................................................................................... 43
3.3 Data repres ent ation standards ............................................................................................... 44
3.3.1 GML Schema .............................................................................................................. 44
3.3.2 GML instances ............................................................................................................ 45
3.3.3 SensorML ................................................................................................................... 46
3.3.4 KML .......................................................................................................................... 48
3.3.5 Contexts ..................................................................................................................... 49
Future Cont ext specifi cation ................................................................................................. 49
3.4 OGC Filters ....................................................................................................................... 50
3.4.1 The ClassifiedAs-Operator ............................................................................................ 50
3.4.2 Usage ........................................................................................................................ 51

4.

SUMMARY ........................................................................................................................ 52

5.

REFERE NCES AND FURTHE R READINGS ...................................................................... 53

APPE NDI X A - GLOSSARY ...................................................................................................... 54

Copyright © 2012 Open Geospatial Consortium.

3

OGC 08-167r2
APPE NDI X B - SEMANTIC ANNOT ATIONS IN A NUTSHELL ................................................ 55
APPE NDI X C – SUMMARY OF ANNOT ATED (META)DATA STANDARDS ............................ 58

4

Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2

FiguresFigure 1 - Excerpt from an OGC WFS Capabilities document ......................................................12
Figure 2 - The data model for the WFS o f Figure 1. ....................................................................13
Figure 3 - Semantic annotations at three different levels...........................................................16
Figure 4 - Two types o f re ferences.............................................................................................17
Figure 5 - Application Ontology encoded in OWL .......................................................................20
Figure 6 - Application Ontology encoded in WSML ....................................................................20
Figure 7 - OTEG Thesaurus encoded in SKOS ..............................................................................21
Figure 8 - Ontology Architecture................................................................................................22
Figure 9 - Annotations as part of the resource metadata ...........................................................27
Figure 10 - Referencing elements in the data model to domain ontologies ................................28
Figure 11 - Using references to identify relevant elements in the data model ............................29
Figure 12 - Elements for the Annotation of Processes................................................................30
Figure 13- Result of the translation from data model to Resource Ontology (using the developed
visualization tool). .....................................................................................................................32
Figure 14 - Using Data type Ontologies for flexible annotations. ................................................32
Figure 15 - Result of the translation from data model to Resource Ontology (using thedeveloped visualization tool).....................................................................................................33
Figure 16 - Annotation of the feature type exploitationsponctualsproduction(using the developed visualization tool).....................................................................................34

Copyright © 2012 Open Geospatial Consortium.

5OGC 08-167r2

LISTINGS
Listing 1 - Example o f W SML annotation using the Resource Ontology ......................................35
Listing 3 - ISO 19139 Structure...................................................................................................39
Listing 4 - Unique Identifiers......................................................................................................39
Listing 5 - Concrete Example of ISO 19139 Structure ..................................................................40
Listing 6 - Concrete Example of ISO 19139 Structure..................................................................40
Listing 7 - Annotation of the GetCapabilities -Document ............................................................41
Listing 8 - Metadata Annotation for WMS .................................................................................42
Listing 9 - Using the MetadataURL for the feature types in a WFS ..............................................43
Listing 10 - Applying SAWSDL to GML Schema ...........................................................................45
Listing 11 - Applying SAWSDL to GML-encoded Data Entities .....................................................45
Listing 12 - A stronger-typed solution for applying SAWSDL .......................................................46
Listing 14 - Semantic Annotations in KML ..................................................................................48
Listing 15 - Semantic Annotations in a Context docume nt .........................................................49
Listing 16 - Semantic Annotations in an Atom-based Context document....................................49
Listing 17 - How to apply the ClassifiedAs Operator ...................................................................50
Listing 18 - Example for ClassifiedAs Operator ..........................................................................51
Listing 19 - Using the modelReference in a WFS query ...............................................................52

6

Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2

i. Abstract
In this OGC Best Practice, the concept of semantic annot ations is introduced. Annotation of
Web Services or data compliant to OGC standards refers to th e task of attaching meaningfuldescriptions to the service and the served geospatial data or processes.

ii. Keywords
ogcdoc, semantic, annotations, metadataiii. Preface
Annotation of Web Services or data compliant to OGC standards refers to the task of attaching
meaningful descriptions to the service and the served geospatial data or processes. T his Best
Practice extends the expressiveness of such annotations by includin g more sophisticated(semantic) descriptions. Semantic annotations can be applied on different levels (metadata, data
model, and instance data). T his Best Practice investigates implications on typical applications on
all three levels, and discusse s how they can be technically realized.
T he first section introduces semantic annotations, mentions the three levels, and elaborates on
semantic problems, which are evident in contemporary spatial data infrastructures. Such semantic
conflicts are resolved if the proposed semantic annotations are incorporated by query processing
routines in information retrieval (IR) systems like OGC Catalogs. T his BP also discusses typicalapplications where semantic annotations can facilitate the use of OGC Web Services.
T he second section provides a detailed discussion of the three different levels and relates themto standardization efforts of ISO/T C211. Implications on the find-ability of geospatial resources
and their evaluation due to the additional reasoner support are discussed for each level. Potential
benefits as well as the drawbacks are included. T he technical realization of the different
approaches are discussed and compared as well.
In the next section we discuss the implications for existing GI S standards like GML an d KML,
which are mostly from the OGC community. But also other standards like I SO 19115 and 19119
are included. Examples how to realize the semantic annotations for the different standards arelisted.
T his Best Practice concludes with a comparison of each approach, and with some suggestions
when to use which method.

Copyright © 2012 Open Geospatial Consortium.

7

OGC 08-167r2

iv. Document terms and definitions
T his OGC Best Practice paper includes the following abbreviated terms:


OGC

Open Geospatial Consortium

OWS

OGC Web Services

v. Normative References

OGC® Standard : Web Service Commons (WS-Common)
URL: http://www.opengeo spatial.org/standards/commonOGC® Standard : OGC® KML ( KML)
URL: http://www.opengeo spatial.org/standards/kml

OGC® Standard : Geography Markup Language (GML)
URL: http://www.opengeo spatial.org/standards/gm lOGC® Standard : Sensor Model Language (SensorML)
URL: http://www.opengeo spatial.org/standards/sensorml

OGC® Standard : Web Feature Service (W FS)
URL: http://www.opengeo spatial.org/standards/wfs

OGC® Standard : Web Processing Service (WPS)
URL: http://www.opengeo spatial.org/standards/wps

OGC® Standard : Web Coverage Service (WCS)
URL: http://www.opengeo spatial.org/standards/wcs

OGC® Standard : Web Map Service (WMS)
URL: http://www.opengeo spatial.org/standards/wms

OGC® Standard : Catalogue Service (CAT)URL: http://www.opengeospatial.org/standards/catOGC® Standard : Filter Encoding (FES)
URL: http://www.opengeo spatial.org/standards/filter

ISO/IEC 13211: Prologue

ISO/IEC 13250: Topic Maps
URL: http://www1.y12.doe.gov/capabilities/sgml/sc34/document/0322.htm



ISO 19109: Geographic information : Rules for application schemaISO 19119:2005: Geographic information -- Services

ISO 19115:2003: Geographic information -- Metadata

ISO/TS 19139:2007: Geographic information - Metadata - XML schema implementation



W3 C® Recommendation: OWL Web Ontology Language
URL: http://www. w3.org/T R/owl-features/

8

Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2


W3 C® Recommendation: Semantic Annotations for WSDL and XML Schema ( SAWSDL),
URL: http://www. w3.org/T R/sawsdl/



W3 C® Member Submission: SWRL: A Semantic Web Rule Language
Combining OWL and RuleML, URL: http://www. w3.org/Submission/SW RL/

W3 C® Member Submission: Web Service Modeling Ontology (WSMO)
URL: http://www. w3.org/Subm ission/WSMO/

IETF® RFC: Uniform Resource Identifier (URI): Generic Syntax
URL: http://tools.ietf.org/html/rfc3986

Copyright © 2012 Open Geospatial Consortium.

9OGC 08-167r2

vi. Document contributor contact points
All questions regar ding this document should be directed to the editor or the contributors:
Name

Organiza tion

Patrick Ma ué

IFGI, Unive rsity of Münste r, Germa ny

Sven Scha de

IFGI, Unive rsity of Münste r, Germa ny

Philippe Duches ne

Erdas, Belg iumvii. Revision History
Date

Release

EditorPrimary cla uses
modified

Descr iption

11/07/08

0.0.1

Patrick Ma ué

Initia l ve rsion

01/05/09

0.0.3

Carl Reed

Various

For publication as DP

07/15/09

1.0

Patrick Ma ué,

VariousForma tting , Rela tion
to ISO, Upda tes to
Section 3,
Cla rifications

VariousUpdates on
integra tion with GIS
standa rds

Sven Scha de

06/10/11

2.0

Philippe Duches neviii. Changes to the OGC Abstract Specification
The OGC® Abstract Specification does not require changes to accommodate the technicalcontents of this document.

ix. Foreword
Attention is drawn to the possibility that some of the elements of this document may be the subjectof patent rights. The Open Geospatial Consortium shall not be held responsible fo r identifying
any or all such patent rights.
Recipients of this document are requested to submit, with their comments, notification of any
relevant patent claims or other intellectual property rights of which they m ay be aware that might
be infringed by any implementation of the standard set fo rth in this document, and to provide
supporting documentation.
10

Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2

Semantic annotations in OGC standards

1. Introducing annotation
T he World Wide Web is a vast collection of arbitrary resources, held together by standards thattell us how to locate and transport data. Such reso urces might be textual information on a Website but also can be images, a video, do wnload-able multi spectral satellite image, OGC Web
Feature Service providin g some vector data, or a Sensor Observation Service delivering up -todate temperature values. Without proper descriptions, the use of such a reso urce is limited to asmall user gro up. Before publishing a reso urce in the Web, it has to be annotated withdescriptive metadata to make it usable to a broad audience. Otherwise people will neither be able
to find the resource using search engines nor will they be able to evaluate if the discoveredresource satisfies their current information need.
T he OGC standar ds baseline provides accepted and well thought -out methods to make spatial
resources (data and processes) served via Web Services accessible. Service capabilities (seefigure 1 as example) describe, besides contextual information like contact information, how toaccess an d invoke the service to retrieve the required geo spatial data. T he individual name an dlocation of the operations are also listed in the Capabilities document of each OGC-conformal
Web Service (as defined in OGC W S-Common). Since such operations and the format to encode
the data are predefined in OGC Implementation Standards and OGC Encoding Standards, genericclients can, without knowledge abo ut the nature of the data, display the resulting data on a map.
In this OGC Best Practice, we introduce the notion of semantic annotation. With the help of
the OGC Capabilities-Document and the various individual descriptions of feature types,
coverages, or processes, the standards of the OGC define how to access, invoke, and finallyvisualize spatial data. T he OGC standards cover the functional dimension of a Web Services. But
they lack a well-defined methodology to describe the thematic dimension of a Web Service. T hey
don’t tell much about what the served data (or process) represents, and in particular they lack a
way to link the resources to external models. For example, the application knows ho w to load andvisualize the data on a map, but the user has no idea how to read the displayed map. With the h elpof semantic annotations, data providers will be able to connect the standardized service
descriptions to the modeled knowledge. Such models comprise conceptualized knowledge abo ut
the represented geographic phenomena. Having such a link established, reasoning algorithms will
be able to infer if a Web Service matches an agent's query on the formal level. In addition it willallow for extracting valuable contextual information from the knowledge models, making it
possible to display thematic information for the displayed data and helping the user to understand.
T he in depth discussion of applications for semantic annotations in the context of OGC
Standar ds can be considered to be the main contribution of this Best Practice. T he concept of
three different levels where annotations can be applied has been developed for this Best Practice
paper. Additionally, this is the first time we discuss the semantics of the reference, and justify the
Copyright © 2012 Open Geospatial Consortium.

11

OGC 08-167r2
distinction between model references an d domain references. T his Best Practice paper does notsuggest introducing new standards. We rather propose to extend the notion of already existing
OGC standar ds an d to apply standards from other organizations like the W3C to OGC Standards.
In the remainder of this section we are going to discuss which different levels for annotating
OWS descriptions exist, why Semantics are needed in the annotation process, and what types ofapplications and scenarios can benefit from includin g knowledge model references in the
annotation process. We use semantic discovery as main motivation, but include pointers toadditional usage scenarios.
Figure 1 shows the metadata available for a WFS serving one feature type with the nameexploitationsponctualsproduction . T he example will be used throughout this Best

Practice paper to illustrate why semantic annotations are needed, an d ho w they should be
realized. T his example, an d accordingly the service providin g the associated data 1 , has beendeveloped within the European funded project SWING 2 . T he methods have been also studied
durin g research for the German funded project GDI Grid 3 .

Figure 1 - Ex cerpt fr om an OGC WFS Ca pa bilities document1

Link to this particular WFS: http ://swing.brgm.fr/d ataacc ess/wmswfs.

2

Link to the official Web sit e: h ttp://www.swin g-project.org/.

3

Link to the official Web sit e: h ttp://www.gdi- grid.d e

12

Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2

Figure 2 - T he da ta model for the WFS of Fig ure 1.

Figure 2 lists the GML schema for the exploitationsponctualsproduction feature type.
But what does its data represent? T he name is already confusing; the attributes don't give us any
additional information. Whose name is the value of name, what does the attribute year refer to,and how is the allowedproduction measured?

1.1 Why semantic annotations
Before going into the technical details about semantic annotations, we need to discuss sometheoretical background of semantics, in particular how semantics can inc rease the usefulness of
geospatial information. We introduce the different types of semantic conflicts and the notion ofsemantic interoperability, the idea of conceptualization to resolve these conflicts, and the use offormal languages to specify such conceptualizations.
T he major goals of standards like XML or GML is to achieve syntactic and structuralinteroperability between different software components4 . If two agents agree on ho w to represent

4

How the OGC defin es int eroperabil ity: http://www.op engeosp atial .org/ogc /faq /openn ess (#10)

Copyright © 2012 Open Geospatial Consortium.

13

OGC 08-167r2
and communicate the data, a seamless and conflict -free integration is established. Hence,
semantic interoperability can be achieved if the two agents (both, humans and machines) agree on
how to understand the data. The level of understanding can differ and depends mostly on thecomplexity of the formalized knowledge. T he followin g listing discusses common conflicts (orheterogeneities) which can be addressed using conceptualizations on the domain level and thesemantic annotations to relate OWS to these domain concepts.
Application-specific knowledge: T he feature type modeled in figure 2 sho ws an example forproblems that are caused by application -specific knowledge. Fir st, certain identifiers or terms
are used in a small community, which makes the underlying data hardly usable for otheruser s.
T hecasualuser
does
obvio usly
not
know
what
an
exploitationsponctualproduction represents, and he would fail to discover the data
even if would provide the required search terms. T he attribute allowedproduction
remains unclear to the user as well. It refers to the maximum allowed production of the
product (gravel, chalk, …) in tons per year. The attribute year is in this case the year thisallowed production is meant for. Without a further description which is shared to the otherparties, the use of this data is constrained to a very limited user group. Having elaborated
semantic descriptions linked to these attributes and feature types provides a solution to thisproblem.
Hierarchical Problems: Probably the most common issue in service discovery is thedifferent level of expertise between the seeking user and the data provider. A casual user
looking for excavations is obviously taking the term “excavation ” or “mine”. T he specialist
publishing the data is usin g more specific terms, like “quarry” (an open -pit mine) or“chalkpit” (a quarry use to excavate chalk). Searching based only on keywords would yieldno results here. Since one term is more specific then another (we refer to it as a hypernym 5 ),they can be simply associated on the conceptual level using taxonomic relatio nships. T hedomain concept QUARRY is then simply modeled as sub-concept of the domain concept
EXCA VATION .
Multilingual community: Yet often neglected in the Anglo-centric GI S community, thedifferent languages spoken by users impair the find-ability of spatial resources as well.
Especially in the European region the requirement for multilingual descriptions of geo spatial
data gains importance. Concepts at the domain level support labels in different languages,
which makes it possible to match a user's query and service description even if the chosen
languages differ. T his approach assumes that terms in different languages can be refer red toexactly the same concept. But the German term “Steinbruch” does not necessarily bear thesame meaning as the American English term “Quarry” or the British English term “stone pit”.
Depending on the required complexity of the knowledge, lan guage - specific concepts mightneed to be introduced as well.
T ypical semantic problems result from the ambiguity of human language. Individual language
depends greatly on the backgroun d kno wledge, which is influenced by society, culture,
5

From th e Wo rdNet Glossary (http://wo rdnet .princeton.edu /man/wngloss.7WN) : Hyp erny m is “Th e genericterm used to d esignate a whole c lass of specific instanc es. Y is a h ypern ym of X if X is a (kind of) Y. “

14

Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2
profession, and much more. If data should not be restricted to a user community speaking, bychance, the same language as the data provider, we need to solve the following semantic
heterogeneities:
Synonymy: One term is a synonym of another different word, if they both denote the sa me
object. A synonym for the word “quarry” is, for example, the “open -pit mine”. On theconceptual level, we wo uld identify the concepts QUARRY an d OP EN P ITMINE , as similar. A
reasoning algorithm is then able to infer that a user searching for “quarry” is, in the same
moment, also looking for a “open pit mine”. T he user doesn't even have to realize that thequery has be redefined, since all additional results are as relevant as the others.
Homonymy: T ypical representatives of semantic heterogeneities are also homonyms. One
wor d has multiple meanings, and only the context makes it understandable to the reader.
“Mine”, for example, is defined either as excavation in the earth 6 or as explosive device that
explodes on contact. It can in both cases also be used as verb. On the conceptual level suchterms are only used to label a concept. It is therefore quite simple to distinguish bet ween
homonyms. The words look equal, but they are linked to different concepts.
Polysemy: T ypical semantic problems in geospatial applications are result of the ambiguityof place names (also called toponyms). Like homonyms, a polysem is described as a wor dwhich can be under stood differently depending on contextual information. But in this casethe denoted objects (and therefore also the concepts on the domain level) are similar. A
toponym is very often also a polysem. Examples are “do wntown”, “Main Street”, or evennames of cities like “ Springfield” 7 . Since something like “do wntown” stays conceptually thesame, even if it there is a large spatial distance in space, it cannot be fully covered by formal
domain concepts on the domain level. Annotations of the individual data entities, on theother hand, might help.

1.2 Different perspectives on annotations
Semantic annotations establish a connection between the geospatial resource, its metadata, andthe ontology. T he following figure 3 illustrates the three different levels of (semantic) annotations
which are possible for OGC Web Services, taking the WFS from Figure1 as example.

6

We are using th e wo rdnet d efinitions h ere.

7

Wikip edia cl ai ms that th ere are 34 Sp ringfi elds in the US

Copyright © 2012 Open Geospatial Consortium.

15

OGC 08-167r2

Figure 3 - Sema ntic annota tions a t three different levels

It is possible to distinguish between three locations where particular information about theresource can be acquired. T he Capabilities-document defined in OW S- Common comprises
functional properties telling the user how to access and invoke the service, as well as someresource metadata with information about the service provider, licensing, a title and description,
or a keywor d section (Figure 1). An additional document provided by every OW S is a XML based schema representing the data model (figure 2), which comprises a description of the data
model with focus on syntax and structure. Both documents, the metadata and the schema, aredescribin g the un derlying data, and therefore explicitly linked (highlighted by the orange arro w).
T he third source of information are obviously the data entities itself, encoded in the format
predefined in the data model specified in the data schema.
A reference (the numbered arro ws in the figure) to a knowledge model is feasible on all threelevels. In figure 3, a WFS which serves quarry features ( with allowedproduction as one
attribute) is semantically annotated. We can directly link (1) a keyword within the CapabilitiesDocument to the corresponding concept in the domain ontology. We can annotate (2) the data
model (the features and the attributes) usin g an application -specific ontology. Or we attach (3)semantic annotations directly to the feature instances. Each type of annotation has different
implications on the find-ability of the Web Service, and the possibility of the user to evaluate if
the served data satisfies his needs. T he different levels with benefits and draw backs are discussed
in detail later on.

1.3 Semantics of the Reference
T he link between elements in a XML document and concepts from a shared vocabulary encodedin another format is coined the model reference (introduced in the W3C Standards SAW SDL). Its
16

Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2
purpose is to bridge different languages, and is alway s a link between t wo models (e. g. XML
Schema or UML modeling data, RDF modeling a domain vocabulary, and so on).
T he domain reference, on the other hand, links between a local, application -specific modeland a glo bal, shared vocabulary. Whereas the model reference is a unique URI which points tothe corresponding element in another model, the domain reference can be also expressed in formof complex rules. Here, n-ary links are required to accommodate for the complex relationshipbetween application-specific features and common domain knowledge.
T he following figure sho ws how these references relate. Note that the two types of references
can overlap. In many cases a domain reference is in the same time also a model reference, since
the reference performs both tasks (bridgin g in bet ween two languages an d linking from local to
global). In this case, the domain reference should be used.

Figure 4 - T wo types of references

T he figure above represents a level 2 annotation: a data model (the feature type schema) is linked
to the resource ontology via the model reference link, which again is linked to the domain
ontology with the domain reference. If the features itself are to be anno tated (e.g. placemarks in a
KML file), we should use the domain reference if we link directly to a shared vocabulary, such asa gazetteer.
T he distinction between two reference types (and the introduction of the resource ontology)
adds an additional layer of complexity, but has also several benefits which in our opinion are
crucial for the applications introduced later. Using only domain refe rences (linking directly todomain vocabularies) for level 1 and level 2 annotations results in either too application -specificdomain models or too generic annotations. T ake for example the attribute name from the feature
type example in Figure 2. Either it is linked to the concept IDENTIFIER, which means we lose theinformation what entity is identified with its value. Or we link it to the concept QUARRY NAME ,which means we have to update the domain vocabulary for data models with complex
relationships; the latter results in cluttered vocabularies barely usable for tasks like semantic
Copyright © 2012 Open Geospatial Consortium.

17

OGC 08-167r2
integration. With a resource ontology, we can model the implicit relationships between the
different data feature attributes and the feature itself. On a local level we model that the name isthe name of the quarry, or that the value of the year refers to the year where the value of theallowed production rate is valid.

1.4 Ontologies as Formalized Knowledge
Up to now we always referred to conceptualizations on the domain level, and avoided the term
ontology. Analogue to Gruber's definition (Gr uber, 1995) for ontologies, we see an ontology as
particular specification of a conceptualization. They are not necessarily needed to solve every
potential semantic problem listed in Section. Different levels of hierarchies are, for example, also
resolved usin g thesauri like GE MET 8 from the European Environmental Agency (EEA) or
AGROVOC from FAO 9 , which serve synonyms and hypernyms for a defined collection of terms.
But the proposed solution should cover all introduced challenges resulting from semantic
heterogeneities. Dictionaries, controlled vocabularies and even taxonomies can be considered asless formal, less expressive, and therefore less powerf ul conceptualiza tions of domain knowledge.
Ontologies and the underlying formal systems have the required expressiveness to formalize theconceptualizations and rules required to avoid the listed semantic conflicts. Note though, that thementioned domain-specific thesauri represent the vocabulary commonly accepted within theinformation community. Engineering domain ontologies representing a certain domain’s
vocabulary should therefore always take common and well-accepted thesauri as starting point. Or,even better, the authorities controlling the thesauri also create the ontologies (in the case of
AGROVOC).
T he Ontology Definition Metamodel (ODM) 10 , which is built on top of OMG's Model Driven
Architecture (MDA), identifies four main components used to specify (and formaliz e) a
conceptualization: relations, individuals, axioms, an d the concepts used to define the vocabulary.
T his is a rather light -weight view on ontologies, but nonetheless allo ws for explaining the maindifference to a less flexible knowledge base like a thesaur us. T he ontology's axioms can be used
to constrain the relationship between concepts, or to create new knowledge in the form of rules.
Having these complex concept definitions (concept, its relations, the axioms constraining therelations, and the individuals of this concept) expressed in a language based on a formal
deductive system like first -order logic or description logic enables the use of reasoning
algorithms. Inference can be as simple as creating new facts from transitive relations, but also as
complex as matching complex logical statements usin g techniques like Query Containment(Calvanese, 1998). It depends on the required expressiveness which kind of logic language isselected. But the more expressive the underlying language, the less decidab le are the expressedstatements. A reasoning algorithm which has to compute a potential match between services
described usin g ontologies based on first -order logic requires more resources (in terms of time

8

Example of EEA: http://glossary .eea.europa.eu /terminolo gy /concept _html ?t erm=quarry

9

Find more information h er: http://www.f ao.org/agrovoc /1018

Ontology Sub group of OMG: http://onto logy.o mg.org/

Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2
and computing po wer) compared to ontologies used in a less expressive description logic(Baader, 2003).
In this Best Practice we discuss semantic annotations of existing OGC standar ds. We try to
focus on the extensions in the existing service description documents, but nonetheless we have to
introduce t he standards used to express the conceptualization on the domain level. A wide variety
of different languages and supporting tools is available, rangin g from the very simple Topic Maps
(ISO/IE C 13250) to complex descriptions in logic programming lan guages like Prolog (I SO/IE C
13211). We focus on three examples which are commonly used today and which have gained
tremendous support in the rise of the Semantic Web.
T he most common language is the RDF- based Web Ontology Language (O WL), which hasreached the status of a W3C Recommendation. T he most frequently OWL variant (OWL-DL) isbased on Description Logic (DL), which constrains its expressiveness an d therefore applicability.
But the decidability, good support, and wide availability of tools makes it the first choice for the
majority of applications. OWL2 11 introduced the possibility to create profiles, with different
supported reasoning capabilities in mind. OWL can be bundled with even more expressive rule
languages like the Semantic Web Rule Language ( SW RL). Rules can lead to un decidable
statements in the ontologies, but still contribute significantly to the expressiveness of OWL.
T he Web Service Modeling O ntology (WSMO ) was developed to account for therequirements of finding and composin g Web Services. T he used language, the Web Service
Modelin g Language (W SML), comes in different flavours. Like OWL -DL, WSML-DL isconstrained to the language constructs allowed for a Description Logic. But with WSML -Flightand WSML-Rule, two flexible lan guages are available wh ich allow for expressing even moresophisticated conceptualization. A thorough introduction in WSML is available in the W3C
submission.
T he Simple Knowledge O rganization System (SKOS) is a formal language designed for
representation of thesauri, classification schemes, taxonomies or any other type of structured
controlled vocabulary. SKOS is built upon RDF and RDFS, is simpler than OWL, and focuses on
the easy publication of controlled structured vocabularies. Because it is based on RDF, SKOS
entities can be integrated in OWL constructs. It must be noted that SKOS concepts are not OWLclasses (they are instances thereof) and therefore cannot be used as instantiable classes, nor haveclass properties. SKOS has reached the status of W3C Recommendation.
T he following two figures 4 and 5 show how the application ontology from figure 3 on page
12 would be encoded in OWL and W SML. (T he SKOS example is detailed later) Sentences in
OWL are represented as triples, because it has been modeled as extension to RDF and RD F( S).
T he WSML code has a RDF representation as well, but can also be serialized (and later again
parsed) using an human-readable form like in figure 5. In the W SML example cardinalities havebeen added to the attributes. In this case the attribute msGeometry is mandatory, because it has a
cardinality of exactly 1. All other attributes can be either present or not.

11

More about profiling for OWL : http://www.w3.org/TR/o wl2 -profil es/

Copyright © 2012 Open Geospatial Consortium.

19

OGC 08-167r2

Figure 5 - Applica tion O ntology encoded in O WL

Figure 6 - Applica tion O ntology encoded in WSML

Because SKOS concepts are not classes, as stated above, they cannot hold class-level properties
as in the examples above. SKOS concepts are meant to hold static entities that form a controlled
vocabulary. Belo w is a possible SKOS enco ding of the OT EG thesaurus :20

Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2<rdf:RDF
xmlns="http://oteg.esa.int/infodomain-v1.0.owl#"
xmlns:rdf= "http://www.w3.org/1999/02/22-rdf-syntax -ns#"
xmlns:skos ='http://www.w3.org/2004/02/skos/core#'><skos:ConceptScheme rdf:about="http://oteg.esa.int/infodomainv1.0.owl"/><skos:Concept rdf:about="#Land_monitoring"><skos:broader rdf:resource="#Information_Domain"/></skos:Concept><skos:Concept rdf:about="#Agriculture"><skos:broader rdf:resource="#Land_monitoring"/></skos:Concept><skos:Concept rdf:about="#Cloud" ><skos:broader rdf:resource="#Agriculture"/><skos:broader rdf:resource="#Meteorological_data"/></skos:Concept><skos:Concept rdf:about="#Meteorological_data"><skos:broader rdf:resource ="#Wave_climate"/><skos:broader rdf:resource="#Operational_oceanography"/><skos:broader rdf:resource="#Weather"/></skos:Concept>[...]</rdf:RDF>
Figure 7 - O TEG Thesaur us encoded in S KOS

An ontology architecture provides an high -level view on the various types of ontologies, and ho w
they are related to each other. T here are two types of distinctions which will be used through -out
this Best Practice.
Local vs. global: Local ontologies are used in a particular application, and are not shared or
publicly available. Global ontologies, on the other hand, are available to everyone, and should
therefor not contain individual kno wledge. Concepts in local ontologies have to be linked to
global concepts to make them useful, for example, to let the reasoner decide if t wo local concepts
are denoting the same thing.
Application, Domain, and Foundational Ontologies: Local ontologies as mentioned above
are usually coined application ontologies, in the fo llowin g we prefer to use Resource Ontology.
Such ontology comprises concepts used for a specific application, in our context the application is
the provision and use of geospatial resources in the WWW. A Resource Ontology might include,for example, concepts representing feature types and their attributes (see Figure 1) which aredefined in the feature type schema of a Web Feature Service. Domain Ontologies are shared an d
global conceptualizations which are used across different applications. A Foundational Ontology
Copyright © 2012 Open Geospatial Consortium.

21

OGC 08-167r2(also called Upper Level, T op Level, or Formal Ontology) sits on top of domain ontologies, andallows for bridging bet ween the different domains. T his level of ontologies is not yet fully
specified, an d requires more research before being usef ul for applications.

Figure 8 - O ntology Architecture

T he strict distinction between domain ontologies which try to capture the common knowledge of
one community, and the application-specific Resource Ontology which model s the very specificinner workings of a particular dataset or process is f undamental for the understanding of semantic
annotations. Information exchange requires commitment of all parties to the global kno wledge
modeled in the domain ontology. On the local level each participant can model the application
ontologies in a way which best suits his purpose. Forcing him to use domain concepts only will
result in loosing valuable application specific knowledge. Relating the local application
ontologies to global ontologies allo ws for keeping this local knowledge as well making the served
data findable for reasoner-supported IR systems. Such systems are no w able to infer that services
like the two illustrated in figure 6 do actually match because they serve related data and can beboth of interest for a discovery task using, for example, the concept QUARRY .
A slightly more complex reasoning scenario involves subsumption reasoning. The local
concept EXPLOITATION is related to the domain concept QUARRY , the other local concept
GRAVEL _ EXCAV is associated with the domain concept INDUSTRY . Since Quarry is modeled as
being a sub-concept of I NDUSTRY , the reasoning engine is able to infer the both local concepts are
related (they are not similar, though).

1.5 Applications
We claim that semantic annotations can increase the usefulness of OGC Web Services in nearly
many scenarios they can be deployed in. Four typical applications are discussed in detail belo w.
22

Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2
T hey are subject of interest for two research projects the authors are involved with. In theGerman GDI- Grid project we studied way s how to semantically validate GRID-enabled
workflo w. And in the European funded SWING project the applicability of Semantic Web
T echnologies in the context of geospatial decision making in th e mining industry has been
discussed.

1.5.1 Geographic Information discovery and retrieval
Due to the complex nature of Geographic Information, the discovery of such data is significantly
more challenging then searching, for example, a Web site using a keyword- based search engine.
Spatial data comprise several search-able dimensions: Space, T ime, and Theme. OGC Standards
like Filter Encoding have addressed the spatial dimension sufficiently, and even temporalcharacteristics of spatial data can be simply queried usin g a well-defined temporal reference
system like the Calendar. T he thematic dimension on the other hand is restricted to string-based
filters, which neglects the semantic problem s introduced in section 1.1 and makes the discovery
of geographic resources representing a specific phenomena a tedious task.
We argue that GIR using semantic-enabled catalogs can improve user experience andusef ulness of such IR systems significantly. Letting users specify not only keywords, but relating
their queries to conceptualized domain knowledge using the proposed annotation approach will
enable reasonin g algorithms (a) to expand the user queries, (b) to increase the number of relevant
records in the repository, and (c) to return a more precise result set in the end. Hence, semantic
descriptions can be used to increase recall, i.e. discovering all services which fit the user
requirements, and precision, i.e. includin g only relevant service in the result set.
Discovery of semantically annotated processing components with focus on operations iscomplex, and requires more sophisticated reasoning capabilities. Here, various kinds of matches
have to be applied. T he classical approach, the exact match, has to be separated from thepredicate match, plug-in match, and an extended plug-in match (Zaremski 1996, Lutz 2006).
Predicated matches compare requested process descriptions with the pre- and post-conditionsof the advertised services in one matchmaking step. Predicate matches are especially useful for
simple queries such as "give me all services that compute overlay". T he predicate match fails if arequested precondition is more specific/restrictive then the precondition offered by some Web
Service, although the Web Service could execute on the input provided by the requester. Hence,these matches may decrease recall, that is: some WPSs that provide the requested f unctionality
are possibly not retrieved. If the provided precondition is more specific then the requested one,predicate match succeeds although an acceptable input cannot be guaranteed. Hence, this match
possibly decreases precision, that is: some WPSs that are retrieved are possibly not able to fulfill
the requested functionality.
T he more sophisticated Plug-In Match compares the pre-conditions and post -conditions
separately. T his avoids the drawback s from the predicate matches. It is still impossible toconsider dependencies bet ween inputs and outputs using t his type of match. Having two polygons(A and B) as inputs, it is impossible to identify if it is difference (A – B) or (B - A). T his type ofmatch is not aware of possible permutations of the input variables. Since this can possibly deliver
wrong results, it may decrease precision as well.
23
Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2
For a non-relaxed match, i.e. a match with high precision and high recall, the Extended PlugIn Match was developed. T his algorithm is able to incorporate all the elements of a processdescription. But due to its complexity and the dependency on expressive ontology languages, it isvery resource intensive and not (yet) applicable for large -scale applications. SWING D3.2
(Schade et al, 2006) contains more information on possible implementations using W SML -Flight,
an ontology language variant based on logic programming.

1.5.2 Geographic Information validation
Once Geographic Information has been discovered, the agent (user or machine) has to evaluate if
the available spatial dataset matches the user requirements. Several aspects play an important role
here, and not many have been investigated sufficiently (like Service Level Agreements, Qualityof Service parameters, License issues, Security, ..). T he use of ontologies to describe specificaspects of a Web Service, or the served data, is a flexible and easily extensible approach.
T echnologies like RDF which are used to encode ontologies account for the dynamics of themodeled kno wledge. T hey can easily be extended with additional (non-ontological) information
without the need alter the underlying schemata. T he flexibility of reasoning algorithms doesn't
restrict metadata to specific content, they only reason on the relevant ontological subset of the
document.
T he evaluation of the thematic dimension of the spatial data is obviously improved as well.
Since we are not restricted to ambiguo us, error-prone and usually missing key words and textual
descriptions any more, it is now easier to evaluate what the discovered service represents.
Formalized concepts on the domain level are sophisticated descriptions, including label in
different languages, relationships to other concepts, and many more. Since these concepts are
encoded in ontologies, the extent of potential information about them is not constrained.

1.5.3 Validation of Service Workflows
If we consider Web Services as atomic components, which either serve or process geospatial data,
we also want to be able to compose more complex services by creating service workflows. Data
services like the WFS or WCS deliver geospatial data, which is then processed an d modified by a
WPS. T he output of the WPS could be again a Feature Collection, Coverage, or an image.
Depending on the resulting data, the whole service composition will be encapsulated again as
WPS, WFS, WCS, or WM S.
Creating the workflows is a matter of adding existing Web Services to the present composition
and, at the end, hand over the workflow document to a workflow engine. Since only OW S areused, syntactic interoperability of the service components can be assumed. GML is output of thedata services, and GML is the expected input of the processing services. Semanticinteroperability, on the other hand, can only be achieved if the used Web Services aresemantically annotated. Reasoners can match the outputs with the input of the subsequent service,
and are therefore able to validate if the workflo w not only syntactically, but also semanticallyvalid.

1.5.4 Semantically supported integration of geospatial data sets
24

Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2
Integrating spatial datasets in any form assumes that both datasets match in geometry, structureand semantics. Geometry simply refers to the spatial nature of the represented data; both datasets
are representing t he data in the same way, for example in form of points in the case of feature
types representing our quarries. Str ucturally matching feature types have either equal sets of
attributes, or routines which are used to translate between attributes. A syntactic al match isensured if the same standard, meaning the same version of GML, is used for encoding the data.
Such tasks don't consider the semantic dimension yet. T wo datasets may be compatible in theirgeometric, syntax and structure. But this doesn't imply that each attribute present in both feature
types with the same identifier has the same meaning. T he feature type of our example has theattribute allowedproduction, which is measured in tons per year. Another dataset my havethe same attribute, but its value refers to the allowed weekly production. Integrating the twodatasets wo uld clearly result in unusable data. Semantically annotated attributes and a validation
procedure, optionally supported by rules to translate from one value to another, will eithe r warn
the user in the case of semantically incompatible datasets, or use the rules to solve semantic
conflicts.
Integrating of specific spatial entities is also an interesting application for semantic
annotations on the instance level. If two spatially close entities are equally annotated, one caninfer that both refer to the same geographic object, which means they have to be integrated. As
example, two point features within a distance of less than 100 meters are related to the domain
concept QUARRY . It is reasonable to assume that both features refer to the same geographic
object, they can be combined to one feature. Rules formalized in the domain knowledge can
support such assumptions, and can be automatically applied either during the annotation of
instances, or during the integrating of datasets.

2. Semantic annotations at three different levels
Modellin g knowledge an d publishing it in a well-defined and machine interpretable format can
result in increased usability of OGC Web Services. We consider ontologies as most promisingformat to capture such knowledge. But the possibilities to connect onto logies with OGC services
are manifold. In this section we discuss ho w we can annotate OGC services on the alreadymentioned three levels:
1. the service metadata,
2. the data models and process descriptions, and3. the actual data instances in the database.
T he three annotations levels differ in their potential. T his is due to different reasoning
capabilities, i.e. the abilities to infer either new knowledge (making implicit knowledge explicit)
or to identify conflicts in existing models. Accordingly, the applications for semanticallysupported OW S discovery and workflo w validation vary. Requirements vary between projects,
the following comparison of the three levels with implications on reasoning and potential benefits
can therefore only outline possibilities.
Copyright © 2012 Open Geospatial Consortium.

25

OGC 08-167r2
Notably, although we illustrate semantic annotations in the OGC context, they can be similarly
defined in relation to ISO/T C211. In particular t he ISO General Feature Model ( GFM) describedin I SO 19109 and I SO 19115 (Metadata) has to be considered. In GFM, geo spatial data ismodelled as features and their properties and associations. Metadata can be associated for each ofthese elements.
Following our suggestion, a semantic annotation would either link instances of the GFM, i.e.
concrete feature types, feature attributes and feature operation, or their instances, i.e. concretefeature collections and their content to concepts of an ontology. T he first approach reflects level2, the second level 3. Level 1 annotation would relate to service metadata (ISO 19119 ).
In any case, a semantic annotation can be seen as a specific kind of metadata and should
therefore be considered as an official metadata element.

2.1 Implications for geospatial applications
Semantic annotations extend the already existing annotations like the OGC Capabilities document
by linking particular metadata elements to conceptualized domain knowledge. T hese links point
to one or more concepts, which are modelled usin g ontologies or the less formal taxonomies. T he
Quarries W FS from the example in figure 1 (p.8) can, for example, be annotated with the concept
QUARRY , MINE , and AGGREGATE . Sophisticated semantic annotations include axioms, i.e.
combinations of logic statements, which relate various domain concepts to each other in order toelaboratetheinternal
relationships
of
the
data.
T he
featuretype
exploitationponctualsproduction has, for example, the attributes allowedproduction
and year. With the help of axioms we are able to specify that allowedproduction ismeasured in T ons per Year, and that this Year is related to the other attribute year. We havesuccessf ully investigated such complex semantic annotations in the mentioned SWING project,detailed explanations are available in the deliverable 3.2 from the project web site (Schade et al,2008).

2.1.1 Level 1 - Service Metadata
Adding knowledge model references in one of the existing sections in the data and/or services
metadata (e.g. by extending the keyword section of OW S Capabilities) is the most pragmatic andstill useful approach to semantic annot ations. In our example, only limited information isavailable in the service metadata section (see Figure 1). T he name “MapServer WFS” isautomatically generated and bears no meaning, the title “Quarries” and the keywords “brgm,
quarries, quarry, france” provide an only very limited description of the served geospatial data.
Being able to semantically enrich metadata sections like the keywords makes under standing of
the intended meaning a reality.

26

Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2

Figure 9 - Annota tions as par t of the resource meta da ta

Keywor ds themselves might act as the model references. T hey can be direct links (orange“reference”-arrow in figure 7) to the concepts or axioms in the domain ontology. This approach
extends the notion of keywords to serve not humans only by becoming also interpretable bymachines. In addition to the keywords “quarry” “france” and “brgm”, we can add links toconcepts within a shared kno wledge model ( which can be as simple as a thesaurus or as complex
as domain ontology). T his model is then a conceptualization of the reality, the concept QUARRY
denotes real quarries.
T he main benefit of this approach is low implementation costs, since we only extend thenotion of existing metadata sections. But changing the purpose of this section to include model
references decreases their usef ulness in terms of readability for human users. T extual descriptions
are one major source of information for evaluating the served data. Having cryptic URIs insteadof terms does obviously not improve acceptance by the readers. In section 3.2.2 we list examples
how adding concept identifiers to existing metadata sections may look like. In sectio n 2.2.1 weintroduce the idea of visualization tools to improve the readability by human users.
Looking at the discussed applications for semantic annotations, the discovery and evaluationof geospatial data already benefits from this even very light -weight approach. But the
improvements just affect tasks concerned about the service metadata level. Replacing keywords
with model references cannot cover the complexity of the data served by an OGC Web Service,because no formal connection to the served data has been established. T he reasoning only works
on the service metadata level. As result the GIR system can only infer that a discovered service isin some way related to the domain concept. Unless the semantic annotations are not directly
applied to served resources, i.e. feature types, map layers, a searching user would not able to
Copyright © 2012 Open Geospatial Consortium.

27

OGC 08-167r2
identify the resource providing the needed information. In the case of WFS, he want s to know
which feature types serve the information associated with this domain concept. And within afeature type, he wants to identify which attributes bear the requested information. In the following
section we discuss semantic annotations directly attached to the resource, making it therefore
possible to overcome these problems and enablin g more sophisticated reasoning tasks.

2.1.2 Level 2 - Data Models
In order to relate service metadata more efficiently to domain knowledge, we need to take acloser look at the data models and the service operations. In this section we further discuss theannotation for data as it served by a WFS or a W CS. In the follo wing section we address
processes an d operations, which are usually made available using the WPS standar d. Considerin g
data structures (like GML application schema) for semantic annotations enables reasoning on data
model level. In the example of figure 8, t he feature type and the feature attributes have areference to concepts in the resource ontology. Within this ontology we are no w able to relate thelocal service-specific concepts, which are directly associated to the data, to the global domain
concepts (see Figure 6)

Figure 10 - Referencing elements in the da ta model to doma in ontolog ies

Defining the semantics of a feature type, i.e. using an application ontology to capture the meaningof the elements and attributes used in the data model, enables reasoning on a more detailed level.
Again, the specific reasoning capabilities rely on the ex pressiveness of the chosen logicallanguage. Reasoner-supported IR systems for geospatial Web Services an d data sets based on thesemantic annotation approach have been implemented successf ully (see Schade et al, 2008 and
Hoffmann et al, 2008). With semant ically and syntactically correct annotations we have sho wn
28
Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2
that discovery, in term of precision, can benefit significantly. It depends, however, on
sophisticated semantic queries to benefit from the full complexity of the semantic annotations on
this level. As explained in section 2.2.1 , we have investigated user interface which support theuser in creating such more complex queries.
Even if there is no exact mat ch between a user's query and the semantically annotated Web
Service, the annotations help to increase recall. Once discovered, the annotation can be used to
identify the exact attributes containing t he desired information (see figure belo w). T he references
have to be follo wed the other way, from the ontology back to the data model and its specificelements. In the example, such links in dicate that the attribute allowedproduction contains
information about the allowed production of a specific substance in t ons per year, the nameinformation considers the name of the owner of the quarry, etc.

Figure 11 - Using references to identify releva nt elements in the da ta model

2.1.3 Level 2 - Geospatial Processes
Approaching semantic discovery of processing functionality requires more then a Resource
Ontology describin g the output from a Web Service. As illustrated in the following figure, it is
not sufficient to provide a domain vocabulary includin g all possible processes a Web service canimplement. It is additionally required to model not only the output of the Web service (as we do it
for the data models), but also the expected input dat a of the process and the dependencies
between the output and the input (e.g. sayin g the resulting output area is the union of the two
input areas). T aking not only the output (the postconditions), but also the input (preconditions)
into consideration demands for more sophisticated reasoning capabilities, and is for example
discussed in more detail in the Hoffmann et al. (2008).

Copyright © 2012 Open Geospatial Consortium.

29

OGC 08-167r2

Figure 12 - Elements for the Annota tion of Processes.

Due to the expected complexity we assume semantic annotations of processes is (for now) only
applicable for a small n umber of applications. T he semantic validation of workflows includin gprocessing f unctionality depends on the semantic annotation of all components. It is additionallyusef ul for tasks where specific processin g capabilities within a large pool of WPS are searched.
Annotating processes is also interesting if non -standard operations are implemented and served
via Web Services not conformal to the OGC Standar ds. In the case of WFS, WCS, an d o ther
OWS focussed on data only, the annotation can focus on the data since the semantics of theoperations are predefined.

2.1.4 Level 3 - Data Entities
Semantic annotations are also possible on the data entity level. Regar ding OGC Web Service,
GML features and feature attributes are the entities which have to be annotated here. We candistinguish bet ween two potential techniques: T he individual entities can be either annotated withdomain concepts or with individuals on the domain level. A specific quarry can, for example, be achalk pit. A user might want to express this information by annotating it with the domain concept
CHALK P IT. If this particular chalk pit is modelled in the domain ontology (in this case as
individual of the concept CHALKP IT), he might even want to directly associate the data entitywith this individual.Havin g annotations on the instance level has several implications on
discovery and evaluation of geospatial resources. T he annotations can be used to search for asubset of features (in this case only data entities representing chalk pits) by filtering o ut otherfeatures. T he information available for in dividual entities can be increased significantly. Since
ontologies are, by nature, a very flexible mo del, additional information can be adde d on r untime.
Adding additional documentation to individual data entities is therefore simply a matter of adding
it to the associated Concept/Individual in the Resource Ontology. One specific application, themerging of datasets includin g quality control, can benefit tremendously from semantic
annotations on the data entity level. During merging, features annotated either with the same
30

Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2
individual can be regar ded as equal. In addition, rules can be applied to formalize constraints on
the thematic dimension t o reduce error in data sets. T his wo uld, for example, not only ensure
geometric consistency of datasets (a street network has to be connected), but also semantic
consistency (features annotated with the domain concept H IGHWAY can not be directly connectedto features representing a PEDESTRIAN ZONE ).T echnical realization of the individual levels

2.2 Technical realization of the individual levels
Up to now the implications on the applications have been discussed, together with drawbacks an dbenefits for each level. In the following three sub-sections we discuss how the annotations shallbe technically realized.

2.2.1 Level 1 - Service Metadata
Only sparse information is available for the Quarries WFS. T he name “MapServer WFS” isautomatically generated and refers to the implementation, the title “Quarries” as well as the
keywords “brgm, quarries, quarry, france” provide an only very limited desc ription of the served
geospatial data. T he most light -weight and simplest implementation of a semantic annotation is toextend the keyword section by addin g pointers to domain concepts. Another option is to use the
METADATA field which is proposed as Service Content Metadata in WS-Common. T he standard
does not specify what types of metadata are meant to be entered here. It would be therefore
possible to add the list of domain concepts to this field as well.
Each concept is uniquely identified by an URI, th e accepted standard to encode locations in
the World Wide Web. Using an URI as concept identifier presumes either a predefinedknowledge base where such concepts might be retrieved from, or that the URI is also an URL
which can be simply accessed using a standar d Internet browser.
In Section 2.1.1 we ar gued that addin g such URI s to the service metadata section have anegative impact on the readability. One potential solution are tools to visualize the concepts andtheir relations on the domain level as in figure 11. T his tool has been developed within the
SWING project to make the creation of semantic annotations also possible for non -experts. A tool
bun dled with this visualization component is available for do wnload 12 , a video 13 demonstrates its
usage.

12

http://swin g.brgm.fr/mi msalpha/downlo ad

13

http://swin g-project.org/D emos /WP1/WP1-MiMS.html

Copyright © 2012 Open Geospatial Consortium.

31

OGC 08-167r2

Figure 13- Res ult of the tra nslation from da ta model to Resource O ntology(us ing the developed v isua lization tool).

2.2.2 Level 2 - Data Models

Figure 14 - Using Data ty pe Ontolog ies for flexible a nnota tions.

T o benefit from reasoning on the data model level, the data schema is associated with its
Reso urce Ontology. In the first step, the existing data schema can be simply translated into theaccording Reso urce Ontology. In figure 13 the result of such a translation is visualized (theresulting W SML co de is listed in Figure 5. T he association between the concepts within the
XML-based data schema and the Resource Ontology is established by adding an additional
attribute to the selected elements in the schema, with the identifier (as URI) of the concept asvalue. GI R systems like a CAT can now retrieve, for each registered Web Service, the32
Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2
persistently linked Reso urce Ontology, and infer if a user's semantic query matches the semantic
description of the service.

Figure 15 - Result of the translation from data model to Resource O ntology(us ing the developed v isua lization tool)

In 2007, the W3C submission “Semantic Annotations for WSDL and XML Schema ( SAW SDL) 14
officially reached the W3C Recommendation status. T his very light -weight standard suggests theuse of the modelReference attribute to relate elements in XML schema (as well as elements in
WSDL documents, which is not (yet) of interest for the OGC community) to concepts inknowledge mo dels. T he standard does not define the language used for the knowledge models,
nor does it prescribe the complexity of the model. It can be as simple as a controlled vocabulary
or a T opic Map or as complex as an ontology. Having an URI ( see section 2.1.1 ) as unique
identifier for the concepts in the knowledge model is the only prerequisite.
T he SAW SDL standard suggests two additional attributes to enable a mapping bet ween thelanguage used to model the ontologies and the original data schema. If included, the two
attributes liftingSchemaMapping an d loweringSchemaMapping can point to XSLT
documents which enable automatic transformation between two schemas (assuming theontologies are encoded in a XML-based language). T his transformation is addressing the data
entities, which makes it possible to transform data coming from a service into entities processableby the reasoning algorithm. The potential benefits for applications which have to consider data
quality and processin g of data in general are enormous, but discussin g this is clearly o ut of scope
for this article. Examples how to add SAW SDL model references to existing data schemas an dthe implications on existing OGC standar ds, are further discussed in section 1).
14

Find the reco mmendation h ere: http://www.w3.org/TR/sawsdl

Copyright © 2012 Open Geospatial Consortium.

33

OGC 08-167r2
T he annotation process can be supported using graphical tools (see figure 14). Within the
Reso urce Ontology we have the concept EXP LOITATIONSP ONCTUALSP RODUCTION which has
several relations to other concepts representing the attributes. T wo concepts, the YEAR and the
ALLOWEDP RODUCTION , have been related to concepts in the (global) domain ontology. T he user
is able to simply add domain concepts to the view, and establishing either an annotation link
between service concepts and domain concepts (the red lines), or relations between domain
concepts (the black lines). In this example we have now formally specified that the value of theattribute allowedproduction is representing the P RODUCTION CAP ACITY of the Quarry,measured in T ONSP ERYEAR. T he YEAR, which is the negative exponent of the Unit Tons per
year, is the value of the attribute year.

Figure 16 - Annota tion of the feature type exploitationsponctualsproduction(us ing the developed v isua lization tool)

T he following listing shows an example of WSML code expressing the annotation from fi gure 14(which is automatically generated by the visualization tool). See figure 5 for the concept thisaxiom is referring to.
?ft[Year hasValue ?attr1,
AllowedProduction hasValue ?attr2 ,msGeometry hasValue ?attr3]
memberOf exploitationpunctualsproduction and34

Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2/* referencing the attributes to domain concepts */?year memberOf domain#Year anddomainReference(?attr1, ?year) and?capacity[hasUnitOfMeasure hasValue ?uom]
memberOf domain#ProductionCapacity anddomainReference(?attr2, ?capacity) and/* the production capacity refers to the attribute year */?uom[withNegativeExponent hasValue ?year]
memberOf domain#TonsPerYear .
Lis ting 1 - Exa mple of WSM L a nnotation using the Resource O ntology

2.2.3 Level 2 - Geospatial Processes
T he description of type signatures (the input/output types) is a crucial part of functionaldescriptions. It ensures syntactic interoperability between requester and a Web Service an dtherefore guarantees that a Web Service can process the provided inp ut type and that a requester
can accept the delivered o utput type. Such descriptions can be realised usin g annotations with
Reso urce Ontologies as described in previously (section 2.2.2 ).
T he called, respectively requested, operation has to be linked to the appropriate concept
representing the operation to make its interpretation unambiguo us. T he different overlay
operations on polygons (difference, symmetric difference, intersection, and union) have all equal
type signatures and equal constraints. Additionally, their input and output polygons adhere to acommon spatial reference system. It is therefore impossible to distinguish them just byconsidering (even sophisticated) descriptions of input and output types. Having a unique domain
concept like DIFFERENCE or UNION (along descriptions attached to the concepts) associatedmakes the signature of the WPS better understandable.
Annotations from process descriptions in the OGC Capabilities Document, respectively in the
WPS DescribeProcess-response can be established in a similar way as described in sections 2.2.1
and 2.2.2 .
Additionally, depending on the chosen logic, constraints on service inputs, a nd dependencies
between the in- and outputs may be formally specified. T o ensure that the Web Service reallyprocessed the provided input in the intended way, constraints which further narrow down thepossible input and output values are required. For exam ple, a WPS computing the difference oftwo polygons requires all input values ( besides being of type polygon) to adhere to a common
coordinate reference system. A slightly more complex problem, the possible permutations of the
input variables, does additionally require to formalize the dependency between output and input.
If we only annotate the inputs, outputs, and the operations using axioms defined in the Reso urce
Ontology, we are not yet able to express such relationships. It would be impossible to distinguishbetween Difference(A, B) and Difference(B,A), although their results are quite different.

Copyright © 2012 Open Geospatial Consortium.

35

OGC 08-167r2
Modellin g these dependencies is unfortunately quite complex, and is illustrated here only forthe sake of completeness. T he intended module within WSMO to capture such dependencies is
the WebService, with pre- and postconditions and shared variables. In the preconditions therequired input is formalized usin g axioms, the same is performed for the output. Shared variable
are used in both, the pre- and postcondition. An adapted reasoning engine is no w able to consider
dependencies, using the already mentioned extended Plug-In Match. T he following figure has acomplete example for the annotation of a WPS using the WebService component.
webService DifferenceWPS
capability DifferenceWPSCapability
sharedVariables { ?a, ?b, ?srs }precondition UnionWPSPrecondition definedBy?a[iso19107#hasSRS hasValue ?srs] memberOf iso19107#Polygon and?b[iso19107#hasSRS hasValue ?srs] memberOf iso19107#Polygon and?srs memberOf iso19107#projSRS.
postcondition UnionWPSPostcondition definedBy?c[iso19107#hasSRS hasValue ?srs] memberOf iso19107#Polygon and
GeoOperations#Difference(?a, ?b, ?c).
Lis ting 2 - Complete description of a WPS in WSM L

2.2.4 Level 3 - Data Entities
Similar techniques as the one used for annotating data models ( see section 2.2.2 ) can be applied
to annotate data entities like feature instances. Supporting annotations on this level seems to be
only usef ul for feature data provided by an OGC WFS. T he structure of the la nguage used to
encode the data ( GML) is predefined in the associated XML schema. Havin g additional
attributes therefore requires modifications of this schema. T his is discussed in detail in section
3.3.2 , p.45.
User interfaces supporting annotations on the instance level have to let the user attach links ofconcept definitions directly to features on a map. From a technical perspective there is nodifference bet ween annotating data models or data entities. T he same technique an d user interface
strategy as discussed in section 2.2.2 (p. 32) can therefore be applied to annotate features.

2.3 Comparing the capabilities of the three approaches
We compiled a summary of the advantages and drawbacks of the three levels in a table, which isavailable as Appendix B starting on page 50. Note that we were only able to collect experience on
semantic annotations of data models and processes. We are not aware of every potential argument
in favor or in opposition to t he individual techniques. As o utcome to the discussion
accompanying this paper we expect a more thorough overview of the drawbacks and benefits, and36

Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2
reference documentation which guides the application developer through the implementation of
geospatial applications supported by the semantic annotations.

3. Implications for existing GIS Standards
T his section analyzes how the various standards involved in the GI S world may be affected by
the proposed techniques, i.e. where would the use of model references fit best, and what would be
the benefits or drawbacks. For each of the standards covered in the follo wing subsections, thelevel of annotation that is relevant to address with that standard is considered. Metadata standards
will mostly be used to do first and second level annotations (resp. service and data model), whiledata representation standards are the place to implement third level annotations (data instances).
Finally, because annotating resources is useless without a way to query those annotations,
OGC Filters, as a query encodin g standard, is the subject of the last section, and ways to express
filters based on semantic annotations are considered. T he proposals made in this section can beseen as grounds to build a set of best practices and change requests to generalize and harmonize
semantic annotations across GI S standar ds.

3.1 Expressing semantic annotations
Before analyzing existing standards, it is best to first devise ho w semantic annotations should be
ideally expressed.
A semantic annotation must contain the URI of the classifying concept. T hat is the solemandatory and sufficient piece of information needed to fully qualify the annotation.
Extra attributes should be provided for convenience and performance, namely a label, language ,the thesaurus URI and thesaurus label that the concept (or semantic entity in the broad sense)
belongs to. T hese attributes, although not required to formally identify and process theannotation, are usef ul to implement tools that do not need to resolve and reach the p otentiallyremote concept definition, thereby offering better performance and usability. T hese attributes
should therefore be optional.
As a result, a valid example (outside the scope of any standard analyzed belo w) of a semantic
annotation would be ( using the GEMET thesaurus 15 ) :<annotation conceptUri =”http://www.eionet. europa.eu/gemet/concept/4612 ”
thesaurusUri=” http://www.eionet.europa.eu/gemet/”
thesaurusLabel =”GEMET - INSPIRE Themes, Version 1.0”
lang=” en”>
Land Cover15

In this GEM ET exampl e, and others further do wn, the th esaurus URI is set to ht tp://www.eion et.europ a.eu/gemet/, although the right valu e is unclear fro m avail abl e onlin e resources.

Copyright © 2012 Open Geospatial Consortium.

37

OGC 08-167r2</annotation>

where thesaurusUri, thesaurusLabel, lang and the element content (i.e. the concept label) are
optional, i.e. the minimal valid annotation would be :<annotation conceptUri =”http://www.eionet. europa.eu/gemet/concept/4612 ”/>

The example above assumes that the annotation element is located within the element being
annotated. Like for example in the OGC capabilities a Keyword element is located within theService element being annotated.
If this is not the case, and the annotation stands on its own, then it must also hold a reference tothe entity being annotated, i.e. (re-using the minimal annotation above) :<annotation conceptUri =”http://www.eionet. europa.eu/gemet/concept/4612 ”
annotatedElement=” http://server/element/1234”/ >T his assumes that the elements being annotated can be referenced by URI, too.
Standar ds analyzed belo w will always present the first case, i.e. the annotation being included
within the annotated element. T he second case presented in the previous paragraph will therefore
not be considered further.
Each standard belo w will be analyzed to see to what extent it can contain such an entity, and whatchanges or workarounds wo uld be required to do so, if any.
Related work at the W3C is also worth considerin g in the scope of this Best Practice :http://www. w3.org/2005/Incubator/ssn/wiki/Report_Work_on_Semantic_Markup .

3.2 Metadata standards
Vario us or ganizations introduced standards for metadata, both for geospatial data and service s. In
this section we review standards of three common fields: I SO/T C211 metadata standards, theservice capabilities as defined by OGC, an d ebRIM, as introduced by OASI S.

3.2.1 ISO 19115 & 19119
ISO 19139, as the encoding standard for metadata compliant to ISO 19115/19119, is the firststandard to consider when includin g the references needed for semantic annotations. Looking at
the whole I SO 19139 structure, the most appropriate place to introduce Level 1 semantic
references seems to be the gmd:MD_Keywords element. T his element is meant to hold sequencesof keywords, using keyword elements, and with extra attributes definin g the context, such as thetype or thesaurusName.
<gmd:MD_Keywords><gmd:keyword><gco:CharacterString>keyword1</gco:CharacterString></gmd:keyword>

38

Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2<gmd:keyword><gco:CharacterString>keyword2</gco:CharacterString></gmd:keyword><gmd:type><gmd:MD_KeywordTypeCode
codeList=<anyURI>
codeListValue=<anyURI>/></gmd:type><gmd:thesaurusName > ... </gmd:thesaurusName></gmd:MD_Keywords>
Lis ting 3 - ISO 19139 S tructure

T his ISO19139 structure can be used without modifications to hold semantic references toconcepts from a given ontology. If we assume that (see section 2.2.1 ) any concept can be
uniquely referenced by a URI that can be split as a base URI an d a concept ID:<ontologyURI Base><conceptId>e.g.
for H TTP URIs:

http://www.example.com/Ontology#

QUARRY

for URNs:

urn:x-test:landtypes:

CROP S

Listing 4 - U nique Identifiers

T hen the keyword elements can be used to hold the concept names describing the resource, andthe codeList attribute of the type element can be used to hold the URI of the ontology containing
the concepts. Using this approach, the following I SO19139 excerpt would contain valid
references to such concepts16 (Guidelines regar din g the proper use of the type andthesaurusName elements are needed to ensure that this approach is valid).

<gmd:MD_Keywords><gmd:keyword><gco:CharacterString>Quarry</gco:CharacterString></gmd:keyword><gmd:keyword><gco:CharacterString>brgm</gco:CharacterString >16

For the rest of this document , most exampl es will use HTTP URI as concept ref erence ex ampl es. Pl ease keep inmind that U RN referenc es may also b e used. This will especi ally b e tru e when ex ampl es relat ed to th e c atalo g and
ebXML wi ll be d escrib ed.

Copyright © 2012 Open Geospatial Consortium.

39

OGC 08-167r2</gmd:keyword><gmd:type><gmd:MD_KeywordTypeCode
codeList=” http://www.example.com/Ontology# ”
codeListValue=”ontology”/></gmd:type><gmd:thesaurusName>...
</gmd:thesaurusName></gmd:MD_Keywords>
Lis ting 5 - Concrete Example of ISO 19139 Str ucture

However, it would be better suited to be able to define keywords belonging to various thesauri,each having its own URI. To this end, the gmx:Anchor element (defined to point to registereddefinitions, according to the ISO specification, and usable as a substitute for
CharacterString) is better suited (here using the GEMET thesaurus for the sake of theexample) :<gmd:MD_Keywords><gmd:keyword><gmx:Anchor
xlink:href=”http://www.eionet.europa.eu/gemet/concept/4612 ”>
Land Cover</gmx:Anchor></gmd:keyword><gmd:thesaurusName><gmx:Anchor xlink:href="http://www.eionet.europa.eu/gemet/ ">GEMET - INSPIRE Themes, Version 1.0</gmx:Anchor></gmd:thesaurusName></gmd:MD_Keywords>
Lis ting 6 - Concrete Example of ISO 19139 Str ucture

Here we see that the gmx:Anchor element provides a way to substitute a mere string with aqualified and labeled entity (concept or thesaurus) . It thereby fulfills the requirements for theabstract annotation element described in section 3.1 .
Regardin g semantic annotations at the second and third level (data models and entities), model
references have to be introduced as explicit metadata element. ISO 19115 foresees two options
for this:
T he abstract element MD_ContentInformation could point to ontological descriptions.
Coverages an d feature catalogue descriptions are currently the only non-abstract children of the40

Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2
MD_ContentInformation class. Both provide potential extension points to include
characteristic parameters and natural language descriptions for feature types and properties.
Neither follows the distinction between information objects and models of the world. Aninteresting option would be to include a third class “MD_Reference” to t his branch of metadata
elements, which could contain explicit pointers to resource or domain ontologies.
T he element MD_ApplicationSchemaInformation could also be used to link toontologies. It offers the possibility to refer to an application schema used for a specific data
encoding. Follo wing I SO 19139, this is usually the XSD specifying the encoding of geospatial
information items. Once a pointer to such implementation model is available, semantic
annotations can be established from there. Details considering this approach are given in section
3.3 . T his approach would not require any change of the recent metadata standards, but a specifi c
implementing rule.

3.2.2 OWS Capabilities
T o be able to efficiently describe and discover services using semantic annotations, the OWS
specification must be considered. T he OWS Common specification is common to several OGC
services (WCS, WFS, CSW, …) and defines the way a service can advertise its content, mainly
through the specification of the GetCapabilities operation response. Again, a Level 1
semantic annotation could be established using key words.
Using Keywords
T he definition of the content of a GetCapability response reproduces partially the ISO19139
structure described above in its ows:Keywords element. In particular, the type element ismapped into a ows:CodeType xml element that retains the properties needed for the approachdescribed in the previous section.
T herefore, as a direct consequence, we can apply the same approach to the OWS Capabilities;
usin g this approach, the GetCapabilities document of an OGC service wo uld look like thefollowin g:<ows:ServiceIdentification><ows:Title>Some WFS Service</ows:Title><ows:Keywords><ows:Keyword>Quarry</ows:Keyword><ows:Keyword>brgm</ows:Keyword><ows:Type codeSpace=”http://www.example.com/Ontology#” >ontology</ows:Type></ows:Keywords><ows:ServiceType>WFS</ows:ServiceType><ows:ServiceTypeVersion>1.1.0</ows:ServiceTypeVersion></ows:ServiceIdentification>
Lis ting 7 - Annota tion of the GetCa pabilities-Document

Copyright © 2012 Open Geospatial Consortium.

41

OGC 08-167r2

Here the Keywords element is sho wn as part of the ServiceIdentification element, i.e. theservice description. It can also be used at the level of resources of the services, e.g. feature types
for the WFS, coverage offerings for the WCS, process descriptions for the WPS, and more.
It must be noted that there can be only one ‘Type’ element per ‘Keywords’ section, hence having
all keywords within a ‘Keywords’ section belonging to the same thesaurus (if any). If keywords
from different thesauri are needed, multiple ‘Key words’ sections can be used.
T his construct is not as flexible as the abstract annotation element defined above. In particular,
there is no way to express a conceptURI that is not an extension of its thesaurusURI. T herefore, achange request should be issued to add the ability to have full-fledged annotations in OGC
capabilities, i.e. having each a mandatory concept URI, and optional label, language andthesaurus URI/label. M uch like what gmx:Anchor offers.

3.2.3 WMS Capabilities
T his approach is valid for all OGC services, with one noticeable exception, though: the WM S
specification, as per its 1.3.0 version, does not comply with the OWS Common specification. As
a result, the Keywords element is replaced by a KeywordList element, and the Type element
does not exist.
T he WMS specification should comply with the OWS Common specification by its next
version. In the mean time, if the WMS specification in its current state must be used withsemantic references, the only way is to use the vocabulary attribute available on each Keyword
element, defined by the specification as “ an attribute to indicate the defining authority for that
keyword”. T he Keyword content would then be the concept URI. T herefore, the semantic
annotation becomes :<WMS_Capabilities version="1.3.0"><Service><Name>WMS</Name><Title> Some WMS Service </Title><KeywordList><Keyword vocabulary=”http://example.com/Ontology#” >http://example.com/Ontology#Quarry</Keyword><Keyword vocabulary=”http://example.com/Ontology#” >http://example.com/Ontology#BRGM</Keyword></KeywordList>
Lis ting 8 - M eta da ta Annota tion for WMS

However, this scheme prevents the expression of the concept label. T his is a limitation of theWMS capabilities as they stand today.
42
Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2

Using MetadataUrl
T he WFS and WM S specifications define a MetadataUrl element that provides a link to
metadata documents describing respectively FeatureT ypes and MapLayers. Such MetadataUrlelements have a format attribute defining the metadata format; its values are taken from a finite
set, containing e.g. I SO19115 or FGDC. T his element can be used to provide links to documentsthat describe the resource semantically. T his kind of semantic annotation would not be a mere
model reference linking between entities and concepts as described earlier, but a reference to afull ontology including these concepts. In the case of a feature type, such ontology can be used tosemantically annotate the feature type structure, as described in section 2.2.1 (p. 31). T o achievethis, more formats should be added to the format attribute value set, such as RDF, OWL, SKOS
or WSML.
<wfs:WFS_Capabilities version="1.1.0"><FeatureTypeList><FeatureType><Name>rivers</Name><MetadataURL type="0" format=" rdf/xml" >http://example.com/ontology#rivers</MetadataURL></FeatureType>Lis ting 9 - Us ing the Metada taURL for the feature types in a WFS

3.2.4 ebXML
Previous sections described how to add model references to metadata documents. However, forthis to be useful, semantic annotations must be handled properly by the components that index
such metadata documents. So, although ebXML is not a metadata representation language per se,
it is the model used to represent metadata in one of the two CSW profile specifications 17 . T his
section will thus discuss ebXML an d see ho w it can be used to efficiently store such semantic
annotations.

17

The oth er C SW profil e (ISO AP), based on the ISO19115 specification, c an follo w the recommendations mad e insection 3.2.1 .

Copyright © 2012 Open Geospatial Consortium.

43

OGC 08-167r2
T he ClassificationNode an d Classification elements in the ebRIM specification canbe used to store respectively concepts and semantic annotations, with all the information
described in section 3.1 , and this is how they are used already in the CSW ebRIM profile.
T herefore, the CSW ebRIM profile in its current definition already holds the functionality needed
to represent model references.
However, as a recommendation, it would be good to suggest that semantic annotations as
proposed in the previous sections (ISO19115, Capabilities) be harvested by CSW ebRIM catalogs
by representing the model references usin g the ClassificationNod e and Classification
ebRIM elements. T hat way, semantic annotations contained in the metadata harvested in a catalog
wo uld be explicitly expressed as such and are therefore query-able in an efficient way. Examples
of such querying will be provided in sect ion 3.4 regarding OGC Filters.

3.3 Data representation standards
T he previous section explored how to use semantic references in metadata documents describin g
GI S reso urces. T aggin g reso urces can also be done at a finer -grained level, as described in
sections 2.2.2 to 2.2.4 . To achieve that, we will now consider data representation standards, andhow techniques proposed in previous sections can be applied to them.

3.3.1 GML Schema
As explained in section 2.1.2 , XML schemas can be augmented with semantic annotations usin g
the SA-WSDL standard, which suggests to add a modelReference attribute to XML element
type definitions. Since GML schemas are instances of XML schemas, the same proposal can beapplied here as well. Here is an example of a GML schema where the SA -W SDL proposal isapplied to annotate the schema (for the sake of conciseness, the ontology complete URI is
replaced by the XML entity &quarries;) :<element

name=”exploitationsponctualsproduction”
type=” exploitationsponctualsproductionType”
sawsdl:modelReference="&quarries;exploitationFeatureType"><complexType name="exploitationsponctualsproductionType"><complexContent><extension base="gml:AbstractFeatureType"><sequence><element

name="msGeometry" type="gml:GeometryPropertyType"

sawsdl:modelReference="&quarries;QuarryLocation"/><element name="name" type="string"/><element name="year" type="string"
sawsdl:modelReference="&quarries;Year"/><element name="allowedproduction" type="string"/>

44

Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2
sawsdl:modelReference="&quarries;Community "/></sequence></extension></complexContent></complexType>Lis ting 10 - Applying SAWSDL to GM L Schema

In this example, one can see how the modelReference attribute is used to semantically annotate
both the feature type itself, and some of its elements. In terms of specification, this piece of XML
schema is valid, since any attribute can be added to elements such as xs:complexType or
xs:element.
Again, here modelReference offers the minimal expressivity described in 3.1 , i.e. the URI.
T he additional attributes (label, language, ...) are not available, and would re quire a different
construct. However, it is arguable that GML schemas need such convenience attributes, as they
are mostly meant for machine processing.

3.3.2 GML instances
As explained in section 2.1.4 (p.30), the most fine-grained option to semantically annotate datais to do it at the level of each feature. T o achieve that in GML data, one can add to its feature
type’s specific attributes to hold model references for each data instance. In this example, amodelReference attribute is added to the type of stone provided by a quarry:<complexType name="quarries"><complexContent><extension base="gml:AbstractFeatureType"><sequence>[…]<element name="allowedproduction" type=”anyURI ”/></sequence></extension></complexContent></complexType>Lis ting 11 - Applying SAWSDL to GM L-encoded Da ta E ntities

Such a solution simply adds a feature attribute that can hold anyURI .T his is enough to carry thesemantic annotations, but a stronger-typed solution may be better, such as:<xs:simpleType name="modelReference">

Copyright © 2012 Open Geospatial Consortium.

45

OGC 08-167r2<xs:restriction base="anyURI"/></xs:simpleType><complexType name="exploitationsponctualsproductionType"><complexContent><extension base="gml:AbstractFeatureType"><sequence>...
<element

name=" allowedproduction"
type=” gml:modelReference”/></sequence></extension></complexContent></complexType>Lis ting 12 - A s tronger-typed solution for a pplying SAWSDL

By explicitly definin g an attribute as being a modelReference, component storing such data
(e.g. a WFS) will be able to properly index it for further querying.

3.3.3 SensorML
It is useful to consider here the SensorML specification, where a similar problem has been tackled
at various levels. In this specification, several types of elements need to be semanticallyannotated, namely observable properties and processes.
As a result, several constructs are available to express semantic annotations.
First, the AbstractDataComponentType element type is the abstract type parent of all data
components and observable properties, and has an optional definition attribute, of typeanyURI, defined as “ pointing to semantics information defining the precise nature of thecomponent”:

46

Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2<xs:complexType name=" AbstractDataComponentType" abstract="true"><xs:complexContent><xs:extension base="gml:AbstractGMLType">...
<xs:attribute name="definition "type="xs:anyURI" use="optional"><xs:annotation><xs:documentation>
Points to semantics information defining the
precise nature of the component</xs:documentation></xs:annotation></xs:attribute></xs:extension>/xs:complexContent></xs:complexType>

Listing 13: Semantic Annotations in SensorML
T hen, the process can be described using process metadata groups. T hese metadata group s canhold so-called identifiers and classifiers, that can refer to semantic entities defined in external
ontologies (see SensorML specification, OGC 07 -000, sec. 8.11). They can also containkeywords qualified by a codespace, as in OW S Common capabilities.

<key words><Key wordList codeSpace="urn:x-nasa:def:gcmd:key words"><key word>weather</key word></Key wordList></key words><identif ication><IdentifierList><identif ier name="longName"><Term def inition="urn:ogc:def:identifier:OGC:longname"><v alue>Davis 7817 External Temperature Sensor</value></Term></identifier></Identif ierList></identification><classif ication><Classif ierList><classif ier name="orbitType "><Term def inition=" urn:ogc:def:property:OGC:orbitTy pe "><codeSpace=" urn:ogc:def:dictionary:CEOS:eop:OrbitTy pes:v01"/><v alue>GEOSTATIONARY </v alue></Term></classifier></ClassifierList></classification>

Copyright © 2012 Open Geospatial Consortium.

47

OGC 08-167r2
As an example of such annotations, with a classifier referring to the ESA OrbitT ypes dictionary :T he Term element used here is defined in the SensorML specification, and contains-

a definition attribute that can hold the concept URI-

an optional codespace sub-element that can contain the thesaurus URI-

a value subelement that can contain the concept label

Sen sorML therefore already has several means to specify model references, complying with theminimal constraints expressed in this document. However, it must be noted that some optional
elements described in section 3.1 are not supported : identifier an d classifier elements do notprovide a way to express the label lan guage, wh ile the definition attribute of
AbstractDataComponentT ype only supports the expression of the concept URI.

3.3.4 KML
KML itself is a standard to formally encode simple features without explicit definitions of their
attributes. We consider KML to be a lightweight example of GML instances; the problems
identified there are therefore also valid for KML. It is not an option to extend the KML schema ina way to include the semantic annotations. But in version 2.2.0 of the OGC KML specification,
the ExtendedData field provides a flexible way to annotate existing features (e.g. the whole
Document, individual Placemarks or their collections, the Folders) . T he following example showsthat a Placemark can be annotated with a domain reference linking to a concept from a shareddomain vocabulary<Placemark><name>Münster</name><ExtendedData><Data name="http://purl.org/net/concepts/domainReference"><value>http://www.geonames.org#Muenster</value></Data></ExtendedData></Placemark>Lis ting 14 - Sema ntic Annotations in KML

Note that the value of the attribute “name” has to include either the model reference URI (if aresource ontology exist which is specific for this particular KML file) or the domain reference
URI. Only the reference URI specifics that we have a semantic reference, the URI itsel f therefore
has to be agreed upon beforehand.
48
Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2

3.3.5 Contexts
The Web Map Context specification (as per version 1.1 ) defines a KeywordList element, butwhich can contain a mere list of string keywords. It does not provide any mean to express thethesaurus URI separately from the concept names. Therefore, the only way to use conceptreferences to tag a context is to use full concepts URIs in the keywords list, as in:<ViewContext version="1.1.0"><General>...
<KeywordList><Keyword>http://www.example.com/Ontology#Quarry </Keyword><Keyword>http://www.example.com/Ontology#BRGM</Keyword></KeywordList>
Lis ting 15 - Sema ntic Annotations in a Context document

This is not very strong typed, and does not o ffer a way to express optional attributes describedin section 3.1 .

Future Context specification
A new Context specification is being defined and should be ready by end of 2011. This new
specification builds on the Atom format. As a result, semantic annotations in that format willcertainly reuse the ‘category’ element available in the Atom spec, i.e.
<feed>...
<entry ><category term=”Quarry” scheme=”http://www.eionet.europa.eu/gemet/” /><category term=”Quarry” scheme=”http://www.eionet.europa.eu/gemet/” />Lis ting 16 - Sema ntic Annotations in a n Atom-based Context document

The category element, as per the Atom specification, contains a way to express the attributes
described in section 3.1 (apart from the thesaurus label) . As an example, here’s how one candefine a category with all those attributes in use :<category term=” http://www.eionet.eu.int/gemet/concept/4612”
scheme=”http://www.eionet.europa.eu/gemet/ ”label=”Land Cover”
xml:lang=” EN” />Here the term attribute is used to hold the full concept URI, although the Atom specification
originally intends it to be a mere string code defined in the scope of the thesaurus.
Copyright © 2012 Open Geospatial Consortium.

49

OGC 08-167r2
The Atom category element does not provide a way to express the thesaurus la bel ; this issomething to investigate and suggest to the OGC Context group.

3.4 OGC Filters
Assuming that there exist s data and metadata annotated with semantic references, one must beable to discover them efficiently. If we consider only the OGC services, expressing queries todiscover data is mainly done usin g OGC Filters.
T he OGC Filter Encodin g Standar d does not provide means to express semantic concept
matching, not to mention semantic predicates validation. T he only operator that comes close tothis is in the CQL specification, part of the Catalogue specification, where an optional
ClassifiedAs operator is defined, although it is not meant to references concepts by URI, as
wo uld be needed in the scope of this discussion. So, to be able to discover data tagged withsemantic references, a proposal is made to add specific operators to the OGC Filter specification.

3.4.1 The ClassifiedAs-Operator
T he first operator that would be needed is an operator similar to the ClassifiedAs operator in
CQL, but taking a concept URI as parameter. T his operator would take a property name as firstargument arg1, and a concept URI as second argument arg2. It wo uld return the boolean true
value if the value of arg1 references a concept that is equivalent or is a subclass of the conc ept
defined by arg2. In terms of XML schema, this can be defined as p art of the Filter.xsd schema
as:<xsd:element name="ClassifiedAs"
type="ogc:ClassifiedAsType"substitutionGroup="ogc:comparisonOps"/><xsd:complexType name="ClassifiedAsType"><xsd:complexContent><xsd:extension base="ogc:ComparisonOpsType"><xsd:sequence><xsd:element ref="ogc:expression"/><xsd:element name="concept" type="xsd:anyURI"/></xsd:sequence></xsd:extension></xsd:complexContent></xsd:complexType>Lis ting 17 - How to apply the ClassifiedAs O perator

50

Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2
T his definition can be enhanced by declaring the concept element as a new type, e.g.
ConceptRefType, wh ich would explicitly reference the concept in terms of its thesaurus URI
and concept name.

3.4.2 Usage
Usage in CSW ebRIM :In the scope of an ebRIM catalog, the ClassifiedAs operator can be used to match records thatare subject to a classification, where the classified object is the first element of the operator, andthe second element is the URI of the ClassificationNode used in the classification. It must be
reminded here that the URI of a concept can be a URN, and in particular can be a UUID.
Using this operator in CSW queries will help performing semantic discovery on service
annotations, and on data model annotations:<csw:GetRecords

xmlns:csw="http://www.opengis.net/cat/csw"

xmlns:ogc="http://www.opengis.net/ogc"
xmlns:gml="http://www.opengis.net/gml"
version="2.0.0" outputSchema="EBRIM" maxRecords="50"><csw:Query typeNames="ExtrinsicObject"><csw:ElementName>/ExtrinsicObject</csw:ElementName><csw:Constraint version="1.0.0"><ogc:Filter><ogc:classifiedAs><ogc:PropertyName>/ExtrinsicObject</ogc:PropertName><ogc:Literal>
http://www.example.com/Ontology#Quarry</ogc:Literal></ogc: classifiedAs ></ogc:Filter></csw:Constraint></csw:Query></csw:GetRecords>
Lis ting 18 - Example for ClassifiedAs Operator

Usage in WFS:
OGC Filters can be used when querying a Web Feature Service to search for features that match acertain concept. T his implies that features have been semantic ally tagged, as described in section
2.1.2 (p.28) and 3.3.1 (p.44). Assuming features are properly annotated usin g the feature typeschema proposed in 3.3.2 (p.45), this filter wo uld return all quarries of the type ChalkPit or any
subclass of it:51
Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2<wfs:GetFeature service="WFS" version="1.0.0" […] ><wfs:Query typeName="quarries"><ogc:Filter><ogc:classifiedAs><ogc:PropertyName> Type </ogc:PropertyName><ogc:Literal>
http://www.example.com/Ontology#ChalkPit</ogc:Literal></ogc:classifiedAs></ogc:Filter></wfs:Query></wfs:GetFeature>
Lis ting 19 - Using the modelReference in a WFS query

4. Summary
T he need for better thematic descriptions of OGC Web Services is evident, and we believe thatlinking OW S an d other OGC-compliant resources to ontologies with the help of semantic
annotations can help to address most of the problems identified in the first section. We introduced
three different levels where the annotations can be applied: on the resource metadata level (theCapabilities document for OWS), the data model and processes, an d the actual data entit ies.
T he previous sections sho we d that most existing standards already provide sufficient means
for simple semantic annotations. Agreeing on harmonized best practices (such as the many
proposed here) wo uld be a goo d step forwar d to offer good semantic ann otation capabilities
throughout the OGC stack. From what is observed in the existing standards, it should be noted
though that the need for semantic annotations has already been recognized at several levels an d inseveral domains ( SensorML is a good example). But in the end no harmonized effort was
conducted, which resulted in mixed and partial solutions. Perhaps such a harmonizing effort,
preferably materialized as a definition of a unique annotation element in OGC core schemas(similar to the gmx:Anchor element ?), should therefore be the next step on the quest to
semantically enable OGC Web Services.

52

Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2

5. References and further Readings
F. Baader (2003). The Description Logic Handbook: Theory, Implementation andApplications. Cambridge University Press.
D . Calvanese, De Giacomo, G., an d Lenzerini, M. (1998). On the decidability of querycontainment under constraints. In Principles on Database Sy stems 1998 (PODS'98), pages
149-158.
T .R. Gruber (1995). T oward principles for the design of ontologies used for knowledge
sharing. Int. J. Hum.-Comput. Stud., 43(5-6):907-928.
J. Hoffman, N. Steinmetz, and D. Fitzner (2008): Deliverable 2.4 - Semantic Web
Geoprocessing Services. SWING Project Deliverable.
Url: http://swing-project.org/deliverables/document/110
E. Klien, S. Schade, an d J. Hoffmann (2007): Deliverable 3.1 - Ontologies in the SWING
Application - Requirement Specification
Url: http://swing-project.org/deliverables/document/86
M. Lutz (2007). Ontology-based descriptions for semantic discovery and composition ofgeoprocessin g services. GeoInformatica, 11(1):1-36.
P. Maué, M. Braun, and H. Michels (2008): Meilenstein 5.04 - Anforderungsanalyse zur
Dienste-Annotation in den Szenarien . GDI Grid Project Deliverable.
P. Maué (2008). An extensible semantic catalogue for geospatial web services. International
Journal of Spatial Data Infrastructures Research , 3.
S. Scha de, E. Klien, P. Maué, D. Fitzner, and W .Kuhn (2008): Deliverable 3.2 - Report on
Modellin g Approach and Guideline. SWING Project Deliverable.
Url: http://swing-project.org/deliverables/document/86
M. Zaremski (1996). Signature and Specification Matching. School of Computer Science,
Carnegie Mellon University. PhD T hesis.

Copyright © 2012 Open Geospatial Consortium.

53

OGC 08-167r2

Appendix A - Glossary54Annotation: Attaching descriptive metadata to a resource, with the intention to simplify
its discovery and evaluation.



Data Model: Describes the structure of geospatial data, usually in GML schema. A data
model defines how the → data entities have to represented.

Data Entity: A specific instance of data. Adheres to the structure defined in the → Data
Model.



Domain Ontology: Domain-specific knowledge shared by one user community is
usually captured in such a → global ontology.



Global Ontology: Ontologies capturing knowledge which needs to be shared to otheruser s are categorized as glo bal ontologies. In contrary to → local ontologies, global
ontologies are well maintained by information experts and are made accessible toeveryone.



Knowledge Model : Conceptualizations of knowledge, structured into concepts withunique identifiers an d relations between the concepts. Ontologies are sophisticated formsof knowledge models.



Local O ntology: refers to application specific knowledge models like the → Resource
Ontology. Local Ontologies are not shared, and only the service provider is responsible
for the creation and maintenance (in contrary to → Global Ontology).

Model Reference: A link between an element in the schema-based metadata and aconcept in the → knowledge model. T he model reference is used to link to an entitywith equivalent semantics but a different encoding.



Ontology: Ontologies are the most sophisticated means to structure and specify
knowledge, either on the local level as → Resource Ontology or shared as→ Domain Ontology.



Reasoning: Machine-supported inference to gain either new knowledge out from theexisting ontologies or to solve semantic heterogeneities. Reasoning assumes to have the→ knowledge model expressed in a lan guage processable by the algorithm.

Resource O ntology: Application-specific → local ontology describin g the specificcharacteristics of one particular service or data set. T he → data model of a WFS, forexample, is f ully represented in the Reso urce Ontology (as well as the process served by
a WPS)



Semantic Annotation: A specialized form of → Annotation where the attachedmetadata is partly expressed in a formal language, which makes interpretation by amachine possible. → Reasoning algorithms can then support the discovery andevaluation.



Taxomony: A less structured → knowledge model , consisting of a vocabulary and one
predefined relation between the terms.
Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2

Appendix B - Semantic Annotations in a nutshellIn the following, we present a tentative list of the benefits, drawbacks, an d potential application sfor the proposed annotation at each of the three levels. T his list provides a summary of ourfindings. T his list is a first draft only, the authors expect from future discussions within th e OGC
additional ideas to further extend this list.

Level 1: Source Metadata
Advantages:
Easy to implementEasy to understand (also for non-experts)

Helps to (quickly) assess what kind of data is servedNeeds no modification of underlying data schemaMuch better recall then no annotation at all (due to semantic-enabled query processing)

Only solution for binary data like images (served by WCS or WMS)

Good solution for WMS (since there is no real data schema anyway)

Drawbacks:Semantic-enabled discovery resources requires specialised interfaces letting users selectthe needed concepts



Only week reasoning support if directly linked to domain concepts (via domainreference)

Can impair readability of service metadataConsistency Problems: Changes in un derlying data model requires changes ofannotations on metadata levelNot possible to identify what part of the served data represents the needed information

Suggested Applications:

Service DiscoveryService Evaluation

Copyright © 2012 Open Geospatial Consortium.

55

OGC 08-167r2

Level 2: Data Models
Advantages:Higher precision and better recall since we can model the inner workingsMore details, results in higher recall

We can identify which specific elements yield the requested information

Better assessment possible, since one can better study the data modelLess problem s with consistency, since changes to the data model have direct impact onannotations

Drawbacks:


Loosing the flexibility of Level 1 – annotationsDescribing complex data models tedio us, requires additional documentation



Semantic-enabled discovery resources requires specialised interfaces letting users selectthe needed concepts (but it does have no impact on the normal, keyword-based
discovery)Annotations of processes (in a WPS) rather complex

Suggested Applications:56Service DiscoveryService Eval uation

Workflow Validation

Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2

Level 3: Data Entities
Advantages:
Still lightweight approach, since we still just add a modelReference attribute to entities



Flexible annotation of features

Filtering using annotations possible

Good solution for data without explicit data models, i.e. application schema

Drawbacks:
Needs annotation tools in the Viewer application (Desktop GIS or Web mapping tools)Can be costly, due to the potential high number of entities

Increased data volume

Suggested Applications:

Reso urce Discovery (with filtering)Service EvaluationQuality Control for Resources

Merging of Datasets

Copyright © 2012 Open Geospatial Consortium.

57

OGC 08-167r2

Appendix C – Summary of annotated (meta)data standards
Below is a summary of the standards described in this document, each with a template of
semantic annotation that highlights how to express the elements of an annotation, i.e.
conceptURI, conceptLabel, theusarusURI, thesaurusLabel and language.

ISO19115/19119<gmd:MD_Keywords><gmd:keyword><gmx:Anchor xlink:href=”{conceptURI}”>{conceptLabel}</gmx:Anchor></gmd:keyword><gmd:thesaurusName><gmx:Anchor xlink:href="{thesaurusURI} ">{thesaurusLabel}</gmx:Anchor></gmd:thesaurusName></gmd:MD_Keywords>

OWS
Capabilities<ows:Keywords><ows:Keyword>{conceptURI}</ows:Keyword><ows:Type codeSpace=”{thesaurusURI}”>{thesaurusLabel}

No provision forConceptlabel,
language</ows:Type></ows:Keywords>

WMS
Capabilities<KeywordList><Keyword vocabulary=”{thesaurusURI}”>{conceptURI}</Keyword>

No provision forConceptlabel,
thesaurusLabel,language</KeywordList>

KML<Placemark><ExtendedData><Data
name="http://purl.org/net/concepts/domainReference">

Only conceptURI isexpressed, just as
any other property.

<value>{conceptURI}</value></Data></ExtendedData></Placemark>58

Copyright © 2012 Open Geospatial Consortium.

OGC 08-167r2
Context(WMC)<KeywordList><Keyword>{conceptURI}</Keyword>

Only conceptURI isexpressed.

<Keyword>{conceptURI}</Keyword></KeywordList>

Context(Atombased)
SensorML<category term=” {conceptURI}”
scheme=”{thesaurusURI}”
label=”{conceptLabel}”
xml:lang=”{language} ” /><identification><IdentifierList><identifier name="longName">

No provision
thesaurusLabelNo provision forthesaurusLabel,language<Term definition="{conceptURI}"><value>{conceptLabel}</value></Term></identifier></IdentifierList></identification><classification><ClassifierList><classifier name="orbitType "><Term definition=" {conceptURI}" ><codeSpace="{thesaurusURI} "/><value>{conceptLabel}</value></Term></classifier></ClassifierList></classification>

Copyright © 2012 Open Geospatial Consortium.

for

59