Redesign the Location representation to become interoperable with more widely accepted initiatives

[plbt5]

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 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 physical (street) address
• a PO Box address
• a business address
• a billing address
• a mailing address (not an email, but snail mail)
• a resolvable URL, e.g., as geoname or what3words

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).

• 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.

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:

• Add solutions for each additional CQ

Namespaces

The following namespaces apply in our proposed solution:

Prefix	Namespace IRI
uco-obs	https://ontology.unifiedcyberontology.org/uco/observable/
uco-loc	https://ontology.unifiedcyberontology.org/uco/location/
locn	http://www.w3.org/ns/locn#
dcterms	http://purl.org/dc/terms/
rdfs	http://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?

1. 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.
2. 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:

1. uco-loc:SemanticDimension: a string, providing a textual description, or name, or a domain-dependent code that describes the location;
2. 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."
3. 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:

W3 Location Core Vocabulary	UCO
rdfs:Resource	uco-loc:Location
dcterms:Location	uco-loc:SemanticDimension
locn:Geometry	uco-loc:GeodeticDimension
locn:Address	uco-loc:AdministrativeDimension

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:

1. 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;
2. 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;
3. 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.

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

• Tracking in Jira ticket OC-250

• Administrative review completed, proposal announced to Ontology Committees (OCs) on 2022-07-27
• Requirements to be discussed in OC meeting, 2022-07-28
• Requirements to be discussed further in OC meeting, 2022-08-09
• Requirements Review vote has not occurred

• Requirements development phase completed.
• Solution announced to OCs on (TODO-date)
• Solutions Approval to be discussed in OC meeting, date TBD
• Solutions Approval vote has not occurred

• Solutions development phase completed.
• Implementation has not been merged into develop

• Milestone linked
• Documentation logged in pending release page

[ajnelson-nist]

@plbt5 : Requirement 2.3, and 3, currently refer to CASE as the provider of these requirements. This proposal is supposed to be scoped to the broader UCO, not just CASE. Are you OK making those corrections?

[ajnelson-nist]

The proposal makes reference to locn, which is not in a "Stable" (esp. W3C Recommendation-level) status. Does the proposal intend to make a parallel and independent set of classes in order to align with the general shape of locn, or does the proposal intend to do a "Zippering" subclass model that defines UCO classes as subclasses of both UcoObject and locn concepts?

I think this proposal will be influenced by how well it aligns with available data. For reference, the geonames.org page for Schiphol Airport reads like this when converted to Turtle (apologies if some of the UTF-8 doesn't survive my copy-paste):

@prefix cc: <http://creativecommons.org/ns#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix gn: <http://www.geonames.org/ontology#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix wgs84_pos: <http://www.w3.org/2003/01/geo/wgs84_pos#> .
@prefix xs: <http://www.w3.org/2001/XMLSchema#> .

<https://sws.geonames.org/6296680/>
	a gn:Feature ;
	gn:alternateName
		"Aeropuerto de Ámsterdam-Schiphol"@es ,
		"Amsterdam Airport Schiphol"@en ,
		"Amsterdam-Schiphol-flygplatsen"@sv ,
		"Aéroport d'Amsterdam-Schiphol"@fr ,
		"Flughafen Schiphol"@de ,
		"Luchthaven Schiphol"@nl ,
		"Schiphol Luchthaven"@nl ,
		"Schiphol-Rijk" ,
		"Schipholin kansainvälinen lentoasema"@fi ,
		"Διεθνές Αεροδρόμιο Σκίπχολ"@el ,
		"Аеропорт «Схіпгол»"@uk ,
		"Амстердамский аэропорт Схипхол"@ru ,
		"נמל התעופה סכיפהול"@he ,
		"فرودگاه اسخیپول آمستردام"@fa ,
		"مطار سخيبول أمستردام"@ar ,
		"अ‍ॅम्स्टरडॅम विमानतळ श्चिफोल"@mr ,
		"शिफोल विमानस्थल"@new ,
		"शिफोल हवाई अड्डा"@hi ,
		"ஆம்ஸ்டர்டம் வானூர்தி நிலையம் ஸ்கைபோல்"@ta ,
		"ท่าอากาศยานอัมสเตอร์ดัมสชิปโฮล"@th ,
		"アムステルダム・スキポール空港"@ja ,
		"阿姆斯特丹史基浦機場"@yue ,
		"스히폴 국제공항"@ko
		;
	gn:countryCode "NL" ;
	gn:featureClass <https://www.geonames.org/ontology#S> ;
	gn:featureCode <https://www.geonames.org/ontology#S.AIRP> ;
	gn:locationMap <https://www.geonames.org/6296680/amsterdam-airport-schiphol.html> ;
	gn:name "Amsterdam Airport Schiphol" ;
	gn:nearbyFeatures <https://sws.geonames.org/6296680/nearby.rdf> ;
	gn:parentADM1 <https://sws.geonames.org/2749879/> ;
	gn:parentADM2 <https://sws.geonames.org/2754999/> ;
	gn:parentCountry <https://sws.geonames.org/2750405/> ;
	gn:parentFeature <https://sws.geonames.org/2754999/> ;
	gn:shortName "Schiphol" ;
	gn:wikipediaArticle <https://en.wikipedia.org/wiki/Amsterdam_Airport_Schiphol> ;
	rdfs:isDefinedBy <https://sws.geonames.org/6296680/about.rdf> ;
	rdfs:seeAlso <https://dbpedia.org/resource/Amsterdam_Airport_Schiphol> ;
	wgs84_pos:alt "-3" ;
	wgs84_pos:lat "52.3103" ;
	wgs84_pos:long "4.76028" ;
	.

<https://sws.geonames.org/6296680/about.rdf>
	a foaf:Document ;
	cc:attributionName "GeoNames"^^<https://www.w3.org/2001/XMLSchema#string> ;
	cc:attributionURL <https://www.geonames.org> ;
	cc:license <https://creativecommons.org/licenses/by/4.0/> ;
	dcterms:created "2006-10-28"^^<https://www.w3.org/2001/XMLSchema#date> ;
	dcterms:modified "2022-03-22"^^<https://www.w3.org/2001/XMLSchema#date> ;
	foaf:primaryTopic <https://sws.geonames.org/6296680/> ;
	.

Nixing the rdfs:-, foaf:-, gn:- and cc:-prefixed concepts, we see what's left is some wgs84 annotations that can be pulled into representing a geodetic location. A semantic location representation has ample names to draw on using gn:alternateName.

@plbt5, can you please include an example of how <https://sws.geonames.org/6296680/> would become a UCO Location object(s) under this proposal?

(Also, apparently, there's a prefix bug in the data where an https snuck in to xs:. It's not terribly important for us at this moment, though anybody should feel encouraged to file a bug report with geonames.)

Here is the reduced Turtle snippet:

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix wgs84_pos: <http://www.w3.org/2003/01/geo/wgs84_pos#> .
@prefix xs: <http://www.w3.org/2001/XMLSchema#> .

<https://sws.geonames.org/6296680/>
	wgs84_pos:alt "-3" ;
	wgs84_pos:lat "52.3103" ;
	wgs84_pos:long "4.76028" ;
	.

<https://sws.geonames.org/6296680/about.rdf>
	dcterms:created "2006-10-28"^^<https://www.w3.org/2001/XMLSchema#date> ;
	dcterms:modified "2022-03-22"^^<https://www.w3.org/2001/XMLSchema#date> ;
	.

[ajnelson-nist]

I see references to dcterms:Location included in this proposal. We should be aware that Dublin Core Terms is not compatible with OWL 2 DL, to this extent: It cannot be imported in entirety, but we can import individual concepts such as dcterms:Location. (dcterms includes in its data model some rdf:Propertys that permit both thing and string, which is incompatible with OWL's disjointedness of DatatypeProperty and ObjectProperty.)

[ajnelson-nist]

Competency 2 should refer to the "Location review" section of the Cell Site CASE example, especially kb:location-403d0147-f7ff-4f3e-aa43-19a988e8a3ee.

[ajnelson-nist]

My last remark today, probably:
@plbt5 , we have already held a Requirements Review vote that covers most of this Issue. As you noted in the Issue Background, that vote was a while ago and semi-lost to time. Is this Issue still close enough to the contents of the proposal in Confluence that we can "Pick it up" at Solutions Development, with the solution incorporating replacement of UCO's location ontology?

[plbt5]

Three changes have occurred: There has been a slight progression in thinking since the proposal in Confluence was authored about representation. The confluence proposal provided an additional `Position` concept in between the `Location` and its representations. This concept has been removed from the current proposal since (i) I couldn't find a requirement for its existence, and (ii) conflating all representations directly into one `Location` simplifies the artefact and its application in queries without introducing limitations. Furthermore the temporal requirements that have been addressed in the Confluence proposal has been moved to Issue #410, which is still under construction. Finally, I removed the `Place` as specialisation to an abstract `Location` in favour of turning the latter into a non-abstract concept. With that change, we gain the opportunity as described in option 2 under section The Thing: it is not required anymore to always position a thing at a location, because less ontological commitment is better. Apart from that, the change simplifies the artefact and its application in queries without introducing limitations.

…

-- Paul

On 27 Jul 2022, at 15:42, Alex Nelson ***@***.***> wrote: My last remark today, probably: @plbt5 <https://github.com/plbt5> , we have already held a Requirements Review vote that covers most of this Issue. As you noted in the Issue Background, that vote was a while ago and semi-lost to time. Is this Issue still close enough to the contents of the proposal in Confluence that we can "Pick it up" at Solutions Development, with the solution incorporating replacement of UCO's location ontology? — Reply to this email directly, view it on GitHub <#409 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACAWGQMVSPXCV3H4RDCRDXTVWE4DDANCNFSM52KCZDHA>. You are receiving this because you were mentioned.

[ajnelson-nist]

Three changes have occurred: ...

Thanks for the clarifications!

[sbarnum]

I do not see any rational basis for the proposed change in this CP.

The current design fully supports all identified requirements and competencies identified in the CP.
The current implementation either fully or partially supports all identified requirements with the exception of Req 1.2 which has already been discussed in depth and could easily be added to the current design.

If there are any specific required cases/examples that are believed to not be supported by the current design I believe they would need to be provided before any such major overhaul could be considered.

There are certainly areas where the expressivity of the current implementation should be extended (geo regions/shapes, other coordinate system characterizations, more complete administrative characterizations beyond the current SimpleAddress facet, etc.) but these can all be easily added to the current design that is the result of years of consideration and work and has not yet been shown to be inadequate or broken. I see nothing in this CP to indicate or identify anything inadequate or broken in the current design. It simply talks about the current design as if this is true without any specific detail or evidence.

I would assert that this CP does not provide any reasonable rationale for considering the Solution Suggestion as all of the identified requirements and competencies are already met.

That being said, I do think it is important to express my complete disagreement with one key portion of the Solution Suggestion section as it is in complete contradiction to one of UCO's most fundamental design tenets, that all objects should be represented independent of context and that context should be applied through Relationships between objects.
This tenet allows the graph to function effectively.

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.

Not only should we not require such inherent conflation but I would assert that we MUST NOT support it as it breaks down the fundamental value of the graph.
The purpose of a Location is not solely to "provide us with the whereabouts of a thing".
Any Location is a location independent of any other objects. The Location is the location if no objects are present, if many objects are present, if some objects are present at some time and other objects present at another. The existence and global relevance of the Location has nothing to do with any specific physical object being there. Within UCO purview is the need to express not only relationships (typically temporal) between observable objects and Locations but also relationships between different locations, relationships between Identities (people or orgs) and locations, relationships between Actions and locations, etc.
Fully explaining all of the variations of this would take a whitepaper but hopefully the MANY use cases where this is critical are obvious.
Take one simple example:
Let's say you wanted to express the different locations where my cell phone was today.
You will want to say that at a particular time my cell phone was located at my house, at another specific time it was located at a specific bank branch, and at another time it was located at a specific Chik-Fil-A, etc.
My cell phone should not be characterized in such a way that inherently ties it to a particular location as it in in different locations at different times.
Similarly, each location should not be characterized in such a way that inherently ties them to my cell phone as the presence of my cell phone has nothing to do with the fact that the Locations exist.
Maybe we also want to express the different locations my wife's cell phone was today.
Some of the locations would coincide with the locations of my cell phone but some would not.
If you explicitly and inherently tie Location to a particular object being present the entire graph breaks down.
Context should always be expressed with Relationships between objects.
This tenet continues to be highly critical and especially so in this case.

[sbarnum]

I will assert that this CP or any CP around completely modifying/replacing the fundamental approach for Location cannot be voted on until significantly more detail is provided.

Proposing that we should strive to identify and utilize a well-developed external standard for location is the assertion of a "desire" that I think we all share.

Making this "desire" into a "requirement" is not practical or acceptable until we can ensure that such an option exists that meets the expressive, structural and semantic needs of UCO for location. In order to demonstrate that such an option does meet the expressive, structural and semantic needs of UCO for location would at a minimum require examples demonstrating support for the scenarios outline on this UCO wiki page. This wiki page outlines minimal required capabilities for Location within UCO that have been identified throughout the development of UCO and led to the current design approach.

In the past GeoSparql was proposed as an option to replace the current Location design in UCO. However, at a basic level of review it appear that the semantic foundation of GeoSparql, SpatialThing violates the semantic separation of location from any other thing that is required by UCO's use cases. During last week's UCO/CASE workshops the possibility was raised that GeoJSON may be a possibility as it lacks the conflicting semantic constraint that GeoSparql has.
This appears to be a more promising potential option but to the best of my knowledge we still do not have any concrete examples of actual UCO use cases using either of these proposed options. In order to consider any possible alternative option for representing location within UCO we would need to see demonstrative examples for each of the outlined use case scenarios.

It is absolutely critical that we do not attempt to force a decision as fundamental and critical as Location in an attempt to meet a 22 day deadline based on presumptions that if an external standard is location-related and established that it meets UCO needs. Before it can be considered as a replacement it must be proven to meet UCO needs. I honestly do not see this being practical within the next 22 days.

While aligning with an external standard for location is desirable, it is far more critical that UCO maintain its capability for expressing location within its targeted use cases. If such an alignment must wait until 2.0.0 then that is preferable to breaking UCO 1.0.0. There is nothing fundamentally broken in the current UCO location design. There are certainly desired capabilities (e.g., geometries such as circle, box, polygon) not yet present in the current implementation but they could easily be added in minor releases as they are additive in nature and are possible in the current design. Alignment with an external standard is primarily about improving interoperability with external data. Such alignment can be accomplished between UCO 1.0.0 and UCO 2.0.0 through mapping.

[ajnelson-nist]

It turns out GeoJSONLD might not be an appropriate stand-in. Someone informed me last week that it seemed to be a serialization format of GeoSPARQL. At the least, it did not seem to bear any ontological definitions. I would appreciate whomever told me that bringing a reminder. There is at least some kind of cross-referencing going on between GeoSPARQL and geoJSON in discussion of latitudes.

Re:

However, at a basic level of review it appear that the semantic foundation of GeoSparql, SpatialThing violates the semantic separation of location from any other thing that is required by UCO's use cases.

I think I see where your concern about geo:SpatialThing is obscured. It stems from UCO avoiding making "Top-level ontology" modeling distinctions, in particular "Those things with substance" vs. "Those things without substance". Substantials vs. insubstantials, corporeals vs. incorporeals, something like that. UCO doesn't have that conceptual divide. From your remarks last week, I think your chief concern is a belief that there is a substantial, or corporeal (or something similar), nature to geo:SpatialThing. I disagree, and think it is safe to consider adopting.

Consider owl:Thing. That is the set of everything, whether the thing has substance or is just an idea, is temporally bound or not, is an endurant or perdurant, or any other way of carving up the universe of thought-space.

The top-level class in GeoSPARQL, geo:SpatialObject, has this definition today in the 1.1 pre-release state (and I think is sufficiently likely to remain stable that we could consider adoption):

Anything spatial (being or having a shape, position or an extent).

I read nothing in that sentence that disqualifies an administrative location. Insubstantial things (i.e. things without substance, like the administrative, geometry-less definition of "New York") fit under the definition of geo:SpatialObject, the same as a rock on the ground at my feet would also qualify as a SpatialObject.

Unless I'm missing something, there is no "Top-level-ontology" commitment to a spatial thing having a substance-bearing physical representation.

geo:Feature, a direct subclass of geo:SpatialObject, seems anchored on substantial things. However, geo:Feature in GeoSPARQL 1.1 is not the top-level class, even despite that the remark from 1.0 that "This class represents the top-level feature type" is a mere five lines away from the rdfs:subClassOf :SpatialObject statement. geo:Feature reads as:

A Feature represents a uniquely identifiable phenomenon, for example a river or an apple. While such phenomena (and therefore the Features used to represent them) are bounded, their boundaries may be crisp (e.g., the declared boundaries of a state), vague (e.g., the delineation of a valley versus its neighboring mountains), and change with time (e.g., a storm front). While discrete in nature, Features may be created from continuous observations, such as an isochrone that determines the region that can be reached by ambulance within 5 minutes.

I personally think it is still worth considering adopting any other geospatial representation rather than invest efforts in UCO's location representation. This is a point where we should learn from others' work rather than attempt invention. I suspect UCO's location:Location class and its reference could be replaced with geo:SpatialObject (not necessarily geo:Feature). Then if UCO had some need not met by GeoSPARQL, the location namespace could house extension definitions (subclasses and properties).

We are unfortunately in lack of a champion to demonstrate the requirements gathered recently on UCO's wiki, and whether they are or are not met by GeoSPARQL. So, it is probable that UCO's location namespace will stand as is.

[ajnelson-nist]

Two updates after some more thinking:

First: Re-reading what I wrote, I had some loose wording in my remark above.

However, geo:Feature in GeoSPARQL 1.1 is not the top-level class, even despite that the remark from 1.0 that "This class represents the top-level feature type" is a mere five lines away from the rdfs:subClassOf :SpatialObject statement.

The question of "What class is actually top-level?" was resolved in their Issue 319. There is now no English-documentation claim for top-most object, and geo:SpatialObject is the only Class without an explicit superclass.

Second: I think there's a little more clarification deserved on this remark:

geo:SpatialObject has this definition ...

Anything spatial (being or having a shape, position or an extent).

I read nothing in that sentence that disqualifies an administrative location.

I think this is worth a little more thought in UCO modeling.

As a reminder of our current status, UCO does not define an owl:Class of administrative locations. There is uco-location:SimpleAddressFacet, but no corresponding subclass of uco-location:Location or uco-core:UcoObject.

UCO should consider whether an address (or, if we follow a name hint, a uco-location:SimpleAddress) is an appropriate subclass of "uco-location:Location". I currently think: no, an address is not a location.

An address is an administrative record that a location bears, but the address itself is not a spatial thing (using "spatial thing" more generally, not necessarily GeoSPARQL 1.1's definition). The relationship between an address and a Location object would be a qualified relationship, starting at some time of registering with a local government entity, ending at various events, such as a street being re-named.

SimpleAddressFacet is a place where Facets have let UCO be lax with some modeling questions. See UCO Issue 438 for other examples. This particular Facet has potentially caused a friction point with UCO adoption of an external geospatial model, and I believe we need to resolve for ourselves the question of how an address relates to a location in order to consider any external spatial representation.

[packet-rat]

I totally support Sean’s position that we need to fully vet Location modeling. This feature is much too important, both in terms of static representation, as well as changes over time. Patrick Maroney Principal - Cybersecurity Chief Security Office Office: 732.615.5287 | Cell: 609.678.5613 | Email: ***@***.******@***.***> From: Sean Barnum ***@***.***> Date: Monday, August 8, 2022 at 4:16 PM To: ucoProject/UCO ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [ucoProject/UCO] Redesign the `Location` representation to become interoperable with more widely accepted initiatives (Issue #409) I will assert that this CP or any CP around completely modifying/replacing the fundamental approach for Location cannot be voted on until significantly more detail is provided. Proposing that we should strive to identify and utilize a well-developed external standard for location is the assertion of a "desire" that I think we all share. Making this "desire" into a "requirement" is not practical or acceptable until we can ensure that such an option exists that meets the expressive, structural and semantic needs of UCO for location. In order to demonstrate that such an option does meet the expressive, structural and semantic needs of UCO for location would at a minimum require examples demonstrating support for the scenarios outline on this UCO wiki page<https://urldefense.com/v3/__https:/github.com/ucoProject/UCO/wiki/Discussion-of-required-capabilities-for-Location__;!!BhdT!lbAMgpsUX7FXph2gxYWie6dFJmz2No4gE9i1GjhSWnQn_MxPPPxZxsK49HSLU_ozedGSxf_KUVAtyrAB0VhNIBZ1b18$>. This wiki page outlines minimal required capabilities for Location within UCO that have been identified throughout the development of UCO and led to the current design approach. In the past GeoSparql was proposed as an option to replace the current Location design in UCO. However, at a basic level of review it appear that the semantic foundation of GeoSparql, SpatialThing violates the semantic separation of location from any other thing that is required by UCO's use cases. During last week's UCO/CASE workshops the possibility was raised that GeoJSON may be a possibility as it lacks the conflicting semantic constraint that GeoSparql has. This appears to be a more promising potential option but to the best of my knowledge we still do not have any concrete examples of actual UCO use cases using either of these proposed options. In order to consider any possible alternative option for representing location within UCO we would need to see demonstrative examples for each of the outlined use case scenarios. It is absolutely critical that we do not attempt to force a decision as fundamental and critical as Location in an attempt to meet a 22 day deadline based on presumptions that if an external standard is location-related and established that it meets UCO needs. Before it can be considered as a replacement it must be proven to meet UCO needs. I honestly do not see this being practical within the next 22 days. While aligning with an external standard for location is desirable, it is far more critical that UCO maintain its capability for expressing location within its targeted use cases. If such an alignment must wait until 2.0.0 then that is preferable to breaking UCO 1.0.0. There is nothing fundamentally broken in the current UCO location design. There are certainly desired capabilities (e.g., geometries such as circle, box, polygon) not yet present in the current implementation but they could easily be added in minor releases as they are additive in nature and are possible in the current design. Alignment with an external standard is primarily about improving interoperability with external data. Such alignment can be accomplished between UCO 1.0.0 and UCO 2.0.0 through mapping. — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/ucoProject/UCO/issues/409*issuecomment-1208565948__;Iw!!BhdT!lbAMgpsUX7FXph2gxYWie6dFJmz2No4gE9i1GjhSWnQn_MxPPPxZxsK49HSLU_ozedGSxf_KUVAtyrAB0VhNnoIHMbg$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AAYSFYLLV2B3NDMBMWMS5YLVYFTGXANCNFSM52KCZDHA__;!!BhdT!lbAMgpsUX7FXph2gxYWie6dFJmz2No4gE9i1GjhSWnQn_MxPPPxZxsK49HSLU_ozedGSxf_KUVAtyrAB0VhNuZBVToM$>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>