Update flights.yaml example following Summit presentation and fixed small omission in ontology spec#149
Update flights.yaml example following Summit presentation and fixed small omission in ontology spec#149kurtStirewalt wants to merge 29 commits into
Conversation
… ontology spec that refs the core spec so that both may evolve independently.
…rror changes to the core semantic model spec.
…fixed omissions in the spec regarding where requires fields can appear.
| roles: | ||
| - concept: RunwayLength | ||
| verbalizes: | ||
| - '{Runway} hase {RunwayLength}' |
There was a problem hiding this comment.
This should be "has" and not "hase" ?
How are you thinking about validation for these so that we could catch these typos ?
There was a problem hiding this comment.
Yes, this is a typo. Unfortunately, with verbalization strings there is not a good automated way to catch these kinds of things.
| roles: | ||
| - concept: String | ||
| verbalizes: | ||
| - '{Route} has name- {String}' |
There was a problem hiding this comment.
Similar to the comment above, the hyphen after name looks like a typo ?
There was a problem hiding this comment.
This is actually not a typo, but I can see why it looks like one. Languages (like object role modeling) that support verbalization use these hyphens to group text around the roles of the relationships when verbalizing constraints. So, for instance, the verbalization of the many to one multiplicity constraint would read:
"Each Route has at most one name String"
rather than:
"Each Route has name at most one String"
Notice how by adding the hyphen after "name" that text floats with the second role (played by String) so that the verbalization of the constraint is more readable.
That said, I can see why folks who aren't familiar with this convention (which admittedly is only supported in a small number of modeling languages) might find it confusing.
What do you think we should do in this case? I will add a comment at the end of the line in the spec to clarify that it is not a typo. Please let me know if you think this suffices.
There was a problem hiding this comment.
Yes a comment would be useful to indicate the difference. Thanks.
| identify_by: [ tailnum ] | ||
| requires: [ tailnum ] |
There was a problem hiding this comment.
Are both identify_by and requires needed ? How does one reason about the need for both ?
There was a problem hiding this comment.
Good question. The requirement on tailnum is implied by its use as an identifier. I'll remove it. Thanks
| verbalizes: | ||
| - '{Airport} has average arrival {Delay}' | ||
| multiplicity: ManyToOne | ||
| derived_by: [ 'Decimal == AVG[Flight.arrival_delay WHERE Airport == Flight.route.destination GROUP BY Airport]' ] |
There was a problem hiding this comment.
The expression above for average_departure_delay says Delay= .. but here it says Decimal = ?
There was a problem hiding this comment.
Good catch. This is one that we should have caught in CI/CD on the RAI side. I'lll look into what failed there. But it's fixed now. Thanks
jbonofre
left a comment
jbonofre
left a comment
There was a problem hiding this comment.
LGTM. I left some suggestions.
| @@ -1,1092 +1,1108 @@ | |||
| version: 0.2.0.dev0 | |||
| name: flights | |||
| description: Ontology for flight-related concepts and relationships | |||
There was a problem hiding this comment.
Maybe we can keep the description here?
| roles: | ||
| - concept: String | ||
| verbalizes: | ||
| - '{Route} has name- {String}' # The hyphen after "name" has significance when verbalizing constraints |
There was a problem hiding this comment.
I see the comment about hyphen after name. Thanks for that. I just wonder if we should not have details in the spec that we reference here (not necessarily in this PR, but a follow up).
| version: 0.2.0.dev0 | ||
| name: flights | ||
| description: Ontology for flight-related concepts and relationships | ||
| name: Flights |
There was a problem hiding this comment.
ontology.json added requires at top level. Maybe we should use it in this example.
Something like:
version: 0.2.0.dev0
name: Flights
requires:
- "COUNT[Airport] > 0" # there must be at least one Airport
- "COUNT[Carrier] > 0" # there must be at least one Carrier
ontology:
- concept:
| roles: | ||
| - concept: Carrier | ||
| verbalizes: | ||
| - '{Aircraft} carrier {Carrier}' |
There was a problem hiding this comment.
In OSI, verbalizes is a natural-language template that reads the relationship out loud, with {ConceptName} placeholders for each role.
The "convention" is subject + verb + object.
I would suggest to use:
- '{Aircraft} belongs to {Carrier}'
| verbalizes: | ||
| - '{Flight} cancelled {Boolean}' | ||
| multiplicity: ManyToOne | ||
| - name: cancellationcode |
There was a problem hiding this comment.
| - name: cancellationcode | |
| - name: cancellation_code |
| roles: | ||
| - concept: String | ||
| verbalizes: | ||
| - '{Flight} cancellationCode {String}' |
There was a problem hiding this comment.
| - '{Flight} cancellationCode {String}' | |
| - '{Flight} has cancellation code {String}' |
| - object_mapping: | ||
| concept: String | ||
| expression: FLIGHT.cancel_code | ||
| relationship: cancellationcode |
There was a problem hiding this comment.
| relationship: cancellationcode | |
| relationship: cancellation_code |
| - object_mapping: | ||
| concept: Integer | ||
| expression: ROUTE.dist_grp | ||
| relationship: distancegroup |
There was a problem hiding this comment.
| relationship: distancegroup | |
| relationship: distance_group |
| verbalizes: | ||
| - '{Route} spans {Distance}' | ||
| multiplicity: ManyToOne | ||
| - name: distancegroup |
There was a problem hiding this comment.
| - name: distancegroup | |
| - name: distance_group |
| roles: | ||
| - concept: Integer | ||
| verbalizes: | ||
| - '{Route} distanceGroup {Integer}' |
There was a problem hiding this comment.
| - '{Route} distanceGroup {Integer}' | |
| - '{Route} has distance group {Integer}' |
3 participants
Updating examples/flights.yaml to reflect the full example we presented at Summit. Fixed 2 omissions in the ontology spec: