uncefact / spec-jsonld

Exposing the UN/CEFACT vocabulary as web semantics
https://service.unece.org/trade/uncefact/vocabulary/uncefact/
13 stars 5 forks source link

Include section on vocab update frequency #4

Open nissimsan opened 2 years ago

nissimsan commented 2 years ago

Vocab update frequency

nissimsan commented 2 years ago

@fak3

Fak3 commented 2 years ago

tag myself

Fak3 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

Not doing what?

nissimsan commented 2 years ago

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

nissimsan commented 2 years ago

@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 commented 2 years ago

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 ?!