Wrong use of `@vocab` in context

[VladimirAlexiev]

https://spdx.github.io/spdx-spec/v3.0.1/rdf/spdx-context.jsonld has many examples like this:

    "ai_autonomyType": {
      "@context": {
        "@vocab": "https://spdx.org/rdf/3.0.1/terms/Core/PresenceType/"
      },
      "@id": "https://spdx.org/rdf/3.0.1/terms/AI/autonomyType",
      "@type": "@vocab"
    },
    "ai_energyConsumption": {
      "@id": "https://spdx.org/rdf/3.0.1/terms/AI/energyConsumption",
      "@type": "@vocab"
    },

• The first use (@vocab:... @type:@vocab) is acceptable.
  • It says "ai_autonomyType: "foo" will be resolved to https://spdx.org/rdf/3.0.1/terms/Core/PresenceType/foo"
  • This is what I used in crafting a "simple context" for GS1 EPCIS, eg see https://github.com/gs1/EPCIS/blob/master/epcis-context-simple.jsonld#L27
  • But some (including JSON-LD creator Manu Sporny) dislike this use and even call it a "bomb"
  • The problem is that even a wrong word ("foo", "bar" or "baz") will be resolved to a URL in the SPDX namespace.
  • So at the end a "complex context" was published for GS1 EPCIS, eg see https://github.com/gs1/EPCIS/blob/master/epcis-context.jsonld#L42 . It's 6x bigger because it enumerates every enum value.
    (Note: I believe that a it should declare each enumerated prop as "@type": "@id" and not "@type": "@vocab", see next)
• The second use (@type: @vocab) is not acceptable since it doesn't specify the @vocab.
  • Nor can it specify any @vocab because this is an intermediate node (holding quantity and unit) not an enumerated value
  • What you mean here is "@type": "@id"

[goneall]

@JPEWdev @zvr - is this something we want to resolve for 3.1 RC1?

[kestewart]

Moving this to -rc2; as none on the call (including zvr) are comfortable tackling this without @JPEWdev input.

[bact]

I think I got it now, please review what I understand @VladimirAlexiev:

--

(A) The @vocab where it should be @id

(your "second use" above)

    "ai_energyConsumption": {
      "@id": "https://spdx.org/rdf/3.0.1/terms/AI/energyConsumption",
      "@type": "@vocab"
    },

The snippet above is wrong because the type of ai_energyConsumption is ai_EnergyConsumption which is a class not an enum. It should instead read:

    "ai_energyConsumption": {
      "@id": "https://spdx.org/rdf/3.0.1/terms/AI/energyConsumption",
      "@type": "@id"
    },

I guess we can fix that by changing the generation code at Line 279, that checking for a class (OWL.Class), here https://github.com/spdx/spec-parser/blob/770e74683e57d1ba880cd40e0f230276f4fb08a4/spec_parser/rdf.py#L276-L280 from "@type": "@vocab" to "@type": "@id".

(see details in issue spdx/spec-parser#204 / PR spdx/spec-parser#205)

--

(B) The @context and the choices of how to manage expansion

(your "first use" above)

This is a bit complicated. I will try.

Currently we have:

    "ai_autonomyType": {
      "@context": {
        "@vocab": "https://spdx.org/rdf/3.0.1/terms/Core/PresenceType/"
      },
      "@id": "https://spdx.org/rdf/3.0.1/terms/AI/autonomyType",
      "@type": "@vocab"
    },

Which works, but considered a bad practice because its unconditional expansion will allow a valid-looking IRI inside the SPDX namespace.

For example, if the SPDX document contains a typo:

    "ai_autonomyType": "yess"

instead of:

   "ai_autonomyType": "yes"

The unconditional expansion will give this IRI:

https://spdx.org/rdf/3.0.1/terms/Core/PresenceType/yess

Compare to if we explicitly list every enum entries and do not allow the expansion if it is not in the list, we will get an IRI like this instead (providing https://example.com/doc/ is a base URI):

https://example.com/doc/yess

Which in outside of SPDX namespace and clearer that it is invalid.

To list enum entries, we can do this:

    "no": {
      "@id": "https://spdx.org/rdf/3.0.1/terms/Core/PresenceType/no",
    },
    "noAssertion": {
      "@id": "https://spdx.org/rdf/3.0.1/terms/Core/PresenceType/noAssertion",
    },
    "yes": {
      "@id": "https://spdx.org/rdf/3.0.1/terms/Core/PresenceType/yes",
    },
    "ai_autonomyType": {
      "@id": "https://spdx.org/rdf/3.0.1/terms/AI/autonomyType",
      "@type": "@vocab"
    },
    "ai_useSensitivePersonalInformation": {
      "@id": "https://spdx.org/rdf/3.0.1/terms/AI/useSensitivePersonalInformation",
      "@type": "@vocab"
    },
    "dataset_hasSensitivePersonalInformation": {
      "@id": "https://spdx.org/rdf/3.0.1/terms/Dataset/hasSensitivePersonalInformation",
      "@type": "@vocab"
    },

(Note: the three properties: ai_autonomyType, ai_useSensitivePersonalInformation, and dataset_hasSensitivePersonalInformation all have the same range PresenceType. We will see them more later.)

But as SPDX has many terms, we are at risk of name collision. And it is the case. "noAssertion" is an entry in four vocabularies in 3.0.1: PresenceType, RelationshipCompleteness, SupportType, and dataset_DatasetType.

To avoid collision, we can to put them in a local context, like this:

    "ai_autonomyType": {
      "@context": {
        "no": {
          "@id": "https://spdx.org/rdf/3.0.1/terms/Core/PresenceType/no",
        },
        "noAssertion": {
          "@id": "https://spdx.org/rdf/3.0.1/terms/Core/PresenceType/noAssertion",
        },
        "yes": {
          "@id": "https://spdx.org/rdf/3.0.1/terms/Core/PresenceType/yes",
        },
      },
      "@id": "https://spdx.org/rdf/3.0.1/terms/AI/autonomyType",
      "@type": "@vocab"
    },
    "ai_useSensitivePersonalInformation": {
      "@context": {
        "no": {
          "@id": "https://spdx.org/rdf/3.0.1/terms/Core/PresenceType/no",
        },
        "noAssertion": {
          "@id": "https://spdx.org/rdf/3.0.1/terms/Core/PresenceType/noAssertion",
        },
        "yes": {
          "@id": "https://spdx.org/rdf/3.0.1/terms/Core/PresenceType/yes",
        },
      },
      "@id": "https://spdx.org/rdf/3.0.1/terms/AI/useSensitivePersonalInformation",
      "@type": "@vocab"
    },
    "dataset_hasSensitivePersonalInformation": {
      "@context": {
        "no": {
          "@id": "https://spdx.org/rdf/3.0.1/terms/Core/PresenceType/no",
        },
        "noAssertion": {
          "@id": "https://spdx.org/rdf/3.0.1/terms/Core/PresenceType/noAssertion",
        },
        "yes": {
          "@id": "https://spdx.org/rdf/3.0.1/terms/Core/PresenceType/yes",
        },
      },
      "@id": "https://spdx.org/rdf/3.0.1/terms/Dataset/hasSensitivePersonalInformation",
      "@type": "@vocab"
    },

But as you can imagine, this will result in a very huge context file.

The situation can be improved with some more contexts:

{
  "@context": {
    "spdx": "https://spdx.org/rdf/3.0.1/terms/Core/",
    "spdx-ai": "https://spdx.org/rdf/3.0.1/terms/AI/",
    "spdx-d": "https://spdx.org/rdf/3.0.1/terms/Dataset/",
    "xsd": "http://www.w3.org/2001/XMLSchema#",

    "PresenceType_no": {
      "@id": "spdx:PresenceType/no",
    },
    "PresenceType_noAssertion": {
      "@id": "spdx:PresenceType/noAssertion",
    },
    "PresenceType_yes": {
      "@id": "spdx:PresenceType/yes",
    },

    "ai_autonomyType": {
      "@context": {
        "no": "PresenceType_no",
        "noAssertion": "PresenceType_noAssertion",
        "yes": "PresenceType_yes"
      },
      "@id": "spdx-ai:autonomyType",
      "@type": "@vocab",
    },
    "ai_useSensitivePersonalInformation": {
      "@context": {
        "no": "PresenceType_no",
        "noAssertion": "PresenceType_noAssertion",
        "yes": "PresenceType_yes"
      },
      "@id": "spdx-ai:useSensitivePersonalInformation",
      "@type": "@vocab"
    },
    "dataset_hasSensitivePersonalInformation": {
      "@context": {
        "no": "PresenceType_no",
        "noAssertion": "PresenceType_noAssertion",
        "yes": "PresenceType_yes"
      },
      "@id": "spdx-d:hasSensitivePersonalInformation",
      "@type": "@vocab"
    },

Is this correct? @VladimirAlexiev

--

See generated files here (it also use @protected, as we discussed in spdx/spdx-spec#1312):

• spdx-context.jsonld.txt
• spdx-model.ttl.txt