How to implement Profiles #1077
fkleedorfer
started this conversation in
Ideas
Replies: 1 comment
-
I suggest we move this thread over to "Discussions" (see the button on the right). Seems more appropriate. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
A common requirement of QUDT users have is that they need only a handful of units/quantitykinds, but by using QUDT, they get thousands.
In order to addres this requirement, we have been discussing the introduction of QUDT profiles.
Here is a suggestion of how these might be implemented:
User facing changes
Distributed files
in the distribution zip, there is an additional top-level folder
profiles
, that contains one sub-folder per QUDT profile, e.g.construction
, orgeophysics
. Each of those profile folders contains the complete QUDT folder structure (as far as they contain rdf) and all QUDT TTL files, containing the profile-specific triples.Linked data
Unclear:
As the information pertaining to individual entities is required to change (e.g. a
qk:Length
will not have aqudt:applicableUnit
unit:ANGSTROM
), we will have to generate different html pages and TTL snippets, which means we will need different URIs for our entities - sayhttp://qudt.org/profile/[profilename]/vocab/unit/M
. This, however, has many downsides.Alternatively, we could provide the whole vocabulary of the profile (i.e, all triples), under one URI, e.g.
http://qudt.org/profile/[profilename]/
, but the URIs in the data remain unchanged.Build process changes
a folder
src/build/profiles
is added, with a subfolder per profile, e.g.construction
, orgeophysics
. The contents of this 'profile build folder' is analyzed during the build process. As a result, thetarget/dist/profiles/[profilename]
folder is generated and populated. The way in which the contents of the profile build folder influence the resulting profile contents is called the 'profile algorithm':Profile algorithm
We can do fancy and complicated things later, here is the simplest thing I can think of:
The algorithm processes each QUDT file (from
target/dist/
) individually.The profile build folder my contain one file per distribution file that influences if and how that file ends up in the profile. These files follow a simple naming convention,e.g. [filename-in-qudt-distribution].config.txt. If there is no such config file for a given distribution file, the distribution file is copied to the profile as-is. If the config file contains the word 'OMIT' and nothing else, the distribution file is omitted altogether. If the config file contains a list of IRIs - one IRI per line, these IRIs are used to filter the subjects of the RDF statements contained in the distribution file: only statements whose subject is listed are copied to the corresponding profile file.
As a second processing step, any references to entities that were filtered out are removed from any of the files. For example, if some quantitykinds are not part of the profile, units referring to these quantitykinds are modified to not include them.
Beta Was this translation helpful? Give feedback.
All reactions