ISA Action 1.17: A Reusable INSPIRE Reference Platform (ARE3NA)

Transcription

1 ISA Action 1.17: A Reusable INSPIRE Reference Platform (ARE3NA) Expert contract supporting the Study on RDF and PIDs for INSPIRE Deliverable D.EC.3.1 Methodology for automated conversion of INSPIRE UML models to RDF Linda van den Brink 1

2 This publication is a Deliverable of Action 1.17 of the Interoperability Solutions for European Public Administrations (ISA) Programme of the European Union, A Reusable INSPIRE Reference Platform (ARE3NA), managed by the Joint Research Centre, the European Commission s in-house science service. Disclaimer The scientific output expressed does not imply a policy position of the European Commission. Neither the European Commission nor any person acting on behalf of the Commission is responsible for the use which might be made of this publication. Copyright notice European Union, Linda van den Brink, Reuse is authorised, provided the source is acknowledged. The reuse policy of the European Commission is implemented by the Decision on the reuse of Commission documents of 12 December

3 Contents 1 Introduction 4 2 Issues External vocabularies Which upper ontology? Missing external vocabularies Reuse of existing vocabularies Geometry encoding Real world things and spatial objects Simplification - Complex datatypes Voidability Domain and ranges integrity constraints Codelists UML modeling artifacts Composition and aggregation Encoding 11 3 Test with INSPIRE themes Buildings Statistical units Environmental Monitoring Facilities 17 4 Overview of mapping rules 20 5 Bibliography 23 3

4 Chapter 1 Introduction JRC received several requests about the availability of official INSPIRE RDF vocabularies from parties who were interested in using INSPIRE data in a linked data context. This report describes a methodology for semi-automatically deriving these vocabularies from the INSPIRE UML model. The requirements for the vocabularies follow from the general use case: making INSPIRE data usable in a linked open data context. From our point of view the linked data approach is complementary to the SDI approach already in place. The traditional approach providing a mechanism for a basis of standardized and structured data within domains, and linked data providing an open mechanism for sharing and combining. The traditional approach is characterized by a service based dissemination of GML structured data. In that approach data specifications provide clear definitions of semantics in predefined domains and use cases. These are implemented in XML schema, providing a well-defined and verifiable means of information exchange. The strong point of it is that the proper purpose of standardization and harmonization, interoperability, can be addressed through agreement and sharing of vocabulary. Once agreed the requirements and rules for communication are set and can be implemented in a verifiable way. The quality of implementation can be measured and therefore managed. But there is a downside: the semantics are defined within information domains. In the INSPIRE model, semantics between the different themes are largely harmonized. However, INSPIRE data could be of use outside its original domain as well, but between the INSPIRE domain and other domains little harmonization takes place, and for not yet foreseen concepts and relations the structure is too rigid. This is exactly the weak spot where linked data can be of help. It allows data to become part of a web of data where it is integrated with other data and data models can be interrelated and harmonized. The general use case for INSPIRE, in other words, is making geospatial data available to the linked data community so it can be combined with other, geospatial or non-geospatial, datasets. In addition to the data itself, there is a need to provide vocabularies, based on the INSPIRE UML models. These vocabularies are needed to document the intent of the used terms, and to ensure the same terms can be re-used in the data Europe-wide. The vocabularies are, however, not created with a use case in mind that involves reasoning. For that reason, the intent is to use RDFS as much as possible and OWL only when necessary. Also, validation of data against the vocabularies, as is quite commonly done with XML Schema in the traditional approach, is not part of the use case. XML Schema and RDFS/OWL are not comparable in this respect: XML Schema is used to define the structure (grammar) of data, while RDFS/OWL are used to describe the knowledge model (semantics, meaning) of data. In other words, the INSPIRE vocabularies will primarily focus on describing, not prescribing, the things within the INSPIRE domain of discourse. 4

5 Chapter 2 Issues This section describes the issues that must be addressed for creating INSPIRE RDF vocabularies. 2.1 External vocabularies One of the larger issues to consider is the use of external vocabularies. We discuss four more specific issues regarding this topic: - Which upper ontology should be used - External vocabularies that are used in the UML model but are not available in RDF - Methodology for reusing existing external vocabularies - Available external vocabularies for expressing geometry Which upper ontology? The first external vocabulary that should be considered, is an appropriate one that can function as an upper ontology for the INSPIRE RDF vocabulary. This could be, for example, ISO or the GeoSPARQL vocabulary. Another option is not to use an upper ontology. GeoSPARQL GeoSPARQL (Perry et al, 2010) is an OGC standard for representing and querying geospatial data on the Semantic Web. it defines a set of SPARQL extension functions for spatial queries, a set of RIF rules (Boley et al, 2013) for transforming simple topological relation tests into queries involving concrete geometries, and a core RDF/OWL vocabulary for geographic information. With regard to functioning as an upper ontology, the vocabulary is of interest. GeoSPARQL is based on accepted standards from the geospatial domain: the General Feature Model (ISO TC/211, 2005), Simple Features (ISO TC/211, 2004), Feature Geometry (ISO TC/211, 2003), and SQL MM (ISO/IEC, 2011). It defines three classes, SpatialObject, representing anything that can have a spatial representation [ Perry et al, 2010, p. 6], and its subclass Feature; and Geometry, representing the top-level geometry type. Also, several properties are defined for associating features with geometries and for recording metadata on geometries. In addition, it defines several sets of properties representing topological relations. ISO ISO is an ISO standard under development by ICO TC211. It gives the rules for developing geographic information ontologies in OWL. In annex D, a base ontology for geographic information is given. In chapter 7, some rules are given about mapping classes in an application schema to the ISO base ontology: - Classes with a stereotype <<FeatureType>>: o Sub class of iso :featuretype, o and sub class of iso :anyfeature. - There is no subclass mapping for classes with another or no stereotype. - Attributes with a stereotype <<estimated>>: sub property of iso :dpestimated datatype property or of iso :opestimated object property. - There is no sub property mapping for properties with another or no stereotype. The base ontology defines classes for stereotypes <<interface>>, <<datatype>>, ><<union>>, <<codelist>>, <<featuretype>>, and <<metaclass>>, and the base class <<anyfeature>>, in addition to the already mentioned properties for <<estimated>>, some annotation properties and a gcoliteral datatype. Conclusion Some practical considerations: ISO is in DIS status and has several outstanding comments in addition to one NO vote. GeoSPARQL is already a standard. Our suggestion is therefore to use the GeoSPARQL vocabulary, at least for now. 5

6 Classes with a stereotype <<FeatureType>> are therefore in our proposal mapped to the Feature class from GeoSPARQL Missing external vocabularies The INSPIRE model imports a lot of standardized information models, such as models from the ISO series, Observations and Measurements, etc. This presents a problem when translating the INSPIRE model to an RDF vocabulary: these external models are not available as RDF vocabularies. It is not really possible to solve this we need the official RDF vocabularies in order to model INSPIRE s relationship with them, but they are not available, so we cannot use them. At the expert meeting in Brussels on the 15 th of April, there was consensus that base types and models that are managed by other communities should not be modelled in the RDF vocabulary. Any solution we propose would therefore be a workaround. Several could be suggested: - Use the draft series ontologies. At present, there is work going on to create them as RDF vocabularies. As they evolve the INSPIRE vocabularies can use the latest version. How much maintenance work this involves depends on the versioning strategy of the draft ontologies: as long as the namespace is not changed and the names of classes and properties are stable, there is no impact on the INSPIRE vocabularies. This is only advisable if the versioning strategy of these draft ontologies ensures that neither the namespace nor the names of classes and properties will change during development. - Observations and Measurements: a possibility is to use the Semantic Sensor Network ontology (SSN) 1. This is not advisable since the SSN ontology is not standardized. - In the Building theme there is an informal relation with OGC CityGML. Although CityGML is not imported as a UML package, there is a clear semantic relation between classes and properties of the Building theme and the CityGML model. There is no official CityGML RDF vocabulary; however one has been created and made available by a research group from the university of Geneva 2. It is not advisable to use this CityGML vocabulary since it is not standardized. Our suggestion is not to use these vocabularies now. Any mappings we do make to standardized external vocabularies, are created in the form of triples with an INSPIRE term as subject, a predicate rdfs:subclassof rdfs:subpropertyof owl:equivalentclass owl:equivalentproperty, and a term from an external vocabulary as object. These can be added to the INSPIRE RDF vocabularies at a later time as additions (not changes) Reuse of existing vocabularies It is good practice in the linked data community to reuse existing vocabularies as this improves interoperability. Janowicz et al give vocabularies that reuse existing vocabularies 3 out of 5 stars in their proposed five star model for linked data vocabulary use (Janowicz et al, 2014). There are several external ontologies and vocabularies that are appropriate for reuse and relevant to the INSPIRE themes we have looked at: - GeoSPARQL - Dublin Core Terms - The GeoNames ontology - SKOS - Location Core vocabulary. Location Core defines the class Location (actually it reuses Dublin Core Location) which is a spatial region or a named place. Properties are defined not only for geometry but also for place names, place identifiers and for addresses. However the Location Core vocabulary is an ISA Programme final draft and a first version in the W3.org namespace. The terms in this vocabulary are indicated as testing and some as unstable. Therefore at this point in time we do not propose using it. Besides deciding which vocabularies the INSPIRE models should be mapped to, there is also the question of a methodology to express the mapping and implementing an automated translation of UML to RDFS/OWL that honours the mappings. In order to improve the UML model for better mapping to RDF we extend the

7 UML model by annotating the UML attributes that have a meaning which is standardized in some well-known vocabulary in RDF, with a link to their RDF counterpart. Classes can be annotated in the same way. The annotation is recorded in UML via a tagged value. For example, a geometry property in the UML model is given the following annotation: We extended ShapeChange with a few lines of code to transform such an annotation to a triple stating that :geometry is an equivalent property to geosparql:hasgeometry. Thus, the UML model is enriched with the mapping of classes and properties to existing OWL classes and properties with, for example, equivalentproperty and equivalentclass statements. Other mappings like rdfs:subpropertyof are also possible. The names of classes and properties as they are in the INSPIRE data specifications are retained, and knowledge of their meaning is added through their relations with terms from well-known vocabularies, allowing them to be understood in a wider context. General mappings must be defined for: inspireid beginlifespanversion endlifespanversion name See 2.5 for more on these general property mappings Geometry encoding A recent, thorough overview of ways to encode geometry in RDF can be found in S. Anastasiou et al, Another relevant overview is given in the Core vocabularies specification. It has a section on location, the Location Core Vocabulary, which was recently published as a W3C document (Perego et al, 2013). The Location Core Vocabulary defines three classes, Location, Address, and Geometry, and several properties for describing places in terms of their name, address or geometry. An early vocabulary for representing mapping/location data in RDF is W3C Basic Geo (Brickley, 2003). This vocabulary explicitly does not attempt to address many of the issues covered in the professional GIS world, notably by the Open Geospatial Consortium (OGC). Instead, [it] provides just a few basic terms that can be used in RDF (eg. RSS 1.0 or FOAF documents) when there is a need to describe latitudes and longitudes. When storing coordinates directly in RDF, Basic Geo is one of several options. These differ in what they offer, ranging from only lat/long point geometries, point line and surface geometries, topology, to the possibility to use any coordinate reference system. We give a short overview of the most well-known ones. W3C Basic Geo Basic Geo is a basic RDF vocabulary that provides the Semantic Web community with a namespace for representing lat(itude), long(itude) and other information about spatially-located things, using WGS84 as a reference datum. Although a W3C activity, this vocabulary is not a W3C standard nor is it in the process of becoming one. As is evident from the name, the vocabulary is very basic and has only classes for SpatialThing (similar to GML s Feature) and Point, and properties latitude, location, longitude, and altitude. It has no classes or properties for topology. Acceptance is high: it is used in both GeoNames and DBPedia, both in turn highly used data sets, and in web applications and services including Yahoo! Maps. W3C Basic Geo is too limited to use with INSPIRE data, because it only supports point geometries and no coordinate reference systems other than WGS84. There are already several vocabularies around that offer support for more geometry types. 7

8 GeoRSS GeoRSS can be used in RDF to make simple geographical assertions about objects. However, this is only applicable for GeoRSS Simple, not for its other available variant: the GML geometry encoding. GeoRSS Simple is a very basic format with point, line, box and polygon properties, and allows only WGS84. GeoRSS Simple is used in e.g. DBPedia and implemented in e.g. OpenLayers, GeoServer, Drupal, and the Google Maps API. Although it has support for more geometry types, it is still probably too limited for use with INSPIRE data because it only supports WGS84; also it is not a formalized standard. NeoGeo NeoGeo ( has different namespaces for features (spatial: and for geometry ( Geometries can have any format based on HTTP content negotiation. The vocabulary also has properties for modeling topological relations such as a city being part of a province, a country being externally connected to another, or disconnected, overlapping, containing, and (non)tangential proper part. It does not mention how to reference coordinate reference systems. The content of geometries can be represented in NeoGeo in different formats other than RDF, such as GML, KML or WKT. It then depends on these formats if it is possible to refer to the coordinate reference system that is used. NeoGeo is the result of a community effort, a VoCamp, and not maintained by a standards organization. The latest version is from GeoSPARQL The GeoSPARQL vocabulary allows two serializations for geometry, Well Known Text (WKT) and GML. WKT is a text based format for encoding geometries, defined in the Simple Features specification. It is not only used in RDF, but is supported in several spatial databases and APIs. It is supported in several RDF semantic stores with geospatial capabilities, such as Virtuoso and useekm. The WKT option in GeoSPARQL allows only simple feature geometry types, but this is still a wide range of geometry types such as points, curves, surfaces and geometry collections. The GeoSPARQL vocabulary defines a property aswkt in which a geometry can be recorded as a text value. It is possible to use any coordinate reference system (CRS); a reference to the used CRS is recorded with the coordinates. The GML option in GeoSPARQL allows all ISO spatial schema geometry types, which is a much wider range than the simple features allowed in WKT, including a lot of less commonly used types. The vocabulary defines a property asgml in which a geometry can be recorded as a GML literal, i.e. a geometry element from the GML schema can be embedded in the RDF. The GeoSPARQL asgml serialization is implemented in several tools, and is offered as an option to record geometry in several vocabularies, such as the Location Core Vocabulary. The Location Core Vocabulary also allows WKT. Since the INSPIRE data uses the ETRS89 coordinate reference system and not WGS84, and uses different geometry types, the best option is to use the GeoSPARQL vocabulary. WKT is preferred over the GML serialization option, as long as there is no need to go beyond simple feature geometry types. WKT is more compact than the GML serialization. 2.2 Real world things and spatial objects In the linked data community it is common to make a separation between real world things and the information you can get about these real world things over the internet. This distinction is in a lot of cases very intuitive once you think about it: a building is a real world thing, which can be given an identifier, as is done in the base registry for buildings and addresses in the Netherlands, for example. However if you would request this identifier from an online service, what is returned is not the building itself. The structure of bricks, concrete, etc. is not what you get. Instead you get an information page about the building. The difference seems to be clear, but still the discussion about this quickly gets philosophical. Besides the real building outside that you can touch, i.e. which manifests in time and space, there is also a record with information about the building in a (base) registry. This record is what gets represented as information on the internet. Are there then three layers? And what about things that only exist in the digital world, or on paper, such as planning zones? Are they real things? And if digital things are also real things, then does it follow that information pages on the internet are as well? And what if there is a digital thing before the 8

9 related real world thing is created? For example, a road s name is registered before the road is there; the road s geometry is also registered before it is realized in the real world. In the Netherlands we therefore decided that for now, we should only consider things that are kept in some register, and we should mint a URI for those. In practice often there are no registers of real world things with their thematic identifier, only registers of information resources, which are sometimes representations of physical things in time and space, and sometimes things that only exist in the digital world. A thematic identifier might exist and might be stored in the register, but often it will not. Also, it is quite common to have objects in different registers that are representations of the same real thing. In the Netherlands we came to the conclusion: no register? No identifier! Still, in cases where there IS a real world (physical) thing, it would be useful to represent this as a resource and link it to the digital representations that are there. The real world thing could be identified in many cases with a thematic identifier: a well-known code such as airport codes, road numbers etc. Properties of the real world thing and its versioned representation could be separated, for example by grouping each combination of real world thing and its representations into one named graph. The question is if this is feasible. In two much used geo-linked data resources, GeoNames and DBPedia, there seems to be a separation between the two. In the geo-information world, there has not been a clear separation between real world thing and representation. And as we ve seen, it is not always clear which is which. In the geo-information world, the spatial object thing is often an entity on a map, not a thing in the real (time and space) world, although it may represent a real thing. Recommendation: instead of giving a definitive answer now, experimentation should be done to study this question. 2.3 Simplification - Complex datatypes We propose simplified mappings for a small number of complex datatypes: - Geographical name: In our mapping of the Buildings theme we propose to simply map this to rdfs:label. For discussion see Date of construction/demolition/renovation, also from the Buildings theme: We propose to simplify these by mapping them to dcterms:date. For discussion see Voidability If voidability should be explicitly part of the ontology, it may require the definition of additional properties. We as experts were asked to prepare a modular proposal concerning voidability in their report. However, we leave this to the other experts. They have more knowledge of RDF, RDFS and OWL than we do. We have not come across any design patters for this in linked data. 2.5 Domain and ranges integrity constraints At the Brussels meeting the experts all agreed that the RDFS/OWL representation of the INSPIRE UML model should not exactly reproduce the frame-based, closed-world UML model from the standard, but rather be an open-world OWL representation. This affects property scoping and object property restrictions. The latter choice requires more interpretation during conversion. ISO states that OWL ontologies are complementary to UML static views and serve different purposes. (p. vii) The OWL representation of UML models as described in ISO is rather close to the closed-world view: properties belong to one specific class, and any property that is not defined as belonging to a class, cannot be used with that class. Whereas in an open world view properties are independent things that can be used to make a statement about a thing belonging to any class, and anyone can do this. In an open world view, anything that is not explicitly stated is unknown. ShapeChange at least the version we used in experiments concerning our methodology - produces a closed-world oriented representation of the UML in OWL. We prefer the open-world representation described by Cox (Cox, 2013), but nevertheless used ShapeChange in this experiment because it provides an automated approach which we could extend to support mapping annotations in the UML model. To be able 9

10 to create an open-world oriented ontology as representation of a UML model, an open-world mapping should be defined. ShapeChange can be modified to support this open-world mapping (but this is outside the scope of our experiments one of the other experts, CP, will do this). Open-world oriented mapping: Avoid use of domain and range; these are logical axioms that close the knowledge model. Model properties as independent of class. The class name should not be part of the property name (contrary to the rule in ISO par ). Handle name clashes with UML annotations when necessary. Some properties that have the same name but belong to different UML classes can be treated as the same, but others have class-dependent definitions. For these cases, the proper mapping can be configured in UML annotations. Do not map property cardinality restrictions. These can be left out, as they are not a mandatory part of the implementing rules. On modeling properties as independent of class, some more can be said. In our methodology using ShapeChange, each UML package is considered a name space and is translated to a separate RDF file with its own base URI. In our analysis of the Building theme we found that properties could be considered as independent on two levels: the global level or the package level. In the themes considered by us, there were no properties that were found to be class dependent even though they had the same name as other properties, but this might be encountered in other themes. Properties that are defined in the Generic Conceptual model should definitely be considered as global properties. Some other properties, like geometry, are expected to occur in a lot of themes and could also be considered as global. However, our proposal is to only do this for properties from the GCM. Properties that occur in different packages of the same theme and have the same name, should be made generic to that theme. In the case of the Buildings theme, these properties should be moved to the BuildingsBase namespace. We have not considered yet how to automate this. 2.6 Codelists Codelists are mapped to SKOS representations of the codelist. They are linked to properties using owl:oneof, as these are part of the implementing rules (although his is contrary to the open world view). The concept schemes (codelist) and concepts (codelist values) shall belong to a different namespace since they are managed by a different authority. The codelists need to be made available in SKOS. 2.7 UML modeling artifacts Some modelling conventions in UML result in sometimes awkward UML constructions. An example is the avoidance of multiple inheritance. In UML models multiple inheritance is allowed, but often viewed as unwanted. A result of this is often that classes have a number of properties that are exactly the same (often hard-copied from one class to the next). When this UML model gets mapped to OWL the awkwardness of the UML modelling is preserved (i.e. duplicate properties are created while there could have been just one) even in cases where these modelling conventions do not make any sense in the OWL domain and could be expressed in a better way in OWL, representing the real world more closely than is possible in UML. Some more examples: CityGML application domain extensions complex way of making a UML model open Hierarchical code lists Composition and aggregation: available in UML but not in OWL Association classes 10

11 It is unlikely that this, UML anomalies getting mapped to RDF instead of being fixed, can be fixed by extending the UML model. To examine this, the mapping must be analysed and case by case conclusions and recommendations given. For any of these UML anomalies that are encountered in the three INSPIRE themes assigned to me, case by case conclusions will be provided. Further reading: A Detailed Comparison of UML and OWL. Kilian Kiko and Colin Atkinson, Composition and aggregation Two UML constructs aggregation and composition - are encountered in all three themes we looked at, but are not translatable to OWL, as it does not feature predefined mereological relationship constructs in the knowledge representation ontology (Atkinson 2008). Composition is used in several INSPIRE themes, for example in the INSPIRE Building theme to model that a building consists of building parts, but also Statistical Units theme and the Environmental Monitoring Facilities theme. The recommended way to represent this in ISO is the same as with normal associations, annotated with an annotation property iso :aggregationtype with a value of partofcompositeaggregation. This does not seem entirely useful, because in this way the information that the association is of a special type, with special meaning, is not recorded as an axiom but as metadata. But then again, our aim is not to create an ontology that is useful for reasoning, so it is not a big problem. The added value of having this information at least available as an annotation, is that round tripping back from OWL to UML is possible. Note also that Dublin Core Terms has an object property dct:partof and its inverse dct:haspart. This is however not exactly what we need because it is meant to be applied on the data level, not the ontology level. A design pattern for composition using dct:haspart could be: (bui = INSPIRE Building Core vocabulary) bui:parts rdf:type dct:haspart ; rdf:type owl:objectproperty ; rdfs:range [ rdf:type owl:class ; bui:buildingpart ]. 2.8 Encoding Even though it is not within scope of this report, encoding of data instances with geometries is a topic on which useful guidance can be given. Within the Platform Implementatie Linked Open Data (PiLOD), we have gained insight and experience with the combination of GeoJSON and JSON-LD for the purpose of publishing linked geo-data in an easily consumable form. Recently, on January 16th, the W3C has published the JSON-LD recommendation. JSON-LD is a JSON encoding for Linked Data. It lets you add meaning to the terms and values in a JSON document. This is done inside object that is either referenced from or embedded inside the JSON document. Applications that are not aware of is, can simply ignore it while applications that are aware, can parse and gain knowledge on the semantics of the JSON data. Since in the geospatial domain (Geo)JSON is becoming increasingly popular and Linked Data is also a hot topic (at least in the Netherlands it is), the question also rises if JSON-LD and GeoJSON can be used together. We tried this in an experimental setup and successfully combined GeoJSON with JSON-LD. GeoJSON-LD could be the web-encoding for linked geospatial data; it could be direct output of (Geo)SPARQL or be used as output of specific APIs. 11

12 GeoJSON, an extension of JSON for geometry, is in our opinion good enough for a large number of use cases. In its favour, it is a lightweight encoding, and less verbose than XML encodings like GML. Support in existing software and platforms is pretty good 3. After adding to GeoJSON in our experiment, we found that GIS applications with no understanding of JSON-LD could still use the data. 3 GeoJSON support is mostly found in open source communities and web-applications and platforms. It is not that common in the most widely used desktop GIS software. 12

13 Chapter 3 Test with INSPIRE themes The following INSPIRE themes are part of this report: Buildings: core 2D and 3D Statistical Units: vector Environmental Monitoring Facilities 3.1 Buildings For the classes and properties specific to buildings, a mapping with CityGML can be made conceptually. This is a first stab at such a mapping (only looking at core 2D), without looking too closely as of yet to the definitions: INSPIRE CityGML AbstractConstruction - AbstractBuilding AbstractBuilding Building Building BuildingPart BuildingPart parts consistsofbuildingpart geometry2d - buildingnature function (sort of) currentuse usage numberofdwellings - numberofbuildingunits - numberoffloorsaboveground storeysaboveground conditionofconstruction - dateofconstruction yearofconstruction dateofdemolition yearofdemolition dateofrenovation - elevation - externalreference core:externalreference heigthaboveground measuredheight name - (gml:_feature/name) However, we cannot actually create this mapping, as there is no official CityGML vocabulary in RDF or OWL. An experimental one is available: Prof. Gilles Falquet from the University of Genève has done the translation mostly automatically. The OWL representation is available here: However, there is no information on the ontology available there, so whether the ontology is complete, stable, has known issues, etc. is unknown. We should not consider using this. We recommend to contact him and find out if he wants to standardize this, e.g. by donating it to the OGC. Then we wait until it becomes an OGC resource. Therefore, for now we have not mapped INSPIRE Buildings to CityGML. We do recommend pushing for it to become available, and defining and implementing this mapping once a CityGML ontology is available. The parts relationship between Building and BuildingPart is an example of a UML modeling artifact that cannot be directly mapped to RDFS/OWL, as no construct for this specific relation type exists (see 2.7.1). This is mapped to an owl:objectproperty. The fact that it is a composition relationship can be expressed as an annotation property, conform ISO (although this is not added in our current implementation). Next to consider is the geometry2d property. It has as type BuildingGeometry2D which has the following properties: 13

14 geo = geometry owl:equivalentproperty geo:hasgeometry referencegeometry if true then the geometry property should be mapped to geo:hasdefaultgeometry. horizontalgeometryreference - verticalgeometryreference - horizontalgeometryestimatedaccuracy - verticalgeometryestimatedaccuracy - The geometry property can simply be mapped to hasgeometry from GeoSPARQL. However, ideally we would want to map it to hasdefaultgeometry from the same vocabulary if another property, referencegeometry is true. We have no solution for this in our current implementation. The dateofconstruction,-demolition, and Renovation properties all have a datatype DateOfEvent. Our suggestion is that this should be mapped to Dublin Core terms. The W3C Time ontology could also be applied (the classes Instant and Interval, and the relations hasbeginning and hasend), but this is not a standard, only a working draft. W3C are considering action to move this forward as a recommendation (as was mentioned at the LGD14 workshop). Dublin Core Terms is a DCMI recommendation. dct = dateofconstruction,-demolition, Renovation rdfs:subpropertyof dct:date DateOfEvent datatype - anypoint - beginning - end - A dct:date is a point or period of time associated with an event in the lifecycle of the resource. The DateOfEvent datatype is therefore simplified by mapping it directly to dct:date. The elevation property has a datatype Elevation. There is no equivalent for this in GeoSPARQL or other vocabularies we can think of. No mapping therefore. elevation - elevationreference - elevationreferencesystem - value - externalreference can also be mapped to Dublin Core. Definition: A related resource that is referenced, cited, or otherwise pointed to by the described resource. Intended to be used with non-literal values, i.e. it s an object property. In the INSPIRE Buildings theme it is a datatype. externalreference informationsystem informationsystemname reference owl:equivalentproperty The datatype is a bit problematic because within the datatype, actually there are two resources being referenced: an information system and an item within this information system. In the core Buildings model (both in the 2D and the 3D package), Building and BuildingPart classes have the same attributes, which also have the same definitions. These can in the RDFS/OWL vocabulary each be 14

15 represented by one object property independent of either class. The class name should not be prefixed to the property name. The ShapeChange version we currently use generates two properties, in line with ISO : < a owl:datatypeproperty ; rdfs:domain bu-core2d:building ; rdfs:range < ; dc:description "2D or 2.5D geometric representation of the building."^^xsd:string. < a owl:datatypeproperty ; rdfs:domain bu-core2d:buildingpart ; rdfs:range < ; dc:description "2D or 2.5D geometric representation of the building part."^^xsd:string. What we want is this: < a owl:datatypeproperty ; rdfs:domain bu-core2d:buildingpart ; rdfs:range < ; dc:description "2D or 2.5D geometric representation of the building part."^^xsd:string. We suggest that this should be the default result of the automated UML to RDFS/OWL translation: properties in the same package with the same name are translated to just one property in that namespace. We see two feasible implementations of this in our methodology: 1. Make this the default behaviour, but make it configurable with a tagged value to indicate that an attribute should be treated as specific to the context of its class (in which case the class name is prepended to the property name in RDFS/OWL). 2. During the automated conversion, test if the definitions of attributes are the same. If so, translate them to one common property. However there are cases where the definitions slightly differ but can be considered the same. The second solution will only work in some cases. For example, the definitions of the property geometry2d in the core 2D package have the word building vs building part in the definition. Still, the geometry2d property can be considered to have the same meaning. Therefore we prefer the first solution. There is also the issue of the namespace. All properties that are generated for, in this case, the Building 2D and 3D core models, are in these three namespaces, based on the three packages in UML: This includes properties like inspireid and the lifecycle properties. We want these to be global properties, not properties within the context of a package. These could be annotated with a tagged value to indicate they must be treated as global (isglobal = true ). In that case they should be added to the namespace: (or something similar) Properties within a theme with the same name, like geometry2d in the Buildings theme, are considered as generic within that theme, instead of specific to the Core 2D and Core 3D packages. The desired translation is that these properties are moved to the BuildingsBase namespace, but we have not yet implemented this in our methodology. Another thing to consider are the Building and BuildingPart classes in the Core 2D resp. Core 3D packages. Can these in the RDF vocabulary, with an open world view and no validation goal in mind, be considered to be the same, or are they things with different meanings? We suggest they are not. The definition of these classes in the 2D and 3D packages are the same. The 3D Building and BuildingPart classes have more properties and different constraints, but they are still the same things. Therefore, these classes should each be mapped to just one owl:class and moved to BuildingsBase. Only the 2D and 3D specific properties and 15

16 datatypes should remain in the 2D Core and 3D Core namespaces. We have not yet implemented this in our methodology. The name property has as its type GeographicalName, a complex datatype. We can map it as a subproperty of rdfs:label, but in that case it becomes an annotation property under the rules of OWL-DL, and its value will be a string with possible language tag (a sub property of an annotation property cannot have another type). All the metadata about the name from the GeographicalName datatype is lost. Alternatively, we can retain the structure of GeographicalName and not map the property. The disadvantage of that is that in the RDF without a mapping to rdfs:label (or something else like dct:title), it will not be clear what the meaning of the property is. 3.2 Statistical units For the classes from the Statistical Units theme no mapping is provided besides the standard mapping to geo:feature for FeatureType stereotyped classes. For the properties we suggest the use of: gn = dct = geo = Note: the RDF Data Cube Vocabulary, which as of January 2014 is a W3C recommendation, should be mentioned here. It has some relevance to the Statistical Units theme. It does not have terms for describing statistical units, but is relevant for representing statistical data and perhaps also sensor data in a linked data context. Statistical units reused term from vocabulary StatisticalUnit - VectorStatisticalUnit - inspireid see elsewhere thematicid subproperty of dct:identifier country equivalent property gn:countrycode geographicalname see elsewhere validityperiod subproperty of dct:temporal referenceperiod subproperty of dct:temporal beginlifespanversion see elsewhere endlifespanversion see elsewhere geometry - evolutions - VectorStatisticalUnitGeometry datataype geometry equivalent property geo:hasgeometry geometrydescriptor - GeometryDescriptor datatype - geometrytype - mostdetailedscale - leastdetailedscale - AreaStatisticalUnit - areavalue note: uses Area datatype from ISO landareavalue livableareavalue lowers uppers tesselation predecessors dct:replaces/isreplacedby Note: this is problematic. The tagged value containing the mapping can only be placed on the 16

17 association itself, not on the source or target role. What we want is: - To translate predecessors and successors into a pair of OWL properties, with one being the inverse of the other. - To annotate predecessors with a mapping of dct:replaces, and to annotate successors with a mapping of dct:isreplacedby. This is not yet implemented in our methodology. A problem is that it is not possible to annotate source and target roles with tagged values. successors administrativeunits model as the inverse of predecessors see elsewhere The Statistical Units theme uses composition relations to model the fact that statistical units can be composed of other statistical units, and the fact that units together form a tessellation. Composition is not available in OWL. The recommended way to represent this in ISO is the same as with normal associations, annotated with an annotation property iso :aggregationtype with a value of partofcompositeaggregation. The part about Time, Evolutions, models events such as creation, deletion, splitting. The Evolution class itself is regarded as a FeatureType, although it does not have an inspireid. The initialunitversions and finalunitversions cannot be considered similar to dct:hasversion, because the semantics are different: these associations link to the old and new statistical units that were split, deleted, aggregated, etc in an evolution. Statistical units - evolution reused term from vocabulary Evolution - date dct:date evolutiontype - areavariation - populationvariation - units - initialunitversions - finalunitversions Environmental Monitoring Facilities For the classes from this theme no mapping is provided besides the standard mapping to geo:feature for FeatureType stereotyped classes. For the properties we suggest the use of: dct = geo = skos = The W3C Organization ontology4 was also briefly considered, for the class EnvironmentalMonitoringNetwork. However, although the definition suggests that something like an organization is meant, it does not seem to be exactly the same. 4 recommendation since January of this year. 17

18 The SSN ontology is relevant to the EF theme, but as SSN is not yet standardized we did not define mappings to SSN. EnvironmentalMonitoringFacility could, for example, perhaps be mapped to ssn:sensor or, since it could be a sensor, but also a platform, site, station, etc., a better match could be ssn:system. Only the properties for which we have defined a mapping are listed in the table below: Environmental Monitoring Facilities reused term from vocabulary AbstractMonitoringObject geometry geo:hasgeometry name rdfs:label additionaldescription rdfs:comment onlineresource dct:references supersedes dct:replaces supersededby dct:isreplacedby As is noted in 3.2, this is problematic as tagged values in UML cannot be placed on association target roles. broader, narrower It was considered to map this to skos:broader/narrower, however the meaning is not the same. In SKOS, what is meant is that terms or concepts from a taxonomy are broader or narrower. In the EF theme, what is meant is that monitoring facility can have parts or can host sensors which in turn are other facilities. It is thus similar to the parts relationship in the Buildings theme (see 3.1). EnvironmentalMonitoringFacility representativepoint relatedto operationalactivityperiod geo:hasgeometry skos:related dct:date AnyDomainLink comment rdfs:comment NetworkFacility linkingtime dct:temporal OperationalActivityPeriod activitytime dct:temporal EnvironmentalMonitoringActivity activitytime boundingbox dct:temporal geo:hasgeometry onlineresource Note that there is no property for a bounding box in GeoSPARQL. This property has therefore been mapped to the geo:hasgeometry property although this does not seem entirely appropriate. dct:reference ObservingCapability observingtime onlineresource dct:date dct:reference In the EF theme, association classes are used in several places. According to Atkinson 2008, this can be viewed as a representational shorthand. A construction like the association class is not directly available in 18

19 OWL. Atkinson et al suggest that a common solution for representing n-ary and association class relations in OWL is reification, i.e., the creation of an individual, which stands for an instance of the relation and relates the things that are involved in that instance of the relation. 19

20 Chapter 4 Overview of mapping rules Note The ShapeChange version used in our experiment does not yet support ISO nor does it support changes proposed by us, e.g. not using domain and range. No effort has been put into adding this support, assuming that one of the other experts (CP) will already do this. 20

21 UML RDFS/OWL Equals Remarks Differs Ignores with respect to ISO Package owl:ontology Equals. However, no annotation of the ontology is currently created by the automated mapping. This should be added in compliance with ISO Class owl:class Equals. However, in the current implementation: - it is not annotated with a skos:preflabel (no label is provided). - The definition is mapped to a dct:description property. The source of the definition is not provided, however, it is not present in the UML either. Stereotype - Ignores. The only exception is that based on stereotype <<FeatureType>> a class is defined as a subclass of Feature from the GeoSPARQL vocabulary. Attribute owl:datatypeproperty Differs. Annotations skos:preflabel, dc:source, or owl:objectproperty skos:definition are missing in the current implementation. Domain is set to the current class and range is set to a type from GML. This differs from what we want in the automated UML > OWL conversion, which is no domain and range. Enumerated type There are no enumerations in the test UML models. Code list skos:conceptscheme Differs. In ISO a code list is translated to an owl:class as a subclass of skos:concept, and as an instance of skos:conceptscheme and skos:collection Code list value skos:concept Differs. In ISO a value is also translated to a skos:concept, but in addition it is declared to be an instance of the class created for the code list. Union class There are no unions in the test UML models. Multiplicity - Differs. In ISO multiplicity is mapped to property restrictions owl:minqualifiedcardinality, owl:maxqualifiedcardinality, owl:qualifiedcardinality. In our proposed solution and in the current implementation multiplicity is not restricted in the OWL ontology. Generalization rdfs:subclassof Equals. Association owl:objectproperty Differs. In our current implementation this is incorrectly mapped to DatatypeProperty. Associations should be mapped to ObjectProperty, the same as is described in ISO , but without using domain and range (although range could be used in specific cases). 21

22 Aggregation No aggregation in the test models Constraint not mapped Differs. In ISO this is mapped to an annotation property. Tagged value not mapped Differs. In ISO these are mapped to either annotation properties (tagged values on Package level) or to datatype properties. 22

23 Chapter 5 Bibliography Athanasiou, S., Bezati, L., Giannopoulos, G.,Patoumpas, K. and Skoutas, D. (2013) GeoKnow - Making the Web an Exploratory for Geospatial Knowledge. Market and Research Overview. Atkinson, C. and Kiko, K. (2008) A Detailed Comparison of UML and OWL. Boley, H., Hallmark, G., Kifer, M., Paschke, A., Polleres, A. and Reynolds, D. (2013) RIF Core Dialect (Second Edition). W3C. Brickley, D. (2003) Basic Geo (WGS84 lat/long) Vocabulary. W3C. Cox, S. (2013) An explicit OWL representation of ISO/OGC Observations and Measurements. Proceedings of the 6th International Workshop on Semantic Sensor Networks, Vol-1063: ISO TC/211 - ISO 19107:2003. Geographic information - Spatial schema. ISO TC/211 - ISO 19109:2005. Geographic information -- Rules for application schema. ISO TC/211 - ISO :2004. Geographic information - Simple feature access - Part 1: Common architecture. ISO TC/211 - ISO/CD (2013). Geographic information - Ontology - Part 2: Rules for developing ontologies in the Web Ontology Language (OWL). (Draft International Standard) ISO/IEC (2011) Information technology Database languages SQL multimedia and application packages Part 3: Spatial. Janowicz, K., Hitzler, P., Admas, B., Kolas, D., and Vardeman II, C. Five Stars of Linked Data Vocabulary Use. Semantic Web (2014) 1-0. Perego, M. Lutz and P. Archer (2013). ISA Programme Location Core Vocabulary. W3C. [accessed 11 February 2014] Perry, M. and Herring, J. (2010) OGC GeoSPARQL - A Geographic Query Language for RDF Data. [accessed 11 February 2014] 23