Currently, UCO has made an initial design for representing locations. This design is not yet able to represent various forms of location as a single location, e.g., a geodetic, administrative or semantic representation of a single location will result in three different locations. At the same time, various initiatives exist that do provide these different representations, e.g., ISA Programme Location Core Vocabulary (LOCN), provide best practices about spatial data, e.g., Spatial Data on the Web Best Practices. Moreover, a suggestion for such a new design have been given but became buried in our previous Atlassian archive. This CP is created to combine those and other various demands about the identification and representation of a location into one Location resource.
In this CP, a location identifies the whereabouts of a fixed object. For mobile objects, which can be located at different locations over time, a temporal aspect is required for determining its location. That is out of scope for this CP, but is addressed in CP-410 (#410).
Requirements
Requirement 1 - Location as point or area
Allow for a spatial extent that represents a location that a physical object can be at, or in.
Requirement 1.1 - location as point
Support of the identification of a point. Despite the intrinsic area that, e.g., a house or city, encompasses, under this interpretation a location always identifies a point.
Requirement 1.2 - location as area
Support of the identification of an area. The shape of an area is implicit to the applied means of specification. Currently, the following shapes are requested:
A line
would have 2 connected points
A bounding box
would have 2 diagonally across points for a rectangular or square shape
would have 4 points for a box-like shape
A circle or oval
A circular geographic shape would have a center position and a radius.
An ellipse shape would have would have a center position and a major and minor radius.
A polygon
would consist of 3 or more connected points
Requirement 1.3 - Agnostic to representation
The location should remain agnostic to the form, structure or dimension(s) of the representation, in the sense that no particular representation is enforced when referring to a location.
Requirement 1.4 - Agnostic to resolution
No assumptions should be made about the resolution of the spatial extent, except for the fact that a location implies a certain size of the spatial extent, which might remain implicit.
Requirement 2 - Representation
A location resource is a means to identify the spatial extent (a point or area alike), and is not equivalent to the location itself. Separate the identification and the representation of a location, and allow at least three ways to represent a location: a place name, a geometrical structure or an address.
Requirement 2.1 - Semantic location
A place name, generalised as a semantic location, is a textual description, or name, or a domain-dependent code that describes the location.
Requirement 2.2 - Administrative location
An address, generalised as an administrative location, is a description that is dependent on a particular method or principle as applied by an organisation or domain administration, e.g.:
A geometrical structure applies a well-defined Geodetic grid (a map) as reference in which it specifies a 2- or 3-dimensional point (or area, but still identified as a point).
a Geodetic location resource will carry a denotation of the coordinate system (the grid) that it uses.
UCO will apply WGS84 as its default coordinate projection for representing positions.
a Geodetic location needs an indication of precision of positional data. This precision is directly related to the device and technology being used to determine the Geodetic location, if any.
UCO is not required to represent mountains, lakes, railway lines, and other land terrain features.
Requirement 3 - Relating locations to locations
UCO should be able to represent a relationship between two location objects, e.g.,:
“Joe’s Pizza is 2.5 driving miles from the user’s location at time t.”;
“Joe’s Pizza is 2.1 walking miles from the user’s location at time t.”;
""
UCO is not required to infer those relationships, e.g.:
infer the walking distance to Joe’s Pizza from the driving distance.
Requirement 3.1 - Absolute or relative locations
An absolute location denotes a representation that provides the position without depending on any other object other than a reference framework such as a grid or map. One single individual value that represents the position unequivocally.
A relative location denotes a representation that is dependent on another location, the latter representing a level of resolution that is too course to suffice. The relative location allows for a higher level of resolution, however, must be positioned in the right area indicated by the location is depends upon. Eventually, the last location that a relative location is dependent upon shall be an absolute location, in order to fix the highest level resolution location on some absolute position on earth. One so is able to build up a chain of relative locations in order to achieve the appropriate level of resolution to identify the position of the subjet location precisely enough. Note that this level of resolution (precision) is something different than the accuracy of the position. For instance, an absolute (administrative) location to identify the building, and another relative (semantic) location to reflect the position within that building, e.g., room 203; or two semantic positions that are relative to each other within the absolute building location: floor 5, room 203; or a geographical location (triangulation between identified WIFI hotspots) relative to the 2nd floor (semantic location) relative to the area of the left wing (semantic location) relative to Building 3A (semantic location) relative to the absolute (administrative) location for the campus of Hogwarts School of Witchcraft and Wizardry.
Requirement 3.2 - Find equivalence between different representations of locations
This relates to the requirement to infer that two representations refer to the same location.
Implicit equivalence
Infer that different representations exist for the same location resource.
All distinct representations that belong to a single location resource, carry an implicit equivalence between them. In such case, it should be possible to mechanically infer that the different representations refer to the same location resource, and therefore to the same spatial extent, agnostic to the resolution of each representation. For example:
To find Central Park, New York, NY, USA, one could find this from subject-attributed strings ”Σέντραλ Παρκ”@el AND “Central Park“@en (semantic location type) leading together to the resource ex:location_1;
Assume a third representation has been added to the location resource ex:location_1, https://sws.geonames.org/5112085/ (an administrative location), this will be presented as another query result.
Explicit equivalence
Allow 3rd-party services to find equivalences between distinct location resources.
When such representations are distributed over multiple location resources, we can only rely on a reverse geo-coding service, e.g., google maps geocoding API to map an address represented location to a geographic represented location, or a human-in-the-loop to explicitly identify the equivalence.
Risk / Benefit analysis
The above is a rework of the current design on UCO's location ontology. Its intention is to completely replace the current design.
Benefits
The new design is based on specific requirements that include, amongst others, freedom of location representation, freedom about the spatial extent that location refers to, acknowledging the existence of locations that are relative to other locations, acknowledging relations that exist between locations, and alignment to currently existing initiatives on representing locations in other domains.
This allows for a much broader application of location information, as well as making an as small as possible ontological commitment on the concept of location (allowing for a more general application).
Risks
Clearly, since this CP describes a complete overhaul of the location ontology, any data and adoption efforts that align to the current design on location, requires a significant update to become interoperable again with the standard.
Competencies demonstrated
Competency 1
Identify the location of a fixed object, e.g., a cell tower
Competency Question 1.1
What is the location of Cell Tower <#CT-12345>?
Result 1.1
<LocationID-1265> with its known representations, e.g.,
Semantic location: Holiday Inn Hotel Voorburg
Administrative location:
<observable:Address-1256314>
<https://w3w.co/volunteered.kinds.courtyard>
Geodetic location:
Lat: 52.065710075940174
Lon: 4.359169006347657
Elev: 21m
Reference coordinate system: WGS84
Competency 2
Get the objects that are located within an area
Competency Question 2.1
What known objects are located in/at <LocationID-1265>?
Result 2.1
Cell tower <#CT-12345>
Competency 3
Get alternative representations
Competency Question 3.1
What known representations exist for location Holiday Inn Hotel Voorburg?
Result 3.1
Administrative location:
<observable:Address-1256314>
<https://w3w.co/volunteered.kinds.courtyard>
Geodetic location:
Lat: 52.065710075940174
Lon: 4.359169006347657
Elev: 21m
Reference coordinate system: WGS84
Competency 4
Absolute and relative locations
Competency Question 4.1
To what absolute location is <LocationID-34092> ("room 5.203") relative?
Result 4.1
<LocationID-34092> ("room 5.203") of <LocationID-34080> ("5th floor") of <LocationID-34070> ("west wing") of <LocationID-34011> ("Building 3A") of <LocationID-34010> ("LAT 52.065710075940174; LON 4.359169006347657")
Requirements - Competencies XRef
In order to support completeness, the following matrix identifies the cross-references between requirements and competencies. Check that every column and every row has at least one ✔️.
Req.1.1
Req.1.2
Req.1.3
Req.1.4
Req.2.1
Req.2.2
Req.2.3
Req.3.1
Req.3.2
CQ1.1
✔️
CQ2.1
CQ3.1
✔️
CQ4.1
✔️
To Be Completed:
[ ] Clearly, more CQs are required in order to comprehensively address the requirements.
Much discussion is going on about the philosophical foundations that are grounding spatial concepts. We propose to take the pragmatic decision to follow the standing position on spatial concepts, which is that any physical resource fills a certain space somewhere on the globe, a.k.a. a concept has spatial extent, a.k.a. the location of an object. This inclines us to separate between the thing and the void that it fills.
The thing
Here we have to make a choice: do we allow each and every thing to potentially occupy a void, or do we consider such a characteristic to belong to specific things only?
If we want to align with W3C-SDW-BP we must incorporate SpatialThing as a specialisation of, e.g., uco-obs:Observable. However, this makes a commitment that we think is not relevant in the context of SDO, being the distinction between things that potentially can occupy a space and those things that cannot ever occupy a space.
When we simply provide for the capability to add a location to, e.g., uco-obs:Observable, without enforcing that relation to exist, we effectively realise that every Observable can potentially be occupying a void; when it does, it clearly has a location and when it doesn't, it doesn't.
Note that option 2 implies that no distinction can be made between unknown at this moment, irrelevant to be known, not registered yet, and unable to occupy a space. Since no competency asks for this, we consider this distinction irrelevant. Another consequence of option 2 is that literally everything that is considered a, e.g., uco-obs:Observable, abstract, physical or fictional alike, can be given a location.
👎 The consequence for the choice of uco-obs:Observable is that there are specialisations of it that definitely cannot occupy a void, impeding option 2 and directing us to adopt option 1.
We propose to implement option 2: allow rather then enforce a relation between a thing and the void it potentially occupies. In this way, when a location is added to a thing, the semantics of that particular thing (a specialisation of, e.g., uco-obs:Observable) conceptually includes the definition of sdw-bp's SpatialThing.
The void
We consider the void only of interest when it provides us with the whereabouts of a thing. That means that a void won't exist on its own (see next section). However, the intention of the void is to identify the whereabouts of something, and we therefore propose the void to be denoted a uco-loc:Location.
Since the representation of a uco-loc:Location should be agnostic to the uco-loc:Location itself, we propose that whenever we refer to a uco-loc:Location, we refer to a URI. This implies that we can refer to a Location without having any representation of it (yet).
The relation between the thing and its Location
We consider the particular space that is being filled by the thing inherently dependent on the thing. This is in line with the above: whenever we want to identify a certain void as the Location of a thing, we can create a resource representing that void. Vice versa, we are not interested in identifying a Location if it's not referring to the whereabouts of a thing.
We propose that in order to exist, a location must inhere in its bearer - the thing. We furthermore propose that the thing and its uco-loc:Location be disjoint, in order to underline their distinctness.
Representing locations
It must be possible to apply different representations for a specific uco-loc:Location (see Requirement 1.3). We propose to separate a chosen representation from the uco-loc:Location. In that sense, we consider the representations to be a particular structuration of the Location, because depending on the type of representation it will be structured differently.
We propose to loosely align with the W3 Location Core Vocabulary and recognise three principled ways to represent a location:
The Location Core Vocabulary acknowledges representation by a place name through dcterms:Location, a geometrical structure through locn:Geometry or an address through locn:Address, conveniently in line with the required competencies (CQ 3.1) about, respectively, a semantic location, a geodetical location and an administrative location. The disjunctive union of these three principled types of location structures, then, applies as representation for a uco-loc:Location.
We propose the following structuration:
uco-loc:SemanticDimension: a string, providing a textual description, or name, or a domain-dependent code that describes the location;
uco-loc:AdministrativeDimension: we might reuse the current uco-obs:Address object, which is admittedly more limited in its capabilities to represent the administrative dimension. However, it might provide for a quick start and can be changed and extended in a later stage.
Note the differences in naming between our conceptualisation and W3 Location Core Vocabulary's representation; note that the structuration of our conceptualisation is different as well:
We propose that a particular Location can be represented in more than one way in order to allow for various representations for one Location (Requirement 1.3). For example, consider Amsterdam Schiphol Airport that can be represented by at least the following three representations:
semantically: "Amsterdam Schiphol Airport“@en, or each and any of the following 4 random alternatives: "Schiphol Luchthaven"@nl, "AMS"@iata, "EHAM"@icao. All are different semantic representations for the same position;
geodetically: specified by locn:Geometry as a point, line, polygon, etc. expressed using coordinates in some coordinate reference system, i.e., a coordinate tuple (x, y) in a 2D plane against a certain reference system: (52.3103, 4.76028), or (N 52° 18' 37'', E 4° 45' 37''); similarly (x, y, z) in 3D space. Indeed the reference system must be included;
administratively: an address, which can vary between a postal code, e.g., "NL-1118ZG", or an n-ary <streetname, streetnumber, city> relation, or an url "https://www.geonames.org/6296680".
We propose to make use of SKOS where particular codes are already available (inter)nationally and where identical Positions are encoded differently, e.g., IATA vs ICAO in our example above.
One Location object allows for coalescing values for the three different representations (administrative, semantic, and cartographic data) together. This meets with the mapping competency above.
Equivalency of representations
Since one location can refer to various representations, each representation for a location is considered equivalent to the other representations of that location. Consequently, CQ 3.1 can be met with a query that collects all representations for a location.
Since a representation can be used for multiple locations, CQ 2.1 can be met with a query that collects the locations that refer, either directly to a single representation, or indirectly through equivalent representations (CQ 3.1).
Summarising graph
Please ignore for this moment the <<stereotyping>> that is applied. Regarding the multiplicity, note the following:
A thing is not deemed to have a location;
A location can only inhere in a thing, and cannot exist on its own;
A representation must be used for at least one uco-loc:Location; this reflects our constraint that a location representation is exactly that: something to represent a location. We deny the existence of a location representation without a location that it represents;
A uco-loc:Location can apply more representations:
A location can be instantiated without its representation;
A location can be represented by more than one location representation of a single structuration, i.e., more [ semantic | administrative | geodetic ] location representations can exist;
A location can be represented by more that one location representation, irrespective its type.
Additional notes:
The graph does only reflect the disjointness between the location and the thing implicitly;
All representations are considered equivalent values for the same location.
Namespace
As part of the solution, the suggestion is to make a complete overhaul of the uco-location namespace.
Background
Currently, UCO has made an initial design for representing locations. This design is not yet able to represent various forms of location as a single location, e.g., a geodetic, administrative or semantic representation of a single location will result in three different locations. At the same time, various initiatives exist that do provide these different representations, e.g., ISA Programme Location Core Vocabulary (LOCN), provide best practices about spatial data, e.g., Spatial Data on the Web Best Practices. Moreover, a suggestion for such a new design have been given but became buried in our previous Atlassian archive. This CP is created to combine those and other various demands about the identification and representation of a location into one
Locationresource.In this CP, a location identifies the whereabouts of a fixed object. For mobile objects, which can be located at different locations over time, a temporal aspect is required for determining its location. That is out of scope for this CP, but is addressed in CP-410 (#410).
Requirements
Requirement 1 - Location as point or area
Allow for a spatial extent that represents a location that a physical object can be at, or in.
Requirement 1.1 - location as point
Support of the identification of a point. Despite the intrinsic area that, e.g., a house or city, encompasses, under this interpretation a location always identifies a point.
Requirement 1.2 - location as area
Support of the identification of an area. The shape of an area is implicit to the applied means of specification. Currently, the following shapes are requested:
Requirement 1.3 - Agnostic to representation
The location should remain agnostic to the form, structure or dimension(s) of the representation, in the sense that no particular representation is enforced when referring to a location.
Requirement 1.4 - Agnostic to resolution
No assumptions should be made about the resolution of the spatial extent, except for the fact that a location implies a certain size of the spatial extent, which might remain implicit.
Requirement 2 - Representation
A location resource is a means to identify the spatial extent (a point or area alike), and is not equivalent to the location itself. Separate the identification and the representation of a location, and allow at least three ways to represent a location: a place name, a geometrical structure or an address.
Requirement 2.1 - Semantic location
A place name, generalised as a semantic location, is a textual description, or name, or a domain-dependent code that describes the location.
Requirement 2.2 - Administrative location
An address, generalised as an administrative location, is a description that is dependent on a particular method or principle as applied by an organisation or domain administration, e.g.:
Requirement 2.3 - Geodetic location
A geometrical structure applies a well-defined Geodetic grid (a map) as reference in which it specifies a 2- or 3-dimensional point (or area, but still identified as a point).
Requirement 3 - Relating locations to locations
UCO should be able to represent a relationship between two location objects, e.g.,:
UCO is not required to infer those relationships, e.g.:
Requirement 3.1 - Absolute or relative locations
Requirement 3.2 - Find equivalence between different representations of locations
This relates to the requirement to infer that two representations refer to the same location.
Implicit equivalence
Infer that different representations exist for the same location resource.
All distinct representations that belong to a single location resource, carry an implicit equivalence between them. In such case, it should be possible to mechanically infer that the different representations refer to the same location resource, and therefore to the same spatial extent, agnostic to the resolution of each representation. For example:
”Σέντραλ Παρκ”@elAND“Central Park“@en(semantic location type) leading together to the resourceex:location_1;ex:location_1,https://sws.geonames.org/5112085/(an administrative location), this will be presented as another query result.Explicit equivalence
Allow 3rd-party services to find equivalences between distinct location resources.
When such representations are distributed over multiple location resources, we can only rely on a reverse geo-coding service, e.g., google maps geocoding API to map an address represented location to a geographic represented location, or a human-in-the-loop to explicitly identify the equivalence.
Risk / Benefit analysis
The above is a rework of the current design on UCO's location ontology. Its intention is to completely replace the current design.
Benefits
The new design is based on specific requirements that include, amongst others, freedom of location representation, freedom about the spatial extent that location refers to, acknowledging the existence of locations that are relative to other locations, acknowledging relations that exist between locations, and alignment to currently existing initiatives on representing locations in other domains.
This allows for a much broader application of location information, as well as making an as small as possible ontological commitment on the concept of location (allowing for a more general application).
Risks
Clearly, since this CP describes a complete overhaul of the location ontology, any data and adoption efforts that align to the current design on location, requires a significant update to become interoperable again with the standard.
Competencies demonstrated
Competency 1
Identify the location of a fixed object, e.g., a cell tower
Competency Question 1.1
What is the location of Cell Tower
<#CT-12345>?Result 1.1
<LocationID-1265>with its known representations, e.g.,Holiday Inn Hotel Voorburg<observable:Address-1256314><https://w3w.co/volunteered.kinds.courtyard>52.0657100759401744.35916900634765721mWGS84Competency 2
Get the objects that are located within an area
Competency Question 2.1
What known objects are located in/at
<LocationID-1265>?Result 2.1
Cell tower
<#CT-12345>Competency 3
Get alternative representations
Competency Question 3.1
What known representations exist for location
Holiday Inn Hotel Voorburg?Result 3.1
<observable:Address-1256314><https://w3w.co/volunteered.kinds.courtyard>52.0657100759401744.35916900634765721mWGS84Competency 4
Absolute and relative locations
Competency Question 4.1
To what absolute location is
<LocationID-34092> ("room 5.203")relative?Result 4.1
<LocationID-34092> ("room 5.203")of<LocationID-34080> ("5th floor")of<LocationID-34070> ("west wing")of<LocationID-34011> ("Building 3A")of<LocationID-34010> ("LAT 52.065710075940174; LON 4.359169006347657")Requirements - Competencies XRef
In order to support completeness, the following matrix identifies the cross-references between requirements and competencies. Check that every column and every row has at least one ✔️.
To Be Completed:
Solution suggestion
We base our proposed solution on the Spatial Data on the Web Best Practices - W3C Working Group Note 28 September 2017.
To Be Completed:
Namespaces
The following namespaces apply in our proposed solution:
uco-obshttps://ontology.unifiedcyberontology.org/uco/observable/uco-lochttps://ontology.unifiedcyberontology.org/uco/location/locnhttp://www.w3.org/ns/locn#dctermshttp://purl.org/dc/terms/rdfshttp://www.w3.org/2000/01/rdf-schema#The thing and the void it occupies
Much discussion is going on about the philosophical foundations that are grounding spatial concepts. We propose to take the pragmatic decision to follow the standing position on spatial concepts, which is that any physical resource fills a certain space somewhere on the globe, a.k.a. a concept has spatial extent, a.k.a. the location of an object. This inclines us to separate between the thing and the void that it fills.
The thing
Here we have to make a choice: do we allow each and every thing to potentially occupy a void, or do we consider such a characteristic to belong to specific things only?
SpatialThingas a specialisation of, e.g.,uco-obs:Observable. However, this makes a commitment that we think is not relevant in the context of SDO, being the distinction between things that potentially can occupy a space and those things that cannot ever occupy a space.uco-obs:Observable, without enforcing that relation to exist, we effectively realise that every Observable can potentially be occupying a void; when it does, it clearly has a location and when it doesn't, it doesn't.Note that option 2 implies that no distinction can be made between unknown at this moment, irrelevant to be known, not registered yet, and unable to occupy a space. Since no competency asks for this, we consider this distinction irrelevant. Another consequence of option 2 is that literally everything that is considered a, e.g.,
uco-obs:Observable, abstract, physical or fictional alike, can be given a location.👎 The consequence for the choice of
uco-obs:Observableis that there are specialisations of it that definitely cannot occupy a void, impeding option 2 and directing us to adopt option 1.We propose to implement option 2: allow rather then enforce a relation between a thing and the void it potentially occupies. In this way, when a location is added to a thing, the semantics of that particular thing (a specialisation of, e.g.,
uco-obs:Observable) conceptually includes the definition of sdw-bp's SpatialThing.The void
We consider the void only of interest when it provides us with the whereabouts of a thing. That means that a void won't exist on its own (see next section). However, the intention of the void is to identify the whereabouts of something, and we therefore propose the void to be denoted a
uco-loc:Location.Since the representation of a
uco-loc:Locationshould be agnostic to theuco-loc:Locationitself, we propose that whenever we refer to auco-loc:Location, we refer to a URI. This implies that we can refer to aLocationwithout having any representation of it (yet).The relation between the thing and its
LocationWe consider the particular space that is being filled by the thing inherently dependent on the thing. This is in line with the above: whenever we want to identify a certain void as the
Locationof a thing, we can create a resource representing that void. Vice versa, we are not interested in identifying aLocationif it's not referring to the whereabouts of a thing.We propose that in order to exist, a location must inhere in its bearer - the thing. We furthermore propose that the thing and its
uco-loc:Locationbe disjoint, in order to underline their distinctness.Representing locations
It must be possible to apply different representations for a specific
uco-loc:Location(see Requirement 1.3). We propose to separate a chosen representation from theuco-loc:Location. In that sense, we consider the representations to be a particular structuration of theLocation, because depending on the type of representation it will be structured differently.We propose to loosely align with the W3 Location Core Vocabulary and recognise three principled ways to represent a location:
The Location Core Vocabulary acknowledges representation by a place name through
dcterms:Location, a geometrical structure throughlocn:Geometryor an address throughlocn:Address, conveniently in line with the required competencies (CQ 3.1) about, respectively, a semantic location, a geodetical location and an administrative location. The disjunctive union of these three principled types of location structures, then, applies as representation for auco-loc:Location.We propose the following structuration:
uco-loc:SemanticDimension: a string, providing a textual description, or name, or a domain-dependent code that describes the location;uco-loc:GeodeticDimension: aligns with sdw-bp's geometry object as "An ordered set of n-dimensional points in a given coordinate reference system; can be used to model the spatial extent or shape of a Spatial Thing."uco-loc:AdministrativeDimension: we might reuse the currentuco-obs:Addressobject, which is admittedly more limited in its capabilities to represent the administrative dimension. However, it might provide for a quick start and can be changed and extended in a later stage.Note the differences in naming between our conceptualisation and W3 Location Core Vocabulary's representation; note that the structuration of our conceptualisation is different as well:
rdfs:Resourceuco-loc:Locationdcterms:Locationuco-loc:SemanticDimensionlocn:Geometryuco-loc:GeodeticDimensionlocn:Addressuco-loc:AdministrativeDimensionWe propose that a particular
Locationcan be represented in more than one way in order to allow for various representations for oneLocation(Requirement 1.3). For example, consider Amsterdam Schiphol Airport that can be represented by at least the following three representations:locn:Geometryas a point, line, polygon, etc. expressed using coordinates in some coordinate reference system, i.e., a coordinate tuple (x, y) in a 2D plane against a certain reference system: (52.3103, 4.76028), or (N 52° 18' 37'', E 4° 45' 37''); similarly (x, y, z) in 3D space. Indeed the reference system must be included;We propose to make use of SKOS where particular codes are already available (inter)nationally and where identical Positions are encoded differently, e.g., IATA vs ICAO in our example above.
One
Locationobject allows for coalescing values for the three different representations (administrative, semantic, and cartographic data) together. This meets with the mapping competency above.Equivalency of representations
Since one location can refer to various representations, each representation for a location is considered equivalent to the other representations of that location. Consequently, CQ 3.1 can be met with a query that collects all representations for a location.
Since a representation can be used for multiple locations, CQ 2.1 can be met with a query that collects the locations that refer, either directly to a single representation, or indirectly through equivalent representations (CQ 3.1).
Summarising graph
Please ignore for this moment the
<<stereotyping>>that is applied. Regarding the multiplicity, note the following:uco-loc:Location; this reflects our constraint that a location representation is exactly that: something to represent a location. We deny the existence of a location representation without a location that it represents;uco-loc:Locationcan apply more representations:Additional notes:
Namespace
As part of the solution, the suggestion is to make a complete overhaul of the
uco-locationnamespace.References
[ISA-LOCN]
ISA Programme Location Core Vocabulary (LOCN)
[ISO-19101]
ISO 19101-1:2014 Geographic information -- Reference model -- Part 1: Fundamentals. ISO/TC 211. ISO. 15 November 2014. URL: https://www.iso.org/standard/59164.html
[W3C-SDW-BP]
Spatial Data on the Web Best Practices. W3C Working Group Note 28 September 2017.
Coordination