[cdif-community] Using vocabularies for sets of class instances

[A. G.]

 Donald:
I am not convinced from what you write that CDIF would treat this as a candidate for a SKOS Concept Scheme. The facilities lists we have dealt with in the past were often treated as data sets, where each entry was a facoloty with a (regular) set of properties. (This use case came from INSEE, the French statistical agency. They are heavy users of SKOS but chose not to use it for this.)
DDI-CDI is very good at describing anything tabular - much richer than CSV on the Web or other similar vocabularies which do not give rich enough tie-backs to definnitional concepts. It may be worth looking at the INSEE approach for your use case.
Cheers,
Arofan
    On Monday, October 13, 2025 at 03:40:50 AM EDT, Donald Hobern <donald.hobern at adelaide.edu.au> wrote:  
 
  I wanted to highlight a use case for vocabularies that does not align well with the CDIF SKOS recommendation. I'm not sure it really affects anything about CDIF, but I'm logging it here anyway, Maybe, the recommendation is that I don't use the word "vocabulary" in this case.
APPN is encouraging its partner nodes to produce spreadsheets listing the names and properties for key components of their persistent physical infrastructure (growth facilities, platforms and sensors) and for concepts that the node will reuse across datasets (observed variables). 
Each row in one of these spreadsheets will be an instance of a class in a schema.org-compliant APPN schema (based on the MIAPPE minimum-information model, SOSA, schema.org and other ontologies).
APPN will publish the content of these spreadsheets via Research Vocabularies Australia. This will mean that every row will receive a URI that resolves to a landing page or linked data with all the properties for the instance. This is part of our plan for linking all data from our nodes as a single navigable linked-data graph. A central node will harvest the metadata from all APPN datasets and offer services based on these linkages. Effectively, we're using this approach to publish class-specific PIDs for entities that don't merit a DOI, ORCID, ROR or RAiD. 
I don't want to coerce these sets of instances into a skos:ConceptScheme, but I've been treating them as a controlled vocabulary. Is there anything I need to consider or adjust to avoid a (minor) collision with CDIF?
Thanks,
Donald

Donald Hobern
Data Management Director, Australian Plant Phenomics Network
University of Adelaide - working from Canberra, ACT

P (04) 20511471   |  plantphenomics.org.au   |   subscribe to our news 
APPN acknowledges the Traditional Custodians of Country throughout Australia and their connections to land, sea and community. We pay our respect to their Elders past and present and extend that respect to all Aboriginal and Torres Strait Islander peoples today.
The Australian Plant Phenomics Network (APPN) is supported by the Australian Government’s National Collaborative Research Infrastructure Strategy (NCRIS)
APPN National Head Office at the University of Adelaide (UoA - CRICOS provider number 00123M). This email (and any attachment) is confidential and may also be privileged or otherwise exempt from disclosure. It is intended only for the addressee. If you are not the intended recipient, please delete it and do not send it on, copy it or disclose its contents. No assurance is given about the security of information sent electronically. Think green and read on the screen.-- 
cdif-community mailing list
cdif-community at lists.codata.org
http://lists.codata.org/mailman/listinfo/cdif-community_lists.codata.org
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.codata.org/pipermail/cdif-community_lists.codata.org/attachments/20251013/35005657/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-fumuy2g0.png
Type: image/png
Size: 25838 bytes
Desc: not available
URL: <http://lists.codata.org/pipermail/cdif-community_lists.codata.org/attachments/20251013/35005657/attachment-0001.png>