search

ANZSoilData / def-au-asls-soil-prof

Machine-readable representation of the classifiers described in chapter 8 Soil Profile, by R.C. McDonald and R.F. Isbell, in Australian soil and land survey field handbook (3rd edn)
0 stars 0 forks source link

feature type concepts #2

Open meganrwong opened 2 years ago

meganrwong commented 2 years ago

We are using the following vocab terms and their identifiers to describe features. Currently they are type SKOS Collection (not features). I think this is all of them. We are only using a subset of these, but we have them stored in our DB as features http://anzsoil.org/def/au/asls/soil-profile/boundaries-between-horizons

http://anzsoil.org/def/au/asls/soil-profile/coarse-fragments

http://anzsoil.org/def/au/asls/soil-profile/cutans

http://anzsoil.org/def/au/asls/soil-profile/mottles-and-other-colour-patterns

http://anzsoil.org/def/au/asls/soil-profile/pans

http://anzsoil.org/def/au/asls/soil-profile/roots http://anzsoil.org/def/au/asls/soil-profile/voids

peds and segregations-of-pedogenic-origin – we are not using as features

For observable properties you have defined as type SKOS Collection and type Observable Property. Might it be possible to do similar for features also?

dr-shorthair commented 2 years ago

Assume you mean feature types - i.e. there will be individual features that are of this type that you might want to make and record observations on. In which case we could say something like

<http://anzsoil.org/def/au/asls/soil-profile/cutans> a skos:Collection , rdfs:Class , owl:Class ; 
    rdfs:subClassOf geosparql:Feature .

OWL purists might object to a resource being simultaneously a Class and skos:Collection, but they don't like SKOS much ever, and a skos:Collection looks very much like an enumerated Class anyway, so I don't really see a big problem.

meganrwong commented 2 years ago

hmmm. Can you record observations on feature types? If the yellow book is used as a guide, perhaps we may never see results for observations on individual features of a feature type, for example - http://anzsoil.org/def/au/asls/soil-profile/coarse-fragments http://registry.it.csiro.au/def/soil/au/asls/soil-prof/roots Whereas cutans and pans, for example, looks to have 'types', so would the feature type be cutans, and the individual features the types of cutans?? http://anzsoil.org/def/au/asls/soil-profile/pans http://anzsoil.org/def/au/asls/soil-profile/cutans So, I think if we can make observations on feature types as well as individual features of the feature types, then what you suggest could work..... Perhaps what are features could be reviewed as part of ANSIS work on YB, starting with this chapter?

bsimons14 commented 2 years ago

'feature types' are the types of real world things. So 'coarse fragments', 'roots', 'pans', 'cutans' are all terms for types of features i.e. "feature types". Observations occur on properties of instances of these features.

dr-shorthair commented 2 years ago

The feature-of-interest of an observation should be an individual feature, i.e. an instance of geo:Feature or of a sub-class.

meganrwong commented 2 years ago

Assume you mean feature types - i.e. there will be individual features that are of this type that you might want to make and record observations on. In which case we could say something like

<http://anzsoil.org/def/au/asls/soil-profile/cutans> a skos:Collection , rdfs:Class , owl:Class ; 
    rdfs:subClassOf geosparql:Feature .

OWL purists might object to a resource being simultaneously a Class and skos:Collection, but they don't like SKOS much ever, and a skos:Collection looks very much like an enumerated Class anyway, so I don't really see a big problem.

I think this is ok for the terms we need to use as feature types.