search

GeoscienceAustralia / FSDF

FSDF - Foundation Base Spatial Data - Linked Data - High level models, information, etc
Other
2 stars 0 forks source link

URI conventions #2

Open ibastrak opened 4 years ago

ibastrak commented 4 years ago

Hi Simon,

Returning to the conversation about URI architecture and structure for FSDF datasets/ontologies, etc.

The FSDF ontology (incomplete) was created some time ago at the AGLDWG repository with the namespace http://linked.data.gov.au/def/fsdf.

We also have a URI for Placenames ontology which doesn't use FSDF (http://linked.data.gov.au/def/placenames) and Placenames datasets ((http://linked.data.gov.au/datasets/placenames).

As discussed, my current thinking is about preserving FSDF in the namespace structure as a recognised branding.

So the URI for ontologies will look like: http://linked.data.gov.au/def/fsdf/ and URI for a dataset will look like http://linked.data.gov.au/datasets/fsdf/

Do you see issues in doing it into the future?

Also, do I need to submit a request for each dataset namespace and ontology namespace (when they are ready)?

ibastrak commented 4 years ago

Question about URI conventions. Probably a repetition from out previous discussion.

Themes: At the moment we have the following options as suggested by the http://loci.cat/URI-conventions.html#summary-of-agldwg-uri-guidelines

However, the assigned uri for placenames is http://linked.data.gov.au/def/placenames which is missing the {scope}. Please note that Placenames here is both a theme and a dataset

We can continue with the same structure with other themes and datasets (e.g.http://linked.data.gov.au/def/transport, http://linked.data.gov.au/def/roads, http://linked.data.gov.au/def/physicalInfrastructure, http://linked.data.gov.au/def/pipelines,)

Codelists: Propably having at least (scope) is useful here

My question is: can we have a PipelineProduct collection which will have http://linked.data.gov.au/def/fsdf/product/gas as one of terms?

dr-shorthair commented 4 years ago

Themes:

http://linked.data.gov.au/def/placenames is the URI for an Ontology, i.e. a ‘theme’. The token placenames is the scope. The Ontology is not a 'definition' itself, it contains a set of definitions, classes and properties such as http://linked.data.gov.au/def/placenames/OfficialPlaceName and http://linked.data.gov.au/def/placenames/hasPlaceName

The URIs in the dataset have ‘dataset’ in the path (not ‘def’) – e.g. http://linked.data.gov.au/dataset/placenames/NT_10532

Codelists:

My suggestion is to drop the second element of the scope, and simplify the URIs. So the ones you just mentioned would be

i.e. they are all have the same stem without an extra step. Their membership in the various concept-schemes and collections should be explicit, using skos:topConceptOf and skos:member etc. It should not be inferred from the URI.

However, this does imply that they are all governed together, by the ‘owner’ of http://linked.data.gov.au/def/fsdf/

ibastrak commented 4 years ago

Let leave .../dataset/... out of this conversation for a moment - I'll just like to focus on .../def/...

I guess where I fill unsure is a perception of a need for keeping uri structures consistent.

e.g. (not a true FSDF example) if we use 'gold' as mineral and 'gold' as colour we cannot apply the same uri (http://linked.data.gov.au/def/fsdf/gold)

we will need to use http://linked.data.gov.au/def/fsdf/gold for e.g. minerals codelist and something like http://linked.data.gov.au/def/fsdf/colour/gold for codelist of colours or

http://linked.data.gov.au/def/fsdf/mineral/gold for codelist of minerals and http://linked.data.gov.au/def/fsdf/colour/gold for codelist of colours

There might be similar cases in FSDF

The FSDF example I mentioned before was around 'water' which is a theme (https://www.anzlic.gov.au/resources/foundation-spatial-data-framework/fsdf-themes-datasets/water) which has a number of sub-themes (e.g. groundwater) and a vocabulary concept (e.g. in pipeline products)

ibastrak commented 4 years ago

New four FSDF themes: • Buildings and Settlements • Population Distributions • Geology and Soils • Physical Infrastructure

dr-shorthair commented 4 years ago

Which are added to these

dr-shorthair commented 4 years ago

Persistent URI requests for FSDF have been filed here: http://catalogue.linked.data.gov.au/ontologies

dr-shorthair commented 3 years ago

@arminhaller raised a number of questions relating to the AGLDWG namespace request:

  • I have two concerns with the names proposed below; 1) they are very generic and, 2) they are at the very least unusual for the name of an ontology. Ontologies are typically abbreviations of phrases/words that either contain some project name (, are a combination of several classes within the ontology or some unique phrases. If you have a quick look at the LOV ontology registry (https://lov.linkeddata.es/dataset/lov/) you can see that none of the ontologies is using a generic term like water, transport or population. It looks to me that the below terms are more classes within an ontology and therefore should be defined within the /def/fsdf ontology namespace.

Some discussion:

  1. The names are indeed very generic in some cases. Personally I am a little uncomfortable with 'water' for example, but the names requested do all relate to FSDF themes, so on the first-come-first-served basis it still makes sense.
  2. While the FSDF development is being undertaken under the overall auspices of ICSM, it is planned that the different themes will mostly have distinct governance arrangements - different experts, different revision cycles. This is the primary reason for different namespaces. It is not clear that 'FSDF' branding is useful within the namespace names. And at least one of the FSDF themes is already online without FSDF branding - i.e. PlaceNames ontology. Was that a mistake?
  3. The ontologies defined for each of these themes will have multiple classes. These names are not just class-names. For example, the PlaceNames ontology has 9 classes and 13 properties. While they are not large ontologies, they are more than one class.

I tend to agree that we should tread slowly, and reassure ourselves that each theme requires a distinct ontology in its own namespace, so the current set of request should be treated as placeholders, or statements-of-intent. And we have already evolved a little, as we are considering to have a generic network ontology as a basis for several themes. Should this have its own namespace as well? Or should it just be folded into a utility namespace for FSDF?

In part we are being influenced by the approach taken for the INSPIRE RDF vocabularies. These are factored into a lot of namespaces, matching the packaging of the original UML models. But we are also looking to simplify the packaging from this rather extreme approach.

schimatos commented 3 years ago

Thanks for copying my response in here. My concern was also mostly with the very generic one's. I know there is a first-come first-served principle, but we don't want to start treading on other people's toes, if possible. As Simon mentioned, 'water' is pretty generic and I would assume other Departments want to own (control) that, eventually. Imagery is also pretty generic, is that for any kind of imagery or satellite imagery? If it is the latter, it should probably be in the name. 'Infrastructure' too, is very generic. What kind of Physical Infrastructure will the ontology define? Is there a potential to make this more specific in the name? The same for 'transport'.

One way of avoiding any real problems is to register a # URI only, i.e., just the file name. This would mean that the modules would still remain available later, especially for the very generic names.

schimatos commented 3 years ago

Apologies, logged in with the wrong user name, that comment was from @arminhaller.

dr-shorthair commented 3 years ago

Mentioning @casa-henrym so he gets connected to the thread