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

Customize CubiQL based on data #64

Closed
zeginis opened this issue Dec 6, 2017 · 4 comments
Closed

Customize CubiQL based on data #64

zeginis opened this issue Dec 6, 2017 · 4 comments

Comments

@zeginis
Copy link
Contributor

zeginis commented Dec 6, 2017

I tried to run CubiQL at our server and phased a number of issues related to the conventions made based on the Scottish data.The issues where:

  • the qb:order is mandatory field at the qb:Dimension (our data did not have qb:order)
  • greek labels were not supported
  • language tag (e.g. @en) causes errors
  • the dataset is required to have both an rdfs:label and rdfs:comment (our data has only rdfs:label)
  • codelists should be defined at the qb:ComponentSpecification. The QB vocabulary requires the code lists to be defined at the qb:DimensionProperty
  • use rdfs:label at the skos:Concept (we used skos:prefLabel)
  • always use the qb:measureType (our data have only one measure, so we did not used measureType)
  • The only dimensions that are allowed to have no codelist are the refArea and refPeriod.
  • Reference area should be defined as: http://purl.org/linked-data/sdmx/2009/dimension#refArea
  • Reference period should be defined as: http://purl.org/linked-data/sdmx/2009/dimension#refPeriod

Is there a way to customize CubiQL to run at different data?
This is highly related to #40

@RickMoynihan
Copy link
Member

RickMoynihan commented Dec 6, 2017

Hi Dimitris, Thanks a million for finding and documenting all these for us.

I think the ticket itself (datafying things) should be covered by #40; but the specific issues you've encountered would I think be better split up into separate tickets; if we don't already have tickets for them... e.g. both the language issues can be covered and discussed by issue #6 (I think the rest are mostly new issues).

I think you're right to want to lump them together though; so would suggest attaching a label to them, or creating a project board for them and tracking them on there?

Sorry to be a pain but if you could submit these as smaller issues tracked on a project board for something like "making cubiql work with other data" might be a better way to manage this.; then we can close this megaticket :-)

@zeginis
Copy link
Contributor Author

zeginis commented Dec 7, 2017

@RickMoynihan I have created the separate issues. However I do not have access rights to create/edit projects

@RickMoynihan
Copy link
Member

Thanks a million @zeginis I'll set that up then...

@RickMoynihan
Copy link
Member

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

2 participants