Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

REferencing Actual code enumerations from the Code lists class in JSON-LD vocabulary #52

Open
onthebreeze opened this issue May 27, 2021 · 6 comments
Assignees

Comments

@onthebreeze
Copy link
Contributor

From slack thread Andreas Pelekies:

And can you help me with the current implementation of JSON-LD and Code lists, please?
In the vocab the code lists are defined as separated classes without a content. And the properties using the codes are referencing them exactly as defined:

{
            "@id": "uncefact:UNCL2013Code",
            "@type": "rdfs:Class",
            "rdfs:comment": "Code specifying the rate of recurrence.",
            "rdfs:label": "Frequency code"
}

But there is no link to the code list definition itself. For example, the file uncl2013.jsonld contains

"@context": {
    "uncefact": "https://service.unece.org/trade/uncefact/vocabulary/uncefact#",
    "uncl2013": "https://service.unece.org/trade/uncefact/vocabulary/uncl2013#",
    "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#"
  },
  "@graph": [
    {
      "@id": "uncl2013:Annually_(calendar_year)",
      "@type": "uncefact:UNCL2013Code",
      "rdfs:comment": "Code defining a yearly forecast.",
      "rdf:value": "A"
    }

So, it defines uncl2013 (not UNCL2013Code) with the correct URI. But coming from the vocab it is not discoverable. Is this a bug or intended? Or can anyone help me with this how a developer will find out this automatically?

@onthebreeze
Copy link
Contributor Author

@Fak3 and @kshychko

Any comments on this one?

@Fak3
Copy link
Contributor

Fak3 commented May 28, 2021

We can add a link from the uncefact:UNCL2013Code class definition to the url, where its instances (actual codes) are declared - https://service.unece.org/trade/uncefact/vocabulary/uncl2013/
i.e:

{
  "@id": "uncefact:UNCL2013Code",
  "@type": "rdfs:Class",
  "rdfs:comment": [
     "Code specifying the rate of recurrence.",
     "See https://service.unece.org/trade/uncefact/vocabulary/uncl2013/ for a list of available codes"  // ADDED
  ],
  "rdfs:label": "Frequency code",
  "rdfs:seeAlso": "https://service.unece.org/trade/uncefact/vocabulary/uncl2013/"   // ADDED
}

Would that improve discoverability enough?

@onthebreeze
Copy link
Contributor Author

It would certainly enhance discoverability, yes. But is rdfs:seeAlso the right predicate to say "this is the value domain of this property?"

@Fak3
Copy link
Contributor

Fak3 commented May 30, 2021

There is no better predicate that I am aware of.

One thing we can do is to move the UNCL2013Code class definition from uncefact: to uncl2013: namespace, where its instances are declared. This way you will be forced to retrieve the list of all instances along with class definition.

In this case our StarUML plugin should be adapted to separate class from instances on import.

@AP-G
Copy link

AP-G commented May 31, 2021

I'd prefer the latter solution. We should not make it dependent on any tool, not StarUML nor GEFEG or any other. The definition is intended for users without any knowledge of UN/CEFACT or tool-specialities. So, an intuitive usage and discoverability should be the real focus as defined by the REST design principles.

@Fak3
Copy link
Contributor

Fak3 commented Jul 14, 2021

Related to #35

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants