Open dr-shorthair opened 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.
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.
if we can identify a strong OGC benefit
did you mean "if we can identify a strong ORG benefit"?
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/
andhttps://linked.data.gov.au/def/fsdf/yyy#
, such ashttps://linked.data.gov.au/def/fsdf/common#
andhttps://linked.data.gov.au/def/fsdf/network#
.There are three classes defined in the
https://linked.data.gov.au/def/fsdf/
(prefixfsdf:
) namespace:fsdf:Jurisdiction rdfs:subClassOf sdo:Organization .
for the Commonwealth, States and Territoriesfsdf:Agency rdfs:subClassOf sdo:Organization .
for government organizationsfsdf:Mandate rdfs:subClassOf prov:Entity , dcat:Resource .
for regulations and legislation that bind FSDF resources to an AgencyTwo 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.