Problems in untp-core ontology

[VladimirAlexiev]

I got https://jargon.sh/user/unece/untp-core/v/working/artefacts/jsonld/render.jsonld, saved as untp-core-ontology.jsonld, and converted to turtle untp-core-ontology.ttl, eg

riot --formatted ttl untp-core-ontology.jsonld > untp-core-ontology.ttl 

Problems:

• [ ] there's no owl:Ontology node with metadata (name, who, when, version number, preferredNamespaceUri and prefix)

Props

• [ ] 5 props use wrong range schema:name (that's a prop so it cannot be a range!) and wrong type owl:ObjectProperty (a name is a string not an object!), eg

  untp-core:facilityName
      rdf:type               owl:ObjectProperty , rdf:Property ;
      rdfs:comment           "The name of the facility, represented as a text string." ;
      rdfs:label             "facilityName" ;
      schema:domainIncludes  untp-core:Facility ;
      schema:rangeIncludes   schema:name .

  There's no reason to use different props for the name of things. So remove all these props, and just say:

  schema:name schema:domainIncludes  untp-core:Facility, untp-core:Standard, untp-core:Product...

• [ ] 3 props violate naming convention: Latitude, Longditude, MaterialName
• [ ] Remove MaterialName and just use schema:name as described 2 items above

Enumerations

• [ ] A number of enumeration classes are used but not defined, eg

  untp-core:hashMethod  rdf:type  owl:ObjectProperty , rdf:Property ;
      schema:rangeIncludes   untp-core:hashMethodCode .
  <https://test.uncefact.org/vocabulary/untp/core/hashMethodCode#SHA-256>
      rdf:type        untp-core:hashMethodCode .

• [ ] These classes should conform to naming convention, eg HashMethod
• [ ] They must NOT have a suffix "Code". A hash method is NOT a code, it's only identified by a code but has a life of its own.
• [ ] The values use undefined prop untp-core:Name (which also doesn't conform to naming convention). Just use schema:name
• [ ] The values use an unhealthy mix of 3 props. Never all 3 are populated, and there are parasitic empty values (eg below). Just use schema:name, schema:description

      rdf:value       "Secure Hash Algorithm 256 bits" ;
      rdfs:comment    "" ;
      untp-core:Name  "SHA-256" .

[Fak3]

@VladimirAlexiev

There's no reason to use different props for the name of things. So remove all these props, and just say:

schema:name schema:domainIncludes  untp-core:Facility, untp-core:Standard, untp-core:Product... untp-core:hashMethodCode .

I wonder if we should make all our classes inherit from schema:Thing instead of changing the domain of schema:name. Is there any potential downsides?

[VladimirAlexiev]

@Fak3 I dislike overly abstract classes like Thing and making such classes and deep class hierarchies just for the purpose of binding props to classes.

• I prefer to have only classes that are useful for querying.
• Then you discover not all of your things have name and you start making "flavor" or "interface" classes like Nameable, Identifiable ...

[onthebreeze]

So @VladimirAlexiev - I've been back and forth with specific names vs abstract names. I did have Facility.facilityName - then changed it to facility.name (inherited from identifier). Some ontologists like specific property names and some seem to like abstraction inheritance.

personally I think I prefer specifc names and identifiers - but I'm a bit fed up of swaying with the winds of opinion on this. Is there some external best practice reference that we can follow?

[Fak3]

personally I think I prefer specifc names and identifiers - but I'm a bit fed up of swaying with the winds of opinion on this. Is there some external best practice reference that we can follow?

Yes, the relevant best practices on the web document recommends to reuse vocabularies: https://www.w3.org/TR/dwbp/#ReuseVocabularies

[Fak3]

I did have Facility.facilityName - then changed it to facility.name (inherited from identifier).

Name should not inherit from identifier. Identifier is unique, name is not.

[onthebreeze]

Well of course vocabulary re-use is best practice.

But the question was about best practice vocabulary design - more abstract (thing.name) or more concrete (party.name)

[VladimirAlexiev]

@onthebreeze I don't know who do you trust (why not me? :-).

• Occam's Razor dictates not to proliferate props needlessly
• some of the best ontologists work on FIBO. See https://github.com/edmcouncil/fibo/blob/master/ONTOLOGY_GUIDE.md sec Overarching Principles item 2

There's a lot of useful advice in that guide, eg see about Definitions