OpenC2SIM / C2SIMArtifacts

C2SIM Artifacts
MIT License
4 stars 5 forks source link

Provide Ordering for Locations #8

Open clblais opened 2 years ago

clblais commented 2 years ago

C2SIM Problem Report / Change Request Submitter Name (s): Curtis Blais for Geir Sletten and Ole Martin Mevassvik Contact email address: Geir.Sletten@ffi.no, Ole-Martin.Mevassvik@ffi.no Submitter Organization(s): FFI Date of Submission: 23 May 2022 Type (Problem Report or Change Request): Problem Report Product: Core Ontology Problem/Change Description: From: Evaluation of C2SIM for use in Army Course of Action simulation, 22 February 2022, p 6

Locations are only represented as single points without any ordering specified. This is not sufficient for geometric figures represented by multiple points.

clblais commented 2 years ago

See also Geir Sletten and Ole Martin Mevassvik, Evaluation of C2SIM for use in Army Course of Action simulation, 22 February 2022, pp 12-13, section 6.1.8 Add sequence to location positions:

To avoid problems based on this issue, we propose to add a sequence number, as shown below (this is already used in SWAP):

<WhereValue> <WhereLocation Sequence="1"> ... </WhereLocation> <WhereLocation Sequence="2"> ... </WhereLocation> </WhereValue>

jmpullen2 commented 2 years ago

ManeuverWarfareTask can have unlimited number of Location with implied order.

clblais wrote on 5/23/22 8:15 PM:

Geir Sletten and Ole Martin Mevassvik, Evaluation of C2SIM for use in Army Course of Action simulation, 22 February 2022, p 6

Locations are only represented as single points without any ordering specified. This is not sufficient for geometric figures represented by multiple points.

— Reply to this email directly, view it on GitHub https://github.com/OpenC2SIM/C2SIMArtifacts/issues/8, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABN7HSMQ2KB6EZXXPCOO7ETVLQNQVANCNFSM5WXOFA3Q. You are receiving this because you are subscribed to this thread.Message ID: @.***>

dr-cgf-home commented 2 years ago

I completely agree with the need for sequencing points. We will need to investigate how to represent this.

MagdalenaDechand commented 2 years ago

1) adding only "hasName" or "hasSequenceNumber" or "hasID" to Location has one disadvantage. There is no semantic relation between those Locations.

2) If you use it together with "hasPredecessor" it certainly works.

image

3) adding "orderedLocation" with properties "hasLocation" and "hasSequenceNumber" has also one disadvantage. Where would you put this orderedLocation-class? As subclass of location you would distinguish it from GeodeticCoordinate. I think orderedLocation could be a GeodeticCoordinate or a RelativeLocation though. image

-> As double subordination cannot be used in C2SIM, yet (schema transformation restrictions), I recommend solution 2.

dr-cgf-home commented 1 year ago
  1. I am not sure about the disadavantage of only adding a sequence number to Location. It is true that this sequence number has no context by itself; it is only meaningful in the context of other Locations that are related to the same path/line. I see that the reporters of the issue have a class Where with WhereLocations, and these classes could provide some context for the Locations (see more below).
  2. The hasPredecessor property that Magdalena suggests is reasonable, but the implementation shown has the type of the property as a Location; this is correct in the ontology, but in the schema xml the predecessor location would probably have to be identified by name (i.e., hasLocationName).
  3. I agree that making an OrderedLocation a subclass of Location does not really work in the current ontology.

I think that, continuing the thought of WhereLocations, we should think of Location only as a place in the world, and an "ordered location" as a concept that is more than this; it has the context of a sequence of places, and a position in the sequence, as well as a place in the world. For the moment let's call this concept a Vertex class. A Vertex would have a Location as an object property, and either a sequence number or a predecessor property.

Here's a proposal: Create a class Vertex as a subclass of PhysicalConcept. The Vertex has a Location and a SequenceNumber that is an unsignedInt. Vertex Create a class Shape, also as a subclass of PhysicalConcept. Shape has subclasses Point, Polyline and Polygon. A Shape has 1 or more Vertex object properties; these can define the line, or the boundary, or (for a user-defined subclass extension) arbitrary shape handles. Within a Shape, the Vertex SequenceNumbers should start at 0 and increment by 1 in order. I believe the sequence number will be the most efficient was to communicate the Vertex order in a decoded xml representation--a predecessor property, for example, would require a reference ID for each Vertex and possibly a linked list representation rather than a simple array. Shape

Further, the PhysicalEntity class would be given an object property hasShape. The cardinality can be exactly 1, since each PhysicalEntity already has a PhysicalState with a Location, and if the PhysicalEntity doesn't have a defined extent, the Shape can be a Point with the given Location. For other cases, the Location in the PhysicalState represents the single point representation, e.g. the location transmitted on the network in DIS or HLA. PhysicalEntity

With a Shape for PhysicalEntity, graphcis such as Line (or Route) can use a Polyline to define the sequence of vertices. Tasks should use a Route graphic for defining a route. The hasLocation property for the Action class could probably be changed to have cardinality max 1 instead of min 0.