Include section on vocab update frequency

[nissimsan]

Vocab update frequency

• Discussion, how linked data differs from centralized models.
• Pros and cons of frequent/infrequent updates. Stability versus fringe increments.

[nissimsan]

@fak3

[Fak3]

tag myself

[Fak3]

Briefly discussed this with @onthebreeze in the past years. EDI3 issue: https://github.com/edi3/edi3-json-ld-ndr/issues/30

We converged at the point, that adding and deprecating terms in the vocabulary can happen often, new vocab "release" few times per year may happen. It was not investigated much, what kind of issues this may cause. Input welcome.

My thoughts: Vocab "release" is in the quotes because i'm not even certain if vocab versioning is necessary. But json-ld context version is necessary, to avoid ambiguous interpretation, security and caching issues.

As mentioned in the original edi3 issue, we can add metadata to the terms - date when they added\deprecated. Would that be helpful? have to be investigated.

As I mentioned in the edi3 issue, not yet sure how to properly handle the case when a data consumer receives the data with unknown (uncached) context url. Could some policy be developed for this to avoid security and caching issues? have to be investigated. Input welcome.

[nissimsan]

@Fak3 , I actually stumbled upon this exact part of the spec when bringing over this part of the NDR yesterday. I don't think we're actually doing this (any longer).

[Fak3]

Not doing what?

[nissimsan]

https://github.com/uncefact/vocab/pull/33/files#r796478697 This ^

[nissimsan]

@Fak3, can you please share an assessment of how we should be dealing with this. (Note that we will not be forking the model #67 ).

[cmsdroff]

We have a section in here https://github.com/uncefact/vocab/blob/main/docs/tech-spec.md#versioning which covers how the versioning is covered, i've added in that we will tag official releases (for historic and stability).

The question remains if we have implemented the date as below from comments in https://github.com/uncefact/vocab/pull/33/files namely

 {
     "@id": "SupplyChain_Consignment.Consignor.Trade_Party",
     "@type": "edi3:AssociationBIE", 
     "@edi3:cefactUNId": "cefact:UN01004212",
     "edi3:currentStatus":"deprecated",
     "edi3:createdDate": "01-04-2017",
     "edi3:deprecatedDate": "21-03-2020"
 }

Each rdfs class and property in the vocabualry is annotated the same way. The rdfs class or property can only be deprecated when all the RDM BIEs it is linked to are deprecated.

Every time when the vocabulary is updated from the new version of BSP RDM, the new json-ld context file for this vocabualry is created, and published at the new permanent url, e.g https://edi3.org/vocab/2020.09/context.json

TODO: the exact url for the context is to be decided.

I don't think this is implemented looking at https://service.unece.org/trade/uncefact/vocabulary/uncefact.jsonld

@kshychko checking with you if this is this in place/progress I think it might be an easy win for next meeting PR ;) but of course could be completely wrong ?!