Representation of Timestamped Lat/Long Coordinates

Data containing Lat/Long coordinate measurements can often contain the timestamp at which the measurement occurred. Currently, it appears that representation of this concept involves: an observable:GeoLocationEntry that contains an observable:GeoLocationEntryFacet that points to an instance of location:Location containing a location:LatLongCoordinatesFacet. It seems convoluted, and while it works, I feel like there may be a simpler way.

In discussions with @ajnelson-nist, the location:Location could otherwise be replaced by a not-yet-defined subclass such as location:LatLongCoordinates object. I'm not entirely convinced of the value of such a new subclass if it doesn't contain any additional properties, especially given the use case of having both a location:SimpleAddressFacet and a location:LatLongCoordinatesFacet contained within one location:Location object (such as in the CASE-Examples) repository.

Current example:

[
    {
        "@id": "kb:geo-location-1",
        "@type": "uco-observable:GeoLocationEntry",
        "uco-core:hasFacet": [
            {
                "@type": "uco-observable:GeoLocationEntryFacet",
                "uco-observable:location": "kb:location-1",
                "uco-observable:observableCreatedTime": {
                    "@type": "xsd:dateTime",
                    "@value": "2022-01-01T12:00:00.00Z"
                }
            }
        ]
    },
    {
        "@id": "kb:location-1",
        "@type": "uco-location:Location",
        "uco-core:hasFacet": [
            {
                "@type": "uco-location:LatLongCoordinatesFacet",
                "uco-location:latitude": {
                    "@type": "xsd:decimal",
                    "@value": "48.860346"
                },
                "uco-location:longitude": {
                    "@type": "xsd:decimal",
                    "@value": "2.331199"
                }
            }
        ]
    }
]

Questions:

Is there a better method to represent this concept with the current version of the ontology?
Should there be changes proposed (I'm happy to work them if so) to better represent this concept?

I made a guess at a representation for timestamping lat/long coordinates based on sosa:Observations, as part of the CellSite proposal's documentation under draft here.

I'm aware at least one community member has an issue with this representation strategy, though I admit I was not quite able to understand all of the ramifications of their discussion. I will await their posting a response here.

I may be stating the obvious, but I feel that we are constantly mixing up 2 different things: 1) "Semantic Locations"- Places that have a name and address/position as well as a meaning, for example a certain bank's physical location. To complicate things, sometimes semantic locations change position over time, for example the bank moves the specific branch to a new location. 2) Visited Positions- Typically a GPS Coordinate (Lat/Long, with or without elevation), but sometimes an address that a party or object (the "thing") was at, at a given point in time (or during a date range- from one point in time to another). these types of Locations should have a timestamp, otherwise they are significantly less useful in the context of an investigation. The semantics of the timestamp is when the "thing" was at the location and not when the event was necessarily recorded.

For me, we need to understand these 2 POVs before we attempt to model anything in this space.

In this comment I first describe an ontological view on location, then provide evidence against the use of sosa:Observations, and finish with a response to Danny's comment.

Ontological view on `Location`

I've given an ontological explanation on the concept of Location here. The gist of it is summarised as:

Suggested Definition :
- A Location is: An identifiable spatial extent of a physical or abstract entity (Place) where activities (will) take place or have been taken place.
- A Place is: a building or locality used for a special purpose; a particular region, center of population, ~~or location~~; a building, part of a building, or area ~~occupied as a home~~. See Merriam-Webster: Place, Lemma 2b, 3a, 3b (I crossed-out the parts of MW's lemmas that I consider to ill-fit our application).
A Location is not equivalent to the location itself, but a means to identify the spatial extent. This implies that a Location is abstract (meaning, we cannot instantiate it directly but only indirectly through its subclass Place).
A Place is instantiated as an IRI, identifying a particular Location and represented in one of three ways: semantically by name, geographically by locn:Geometry as a point, line, polygon, etc. expressed using coordinates in some coordinate reference system, or administratively by address. A single Place can be represented many times for each type of representation.
A Place can either be relative or absolute, where the latter's representation identifies the Location independently from any other Places, and the former's representation identifies a particular position within the immediate context of another place, e.g., a room in a building.

Representing `Location` as measurement

Although a location can be the result of a measurement, e.g., GPS or cell tower triangulation (one of the three types of representation above), that does not imply that the Location itself should be represented in terms of a measurement process. By analogy, the height or weight of an individual person requires a measurement process to establish the value in a certain dimension, but we consider height or weight a characteristic (property) of the specific individual as opposed to the result of a measurement process involving that individual.

At the same time, two other means to represent a location exists (semantically and administratively), for which no measurement process exists (at least not in the ordinary sense of the word).

These two arguments are for me sufficient to conclude that representing Location in terms of the outcome of a measurement process is a very peculiar and, hence, non-interoperable way that we should not continue to pursue.

2 POVs: Semantic location versus Visited position

Indeed, two distinct ways to address a Location (pun not intended) do exist. At the same time, I disagree that these are different points of view, since the intended semantics of Location does not change. What does change is their intended use, their pragmatics, but I don't want to start an academic discussion about that. Instead, I would like to confine to the observation that the indicated distinctions are differences in representation of the same concept. These different representations fit with the semantics of Location as described above, which I trust to resolve Danny's comment.

Refer to:

409 to the fundamental design underlying the location aspects of this CP,
410 to the fundamental design underlying the spatio-temporal (trajectory) aspects of this CP.

ucoProject / UCO