Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Need ability to represent concepts "Bearing" and "Velocity" #567

Open
1 of 15 tasks
vulnmaster opened this issue Nov 23, 2023 · 6 comments
Open
1 of 15 tasks

Need ability to represent concepts "Bearing" and "Velocity" #567

vulnmaster opened this issue Nov 23, 2023 · 6 comments
Labels
Change Proposal
Milestone
UCO 1.x.0

Comments

@vulnmaster
Copy link

vulnmaster commented Nov 23, 2023 •
edited
Loading

Background

The current UCO framework provides a robust platform for representing various cyber and physical objects but lacks specific properties for detailed geospatial analysis. Specifically, there is no representation for "Bearing" (direction of travel in degrees from 0 - 360) and "Velocity" (the speed of travel in kilometers or miles). These concepts are critical in investigations involving movement tracking, such as transportation incidents, or analyzing the movement patterns of entities.

I am fine with my examples in this change proposal being transcribed and credited when others can re-use this content.

Example

Background: An investigator is analyzing a traffic incident involving a vehicle suspected of speeding and making an abrupt turn before the collision. The vehicle is equipped with a modern infotainment system that records geospatial data, including the direction of travel (bearing) and speed (velocity).

Data Extraction: The infotainment system's data is extracted using forensic tools compatible with the vehicle's system. The data includes a timestamped log of the vehicle's bearing and velocity.

Presentation of Data:
Extracted Data Log:

Timestamp: 2023-11-22T15:30:00Z
Bearing: 90 degrees (indicating eastward direction)
Velocity: 50 km/h
Timestamp: 2023-11-22T15:32:00Z
Bearing: 135 degrees (indicating a southeast direction)
Velocity: 70 km/h
Timestamp: 2023-11-22T15:33:30Z
Bearing: 180 degrees (indicating southward direction)
Velocity: 30 km/h
Analysis:

The data shows that at 15:30, the vehicle was traveling eastward at a moderate speed of 50 km/h.

By 15:32, the vehicle's speed had increased to 70 km/h, and the bearing changed to 135 degrees, indicating a significant turn towards the southeast.

At 15:33:30, a notable change in bearing to 180 degrees and a reduction in speed to 30 km/h suggest an abrupt southward turn and deceleration, possibly correlating with the moment of the incident.

Investigative Actions:

Map Overlay: The investigator overlays this data onto a map of the incident area to visualize the vehicle's path and correlate it with physical evidence and witness statements.
Speed Analysis: The speed data is compared against the posted speed limits to ascertain if the vehicle was speeding.

Maneuver Correlation: The bearing changes are examined in relation to the road layout and traffic conditions to assess the driver's actions leading up to the incident.

Conclusion:
Based on the bearing and velocity data extracted from the infotainment system, the investigator gains insights into the vehicle's movement patterns, contributing significantly to reconstructing the events leading up to the traffic incident.

Requirements

I have two requirements.

Requirement 1

Description: Introduce a new property, uco-location:Bearing, to represent the direction of travel in degrees (0 - 360).
Type: owl:DatatypeProperty
Range: xsd:decimal

Requirement 2

Description: Introduce a new property, uco-location:Velocity, to represent the speed of travel in kilometers or miles per hour.
Type: owl:DatatypeProperty
Range: xsd:decimal

Risk / Benefit analysis

Benefits

Enables precise tracking and representation of directional movement and speed, enhancing the ontology's utility in geospatial and transportation-related investigations.

Aligns UCO with standard practices in geospatial data representation, improving interoperability with other systems and datasets.

Risks

Potential complexity in ensuring consistent unit usage (e.g., kilometers vs. miles for Velocity) across different datasets.

Additional validation mechanisms may be needed to ensure the accuracy and consistency of Bearing and Velocity data.

These are simple geo concepts that will lead to UCO eventually needing to accomodate GeoJSON concepts.

Competencies demonstrated

Enabled or Upgraded Competency with "Bearing" and "Velocity" in UCO

Competency 1

Enabled or Upgraded Competency with "Bearing" and "Velocity" in UCO

Scenario: An investigator is analyzing a traffic incident involving a vehicle suspected of speeding and making an abrupt turn before the collision. The vehicle, equipped with a modern infotainment system, has recorded crucial geospatial data, including the vehicle's bearing and velocity.

Competency Question 1.1

Question: How can we determine the vehicle's direction and speed changes at specific times to understand its movement pattern before the collision?

Result 1.1

Result: With the integration of "Bearing" and "Velocity" into UCO, investigators can now analyze the directional changes and speed variations of the vehicle. This data provides insights into the vehicle's maneuvering and speed at critical moments leading up to the incident.

PREFIX uco-location: <https://ontology.unifiedcyberontology.org/uco/location/>
PREFIX uco-time: <https://ontology.unifiedcyberontology.org/uco/time/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

SELECT ?timestamp ?bearing ?velocity
WHERE {
  ?vehicleEvent uco-location:bearing ?bearing ;
                uco-location:velocity ?velocity ;
                uco-time:timestamp ?timestamp .
  
  FILTER(?timestamp >= "2023-11-22T15:30:00Z"^^xsd:dateTime &&
        ?timestamp <= "2023-11-22T15:33:30Z"^^xsd:dateTime)
}
ORDER BY ?timestamp

Explanation

The query retrieves data for a specific vehicle's movements (?vehicleEvent) within the timeframe of the incident.
It focuses on extracting the bearing (?bearing) and velocity (?velocity) at each recorded timestamp (?timestamp).
The filtered time range corresponds to the period just before and during the incident, allowing for a focused analysis of the vehicle's behavior.

This query enables the investigator to construct a timeline of the vehicle's directional changes and speed, which is crucial for understanding the events leading up to the traffic incident.

Solution suggestion

Define Bearing Property

uco-location:Bearing a owl:DatatypeProperty ;
    rdfs:label "Bearing"@en ;
    rdfs:comment "Represents the direction of travel in degrees from 0 to 360."@en ;
    rdfs:domain uco-location:Location ;
    rdfs:range xsd:decimal ;
    .

Define Velocity Property

uco-location:Velocity a owl:DatatypeProperty ;
    rdfs:label "Velocity"@en ;
    rdfs:comment "Represents the speed of travel in kilometers or miles per hour."@en ;
    rdfs:domain uco-location:Location ;
    rdfs:range xsd:decimal ;
    .

(2023-11-27: OC Chair edited lightly to fix Markdown syntax.)

Coordination

  • Tracking in Jira ticket OC-300
  • Administrative review completed, proposal announced to Ontology Committees (OCs) on 2023-11-28
  • Requirements to be discussed in OC meeting, 2023-12-12
  • 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.
  • Backwards-compatible implementation merged into develop for the next release
  • develop state with backwards-compatible implementation merged into develop-2.0.0
  • Backwards-incompatible implementation merged into develop-2.0.0 (or N/A)
  • Milestone linked
  • Documentation logged in pending release page
  • Prerelease publication: CASE develop branch updated to track UCO's updated develop branch
  • Prerelease publication: CASE develop-2.0.0 branch updated to track UCO's updated develop-2.0.0 branch
@ajnelson-nist ajnelson-nist added this to the UCO 1.x.0 milestone Nov 27, 2023
@ajnelson-nist
Copy link
Contributor

Thank you @vulnmaster for the proposal, it's pretty well written.

I have a few initial remarks:

  1. The "degrees" property needs to include in its definition what "0" means. Does it mean East (Cartesian), Magnetic North, or True North?
  2. Because this is introducing units of measure, I encourage UCO to not invent concepts here, but instead adopt any other existing implementation. I am aware of QUDT (GitHub repo here) providing unit:KiloM-PER-HR in the unit vocabulary, as well as unit:DEG.
  3. Because this is also covering measurements, I believe this proposal would also depend on qualities.
  4. uco-time:timestamp is mentioned in the competency illustration, but does not exist as a property. (I also suggest avoiding focus on the current members of the UCO time namespace, as they are stubs with currently no functional impact.) uco-core:endTime or startTime, or uco-action:endTime and startTime should be used instead.
    • Which property should be used, and the significance of the gap between start and end times of measurements, is one of the reasons I've mentioned sosa:Observations complementing UCO's observable:Observations.
  5. I saw mention of GeoJSON. That is one of the representations that had come up as UCO was discussing alignments of the Location namespace. GeoJSON, and any other suggested representations, should be evaluated with this requirements wiki page.

@ajnelson-nist
Copy link
Contributor

Re:

  1. Because this is also covering measurements, I believe this proposal would also depend on qualities.

Instead of owl:DatatypePropertys, I believe bearing and velocity would be better suited as qualities. Here are the main reasons:

Given this SPARQL:

  ?vehicleEvent uco-location:bearing ?bearing ;
                uco-location:velocity ?velocity .

The query shape tells me it is not the vehicle that has a bearing and velocity, but instead the event pertaining to the vehicle that has a bearing and velocity. That seems like a confusion of a record with a spatial object, and if we continued down that road we could probably end up measuring databases in transaction-miles-per-hour.

Instead, I think your suggested uco-location:Velocity would be a owl:Class, subclass of Quality, as an object inhering in spatial things. (For instance, a uco-observable:Device always has a velocity, even non-0 if given wheels or wings.) And likewise for uco-location:Bearing, it should also be a quality.

The SOSA/SSN spinning cups example includes a speed measurement of an object clocking in at 47 km/h.

@packet-rat
Copy link

packet-rat commented Nov 27, 2023 via email

@ajnelson-nist
Copy link
Contributor

What are the issues with using the SSN Ontology? Ultimately, won’t an Observation be based on a sensor? I’m always a fan of subsuming well vetted ontologies where it does not constrain one’s objectives.

There are no notes for or against SSN+SOSA yet in UCO's discussions. They haven't been proposed for adoption by owl:imports.

I've exercised them a bit in CASE-Corpora (SHACL shapes in this directory), so I have some sense of what they'd be like to work with.

I think UCO would need to handle Qualities before discussing SSN+SOSA.

And I am still trying to give Qualities their fair shake, but I'm working through some review mechanisms to support that.

@ajnelson-nist
Copy link
Contributor

Re:

  1. The "degrees" property needs to include in its definition what "0" means. Does it mean East (Cartesian), Magnetic North, or True North?

@vulnmaster , I apologize, I missed that your initial post indicates a 0-bearing is not East. But, how should we handle Magnetic North vs. True North?

@sbarnum
Copy link
Contributor

sbarnum commented Dec 12, 2023

I agree with the value of adding the concepts of bearing and velocity an object in geospace.
I think there are still many open questions above in HOW these should be codified.
How should the concepts be defined/structured? What object should they be associated with and how? Etc.
I agree with Alex on the distinction between the bearing/velocity being on the thing with the bearing/velocity rather than an event related to that thing.
This still leaves multiple ways to try to structure this. Alex raises the possibility of doing this using Qualities which could be one option but not an option we should pursue until we have fully discussed Qualities and have consensus on whether or not they should be considered for UCO.
I believe a requirements review vote is premature until these questions can be answered.

ajnelson-nist added a commit to ucoProject/UCO-Profile-gufo that referenced this issue Mar 5, 2024
@ajnelson-nist
Apply EndurantType hierarchy for Qualities of vehicle example
d8afa8e 
No effects were observed on Make-managed files.

References:
* ucoProject/UCO#567

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
@ajnelson-nist ajnelson-nist mentioned this issue Mar 5, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Change Proposal
Projects
None yet
Milestone
UCO 1.x.0
Development

No branches or pull requests
4 participants
@sbarnum @packet-rat @ajnelson-nist @vulnmaster