traceability ontology

[VladimirAlexiev]

@nissimsan provoked me in https://github.com/w3c-ccg/traceability-vocab/issues/230#issuecomment-1023049089

I have not heard any talks of a "traceability ontology" here, and doubt it will be scoped any time soon.

(Ok that was a joke).

Seriously though, such an ontology is needed because:

• You define a lot of new terms.
• You reuse terms from a lot of ontologies, but they not always point to a class from the same ontology

Mistakes in #270 are closely related to this. When you say in a schema.yml:

$linkedData:
      term: freight
      '@id': https://schema.org/ParcelDelivery

What you really mean is a transparency.ttl ontology with this:

transparency:freight a owl:ObjectProperty;
  rdfs:range schema:ParcelDelivery.

There are a lot of intricacies, eg

• whether to use rdfs:(domain|range) or schema:(domain|range)Includes :
  • the former are monomorphic=single-valued, and prescriptive (have ontological implications, defined in the RDFS spec, which infers new shit rather than constrains).
  • the latter are polymorphic=multi-valued, and advisory (descriptive).
• whether to use OWL constructs, in particular to specify property attachment and cardinality per class

uncl1153:Bill_of_lading_number rdfs:subPropertyOf schema:identifier belongs on the UN/CEFACT side. I'm involved in that project too and will raise it there.

That may well be (didn't know you can move mountains :-)) But since you reuse multiple ontologies in a customized way, there are a lot more ontological statements you'd need to make.

• some call making statemetns agants someone else's URLs "namespace hijacking"
• I call it making "application profiles", which specify how you mix-n-match and coordinate the use of multiple ontologies together. See example of such reuse in EBG: https://github.com/euBusinessGraph/eubg-data/blob/master/model/ebg-ontology.ttl

---

Some resources:

• The euBusinessGraph Ontology: a Lightweight Ontology for Harmonizing Basic Company Information (SWJ 2021) describes that
  • RDFS (and OWL) represent stronger ontological commitment and make ontologies harder to reuse
  • the schema.org approach is lighter-weight, less constrained, and makes ontologies easier to reuse
• https://github.com/gs1/EPCIS/tree/master/Ontology:
  • EPCIS.ttl to see that GTIN, GLN etc are not just string IDs but lead to particular classes
  • maybe CBV.ttl (these are just nomenclatures)
• Mapping of EPCIS ids to classes
• EPCIS Semantics for a lot more on these topics

[OR13]

backing up for a second, the original goal of this work was to map JSON Schema types to JSON-LD vocabularies, and generate documentation and context from the JSON Schema types.

There are cases where we "needed to invent something"... and I regret pretty much every instance.

I do think we are on the hook for correcting those cases and minimizing them.

You reuse terms from a lot of ontologies, but they not always point to a class from the same ontology

I think this is the most obvious flaw with the current approach... but I see it as something which we should fix, and not embrace / perpetuate with a "new ontology"... but I could be convinced.

[VladimirAlexiev]

@OR13 that's not a flaw!

• it's a fact of daily life: I haven't done one semantic project that uses less than 5-10 ontologies
• the craft is how to use them together, and you specify that with a "glue" ontology, RDF Shapes, Application Profiles, or good documentation. Your schemas kind of do the same, but it's not the whole story
• I call this "semantic modeling" as opposed to "ontology engineering" (which some pervert to mean "I don't know or care what others have done, I'll just make my own ontology")
• I agree to minimize own classes and props, but you'd always need to add some. More importantly, you need to "localize" external props to your specific domain model

Seems you'll need help with the ontological approach, and I'll lend a hand. Here are some issues that force you to consider classes, props, subclasses, and other ontological constructs. Please comment on them!

• 273

• 277

• 290

We already had an example of a subproperty: uncl1153:Consignment_identifier_carrier_assigned rdfs:subPropertyOf schema:identifier

In that case @nissimsan said he'll add it in the UNECE ontology. But it's very rare to be able to modify an external ontology: It is ok to add such adjustments to your own glue ontology!

[OR13]

I think I may have misread your comment.

I was trying to say, we should be careful not to go crazy with glue, and we should prefer to fix issues upstream when we can... but I agree some amount of glue is always necessary.

[VladimirAlexiev]

@OR13 @nissimsan Let me give you a very simple example:

    "Observation": {
      "@id": "https://schema.org/Observation",
      "@context": {
        "property": {
          "@id": "https://schema.org/measuredProperty"
        "measurement": {
          "@id": "https://w3id.org/traceability#MeasuredValue" // Why not schema:measuredValue?
        "date": {
          "@id": "https://schema.org/observationDate"
    "MeasuredValue": {
      "@id": "https://www.schema.org/QuantitativeValue",
      "@context": {
        "value": {
          "@id": "https://www.schema.org/value"
        "unitCode": {
          "@id": "https://schema.org/unitCode"

So you want to use schema:Observation, but in measuredValue you want to have both value and unitCode (why didn't they think of that?).

But the above doesn't express that! It mistakenly maps measurement (prop) to tr:MeasuredValue (class).

What you need is to map measurement to schema:measuredValue, and then add to traceability.ttl:

schema:measuredValue schema:rangeIncludes schema:QuantitativeValue.

This way YOUR ontology amends the definition of that prop to include one more possible range, the one you need.

Or, you can post to https://github.com/schemaorg/schemaorg/issues, and wait 2 years, and have your issue closed for inactivity. Happened to me many times. See https://github.com/schemaorg/schemaorg/issues/2573.

[OR13]

"@id": "https://w3id.org/traceability#MeasuredValue" // Why not schema:measuredValue?

another bug : )

As I said, we area erroneously defining terms all over the place, when a better existing reference is available.

[OR13]

@nissimsan @BenjaminMoe please propose concrete changes.

[nissimsan]

I think we might have more of an ontology than I was aware of... This should be described better.

[BenjaminMoe]

Added Pending Close by mistake.

[VladimirAlexiev]

I have not heard any talks of a "traceability ontology" here, and doubt it will be scoped any time soon.

I think we might have more of an ontology than I was aware of...

Ok, that's a positive evolution :-)

[BenjaminMoe]

@nissimsan any updates?

[BenjaminMoe]

Suggestion: have a section in the respec document for terms we accidentally need to define.

[nissimsan]

Building a complete ontology would be great. Unfortunately there does not seem to be bandwidth to implement this. Closing for now. Would be great to reopen if there is interest in implementation.