publish extra data, link to external data about spec-jsonld HOT 5 CLOSED

You should also consider publishing using established ontologies. Eg with schemaorg, this could look like:

@prefix uncefact: <https://service.unece.org/trade/uncefact/>.
@prefix unlocode: <https://service.unece.org/trade/uncefact/vocabulary/unlocode/>.
@prefix schema: <http://schema.org/>.

unlocode:CHGVA a schema:State;
  schema:name "Geneve";
  uncefact:locode "CHGVA";
  schema:containedInPlace unlocode:CH;
  schema:sameAs <https://sws.geonames.org/2660645/>.

uncefact:locode rdfs:subPropertyOf schema:identifier.

(All LOCODEs are ADM1 administrative divisions, right?

from spec-jsonld.

Well there's an interesting question here. UNECE is the authority for locodes but they are published as csv / pdf etc not as a json-ld vocabulary.

Our project has taken a simple mapping approach for all codes - of which locked us only one. But it loses rich semantics when the code list is a richer data set than simple name-value pairs (like locode which has port type etc)

Looks like locode.info has done a nice job - but is it authoritative? I suspect that, as an official UNCEFACT project, we should define a better vocabulary publishing model for locodes (pathos's inspired by locode.info) and basically do a proper job of it

from spec-jsonld.

@onthebreeze, or we could make a statement which points at locode.info and pull it from vocab on the UN server. I certainly have little appetite to reinvent the wheel and repeat what has been done already. Plus, if locode.info is already in use, it's arguably an anti-pattern to introduce a new one. @VladimirAlexiev I'd love your input on these considerations?

from spec-jsonld.

I don't know where locode.info came from, or who uses them.
If you have authoritative LOCODE info, it's better to use it: I hope it won't be a lot of work to map it.

@onthebreeze would you care to make issue(s) for other codelists that can be enriched, i.e. all of their data published as JSONLD?

from spec-jsonld.

I added a note about this in the NDR spec. I think that's as far as we should go; it's really not a recommendation as long as we have no idea of how it is maintained - if at all.

from spec-jsonld.