The latter is simple a common context which I can use, provided I call my API attributes the same names which schema.org recommends
So, for example, I could just go ahead and label my attribute edi3:consigment, and then through our standard context that would resolve into https://edi3.org/vocab/#consignment
… This only works if I can and want to use the term consignment. If I wanted to call that attribute something else (like, say, shipment or hullaBulla ) I’d need to introduce my own context which includes:
"hullaBulla": {"@id": "https://edi3.org/vocab/#consignment"}
But as long as I can make my specs use common attr naming (consignment), I shouldn't have (and don't want) to create my own @context.
@Kseniya Shychko, @Roman et al., let me just elaborate on what I raised on the call…
schema.org publishes both:
https://schema.org/version/latest/schemaorg-current-http.jsonldhttps://schema.org/docs/jsonldcontext.jsonThe latter is simple a common context which I can use, provided I call my API attributes the same names which schema.org recommends
So, for example, I could just go ahead and label my attribute
edi3:consigment, and then through our standard context that would resolve intohttps://edi3.org/vocab/#consignment… This only works if I can and want to use the term consignment. If I wanted to call that attribute something else (like, say,
shipmentorhullaBulla) I’d need to introduce my own context which includes:"hullaBulla": {"@id": "https://edi3.org/vocab/#consignment"}But as long as I can make my specs use common attr naming (consignment), I shouldn't have (and don't want) to create my own @context.