surroundaustralia / fsdf-kg

Creative Commons Attribution 4.0 International
0 stars 0 forks source link

Review of fsdf-kg ontology - base classes #1

Open dr-shorthair opened 3 years ago

dr-shorthair commented 3 years ago

FSDF-KG appears to define a basic ontology for FSDF applications, in the namespace https://linked.data.gov.au/def/fsdf/. FSDF-KG relies primarily on GeoSPARQL and DCAT for the key classes (Features and Datasets), and adds specific properties related to custodianship and responsibility.

More specific ontologies and vocabularies may be defined in subsidiary namespaces https://linked.data.gov.au/def/fsdf/xxx/ and https://linked.data.gov.au/def/fsdf/yyy#, such as https://linked.data.gov.au/def/fsdf/common# and https://linked.data.gov.au/def/fsdf/network#.

There are three classes defined in the https://linked.data.gov.au/def/fsdf/ (prefix fsdf:) namespace:

Two of these classes use schema.org types as their base class, while the other leans on W3C ontologies. I suggest either (a) use a consistent base ontology (or family), or (b) move alignments to existing ontologies into separate graphs.

W3C Organization ontology might be a suitable basis - while it has not been widely used, it is designed to support these kind of applications. The alignment to schema.org is useful, but given the intention that FSDF have reasonable strong semantics (there are domain and range axioms) compared to SDO's weak semantics, the SDO alignment is probably best kept in a secondary graph.

nicholascar commented 3 years ago

I suggest either... use a consistent base ontology (or family)...

I think we'll pick up this approach. I'll add in ORG alignment while retaining the schema.org alignment.

[or]... move alignments to existing ontologies into separate graphs.

I won't take this approach as we already have a n aweful lot of semantic elements - onts and vocs - to deal with and really need one main ontology for the FSDF dataset tracing platform (the semantic form of LINK) to bring everything together.

re fsdf:Jurisdition It is unclear if local government jurisdictions are also included

That's not a modelling issue but a governance one: if ICSM wants local Jurisdiction instances, they can make them.

I'll ensure that the model definitions make this clear.

re fsdf:Agency It is unclear if departments and portfolios are considered

fsdf:Agency need not have a consistent govt. structural view with AGOR etc from where portfolios etc come from. So Agency here is whatever makes sense for FSDF. My guess is that it really doesn't include Portfoliios: FSDF Agencies seem to be the org that directly manage/supply data, not parent bodies. But if a AGOR Portfolio supplies data to FSDF, then it's an fsdf:Agency instances.

nicholascar commented 3 years ago

I suggest either... use a consistent base ontology (or family)...

I think we'll pick up this approach. I'll add in ORG alignment while retaining the schema.org alignment.

OK, I've taken this approach but used sdo:Legislation as the super class of Mandate, (Commit https://github.com/surroundaustralia/fsdf-kg/commit/905326d6d2333d451a665dda87615a0d955cf480) so now SDO is used everywhere.

Yes we have stronger semantics than SDO but we need not introduce ORG semantics for any purpose yet found: our own semantics will carry our needs for now. This can be changed later if we can identify a strong OGC benefit. SDO alignment remains for generic SDO export of data from APIs/web systems.

dr-shorthair commented 3 years ago

if we can identify a strong OGC benefit

did you mean "if we can identify a strong ORG benefit"?