How to implement Profiles

[fkleedorfer]

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, or geophysics. 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 a qudt:applicableUnit unit:ANGSTROM), we will have to generate different html pages and TTL snippets, which means we will need different URIs for our entities - say http://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, or geophysics. The contents of this 'profile build folder' is analyzed during the build process. As a result, the target/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.

EDIT: I suspect that we would only apply this algorithm to the 'vocab' subfolder.

[steveraysteveray]

I suggest we move this thread over to "Discussions" (see the button on the right). Seems more appropriate.

[fkleedorfer]

Here are a few thoughts on how profiles may help with context dependent units: #1079 (comment)

[Toby-Broom]

I like this idea as a smaller number of entities helps with implementation, would there be vocabs for each profile?

[fkleedorfer]

We are in the process of designing this feature, so there is no definitive answer yet. Tentatively, yes. A profile subfolder would contain replacement files in the vocab folder that you would instead of the default ones.