Recommendation code lists transformation

[nissimsan]

In extension to https://github.com/edi3/edi3-json-ld-ndr/issues/11, we need the "recommendation" code lists transformed into proper, linkable representations too:

https://unece.org/trade/uncefact/cl-recommendations

[svanteschubert]

When we do a transition from CodeList to RDF semantic graph, the reason is to enrich the former unstructured code list text with structured semantic information that humans are later able to query by traversing the RDF graph using machines. The current quick generated approach is questionable, even if we use some DeepLearning tools manual human interaction is likely always required to build up a rich RDF information set.

In the above example, the user might query for the code list(s) of the following semantics:

1. container
2. container that is sealed
3. container within a range of a volume

A new user will likely not search for "18". If an existing code list user likes to get the RDF information, we should provide to all code lists URLs fragment identifiers (e.g. #18). We might establish this structure even to all previously published HTML documents of UN/CEFACT code lists. The "18" is an identifier and has no semantic value and should not part of the RDF graph unless as part of the identification (being a fragment identifier of an URL like http://tfig.unece.org/contents/recommendation-20.htm#18).

We can also improve any existing CodeList HTML by adding HTML fragment identifiers like https://service.unece.org/trade/untdid/d20b/tred/tred5153.htm#AAL would jump directly to AAL and identify AAL

In addition, we should try to reuse as much as possible existing Wiki URLs, as semantic gets stronger the more it is being used. If any other groups around the world start to do the same thing and map their own code lists to semantic, we would have by this a chance of an intersection (and by this suddenly semantic interoperability).

[AP-G]

Hi Svante, could you provide an example how it should look like, please? As the @id would be the URL fragment, or not?

[svanteschubert]

@AP-G Yes, the id is itself without semantic and would be part of the URL (being the fragment identifier as mentioned above like http://tfig.unece.org/contents/recommendation-20.htm#18

Someone would query for the properties of the semantic, but not the ID (or if known the URL could be used).

[AP-G]

Yes, I know this part, but I was asking for a more concrete example how it would look like syntactically. Can you please provide a "real-world-syntax-example"? Von: Svante @.> Gesendet: Dienstag, 5. Oktober 2021 12:07 An: edi3/edi3-json-ld-ndr @.> Cc: Andreas Pelekies @.>; Mention @.> Betreff: Re: [edi3/edi3-json-ld-ndr] Recommendation code lists transformation (#49)

@AP-Ghttps://github.com/AP-G Yes, the id is itself without semantic and would be part of the URL (being the fragment identifier as mentioned above like http://tfig.unece.org/contents/recommendation-20.htm#18

Someone would query for the properties of the semantic, but not the ID (or if known the URL could be used).

- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/edi3/edi3-json-ld-ndr/issues/49#issuecomment-934262182, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AOAPBEI5NFGUEP6RSA63LJLUFLE2ZANCNFSM4YED7HBA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[svanteschubert]

I tried today to describe the problem from a different perspective: https://github.com/uncefact/vocab/issues/70

@AP-G Andreas, I have the feeling we are cross-talking. Let's take it first offline and have a joint virtual tea break.