Open meganrwong opened 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.
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?
'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.
The feature-of-interest of an observation should be an individual feature, i.e. an instance of geo:Feature
or of a sub-class.
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.
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?