We should see the next level of properties of the birth like here:
stemmed from
(took place at; no data in this case)
has time span
except for the inverse property linking back to the root entity:
brought into life
The case of 'has time-span' is special and important, since very central for the event centered data model we have. Instead of treating the Time-Span like an normal entity, we would rather go even further down the property path and see a pretty printed value like 1817 (or in other cases 1731-03-03 – 1877), calculated from all its linked Date time description.
Generically speaking the item in the list should not just show the rdfs:label and rdfs:type of the object URI but query one level deeper.
One challenge will be to deal with potentially large numbers of properties, as in the case of gender of Johannes Kepler:
has Gender: Here we actually see enough. By applying the above rules though, we would see all persons having the gender male. In the toolbox we managed this by only showing the nested properties of temporal entities and not for persistent items. Unfortunately the owl class hierarchy is not yet present in the RDF.
The only solution I currently see is to rely on the direction of the property: We only show outgoing properties (not the ones with 'i' suffix).
In any case, there needs to be a limit on the query of nested properties, otherwise we risk huge results.
The specs of this issue is not as clear as others due to the complexity. It needs to be elaborated on during the development.
Instead of this
We should see the next level of properties of the birth like here:
except for the inverse property linking back to the root entity:
The case of 'has time-span' is special and important, since very central for the event centered data model we have. Instead of treating the Time-Span like an normal entity, we would rather go even further down the property path and see a pretty printed value like
1817
(or in other cases1731-03-03 – 1877
), calculated from all its linked Date time description.Generically speaking the item in the list should not just show the rdfs:label and rdfs:type of the object URI but query one level deeper.
One challenge will be to deal with potentially large numbers of properties, as in the case of gender of Johannes Kepler:
In any case, there needs to be a limit on the query of nested properties, otherwise we risk huge results.
The specs of this issue is not as clear as others due to the complexity. It needs to be elaborated on during the development.
Here how it looks in the toolbox: