structure check

[meganrwong]

didn't have the prefixes right in file https://github.com/FedUni-CeRDI/def-au-edu-feduni/blob/main/rdf/fed-uni%20002%20(3).xlsx

the builder could not determine which collection concepts belonged to when they had same suffix (ie 'B' could be a procedure - boron procedure, or a soil structure result of 'blocky')

So - In - https://github.com/FedUni-CeRDI/def-au-edu-feduni/blob/main/rdf/fed-uni%20004%20(2).xlsx added extra prefixes up top of sheet, and edited URI and ^skos:member columns

SkosPlay! gives this - https://github.com/FedUni-CeRDI/def-au-edu-feduni/blob/main/rdf/fed-uni%20004%20(2)-2022-02-16.ttl

I can see there are a lot of differences between the file I've generated here, and for example the one you have here Simon, which I guessed could be the one you uploaded to RVA?? https://github.com/ANZSoilData/def-au-scma/blob/main/rdf/scma.ttl

what we are after is just containers, or collections of classifiers: In the fed uni (fu) collection there should be collections of procedures, objects, properties, and classifiers And in the classifiers collection, there should be collections of colour, texture-grade, name and structure-pedality-type In the collection of names there should be a collection called lismore-soil-series

Ideally we want the work here reflected in the SkosPlay! excel file in case they choose to update/maintain by excel tool in future

may need a working session, I appreciate your patience @bsimons14 @dr-shorthair

[meganrwong]

the classifiers seem a little strange from line 195 - 220 of .ttl - Are the collections texture-grade, colour, name and structure-pedality-type all contained within the classifiers collection here?

[meganrwong]

comment from @bsimons14

“ I think it more useful to constrain classifiers to just those formal nomenclature of the domain feature, rather than its properties; so strictly “soil classifiers” such as ASC, horizon classifiers etc.”

[meganrwong]

comment from @bsimons14

“ I think it more useful to constrain classifiers to just those formal nomenclature of the domain feature, rather than its properties; so strictly “soil classifiers” such as ASC, horizon classifiers etc.”

If so, I'd be tempted then to just put all of these collections (such the collection of soil colour results, collection of texture results, collection of structure result and soil names)..... I'm guessing it may get murky to differentiate what is a 'classifier' from a result? The other option as you suggested Bruce is to have collections of classifiers and collections of results.

This could be a demonstration that having hierarchies built into URIs may become problematic - concepts may be moved about where they sit in a vocabulary, but we want the URIs to persist......

[meganrwong]

Looking at what we've done for green book demo, in which procedures are grouped together under chapters (as collections of procedures) - I wondered if the collections (e.g. 'procedures', 'objects') here should also be concepts. It seems a little odd having all those individual procedures, results etc as top level concepts.......

[dr-shorthair]

I don't see a problem with a 'flat list'. But grouping them into collections - one for each analyte - would be fine.

Take a look at https://demo.vocabs.ardc.edu.au/viewById/897 for how it gets presented in RVA.

• the yellow boxes are collections
• the blue boxes at the bottom are any concepts that have 'narrower' concepts underneath them.

So if a series of methods are minor variations on each other, they could either be grouped into a collection, else into broader/narrower hierarchies. Note that SKOS semantics are flexible. Currently I tend to shadow the class/sub-class hierarchy with collections-with-member-collections, and class/instance relationships using collection-with-member-concepts.

[dr-shorthair]

(Does @bsimons14 know that he can make his own comments?)

[meganrwong]

(Does @bsimons14 know that he can make his own comments?)

I pointed Bruce to this repo. Was just collating comments in one place - Apologies to Bruce if not PC to have pasted comment from email.

[meganrwong]

Here is the feedback @dr-shorthair and my attempts at a fix.

I've not had a good look at the output yet.

https://github.com/FedUni-CeRDI/def-au-edu-feduni/blob/main/rdf/fed-uni%20005.xlsx https://github.com/FedUni-CeRDI/def-au-edu-feduni/blob/main/rdf/fed-uni%20005-2022-02-23.ttl

1. You have not defined the prefix reg: - that’s why this won’t process in SKOSplay!
   2. However, I recommend not referring to reg: or ldp: at all – those are namespaces that are added when loading into LDR, and are not needed prior to loading, or on other platforms. Instead of reg:Register use skos:Collection
      • for collections I used skos:Collection, rdfs:Resource, rdfs:Class and for what I think are sub-classes used skos:Collection, rdfs:Resource, rdfs:subClassOf . I looked to https://demo.vocabs.ardc.edu.au/viewById/897 or some guidance. I'll need review as I'm just trying to get around use of Classes and Collections
   3. You mis-spelled ‘classifier’ as ‘clasifier’ in H52, H53
      • fixed
   4. You have bound both colour: and classifier: to the same URI
      • fixed

I've also tried to address the comment re some of our results not being strictly classifiers. I don't really want to make call re what is a 'classifier' and what is a 'result' - so I changed ALL classifiers to results throughout. Feedback welcome.

I also find it really personally useful to have a type that helps describe a bit more re what a concept is, such as sosa:Procedure. For our 'object' I can't find a really good term..... suggestions? I'm not quie sure Owl:Thing fits, and I guess what we are referring to as 'objects' here could be sosa:FeatureOfInterest...... not sure. Or can just not worry about adding more detail to type. No big deal.