Use the PROF vocabulary to to supply profiles

[nicholascar]

Instead of using keeping the various disciplines, Finance, Science, etc. just in separate file, they could be declared as profiles of QUDT using the W3C's Profiles Vocabulary.

Anything that conforms to a Profile, MUST conform to the QUDT base specification while a profile may also implement additional constraints on the base specification.

This would look something like this:

(the profile declaration file for Finance)

@prefix prof: <http://www.w3.org/ns/dx/prof/> .  # the Profiles Vocabulary
@prefix role: <http://www.w3.org/ns/dx/prof/role/> .  # the vocabulary of profile part roles

<http://qudt.org/2.0/schema/qudt/finance>
  a owl:Ontology ;  # this is still an ontology
  a prof:Profile ;     # additionally it's a profile, of the main QUDT
  prof:isProfileOf <http://qudt.org/2.1/schema/qudt> ;  # QUDT identified by namespace URI
  rdfs:label "QUDT Schema - Finance" ;
  owl:imports <http://qudt.org/2.1/schema/qudt> ;  # owl:imports owl:subPropertyOf prof:isProfileOf 
  prof:hasResource [
    a prof:ResourceDescriptor ;  # this is one of the elements of the profile
    prof:hasRole role:vocabulary ;  # the role of this ResourceDescriptor
    prof:hasArtifact <SOME-FILE-IN-THE-QUDT-REPO> ;  # the actual vocab file
  ] ;
  prof:hasResource [
    a prof:ResourceDescriptor ;  
    # other ResourceDescriptors, if relevant
  ] ;
...
.

In this example, QUDT All contains all of QUDT and this profile for Finance imports it and then extends on it with any new elements that it declares within the vocabulary resource indicated. If the Finance sector has additional validation rules, guidance documents or examples, additional ResourceDescriptors can be described.

The purpose of doing this the PROF way is that now all of generic QUDT is in one place and Finance just declares the extra, finance-only, bits.

[nicholascar]

I volunteer to profile-ise QUDT disciplines, if the consortium votes for this.

[steveraysteveray]

I definitely prefer "outside pointing in" (i.e. profiles/views) to "inside pointing out" (i.e. tags), because as the number of disciplines grows, a given unit would have gobs of tags attached to it, with all but one of them of no relevance to a given application.

Here's the way I see this being architected:

1. An external instance (be it a profile instance or a discipline instance) that points to all the relevant quantity kinds for that perspective/profile/discipline.
2. An identification of the desired system of units for that perspective/profile/discipline (e.g. SI or Imperial).
3. From those two pieces of information, one can assemble the "intersection" set of units that are pointed to by both the profile and the system of units.
4. One could then export an rdf file of that specialized set of units, along with the supporting quantity kinds and dimension vectors, for use in whatever application, if the size of the QUDT vocabularies is a problem (which would surprise me, but I suppose could happen for some).

@nicholascar, have you taken a look at the file vocab/disciplines/VOCAB_QUDT-DISCIPLINES-v2.1.ttl ? It is in a fairly raw state and hasn't been scrubbed, but it shows some examples (see the Chemistry instance), where a bunch of quantity kinds are identified. Is this along the lines of what you are proposing?

Rega

[nicholascar]

1. An external instance

Generically this could be a Profile and specifically an Discipline in that the Profile artefact is just a container that has relations to other things (here to all of QUDT) but it can easily be typed (a qudt:Discipline etc.) if there's value in doing so.

2. An identification of the desired system of units for that perspective/profile/discipline (e.g. SI or Imperial

This could be specified as a Profile rule and implemented by the selection of only that sort of unit for inclusion. A constraints language (SHACL) file can be written to ensure the rule is explicit.

3. From those two pieces of information, one can assemble the "intersection" set of units that are pointed to by both the profile and the system of units.

The profile can both state the rule for item inclusion and explicitly list the included units. For simple use, stating the units explicitly would be the way to go. For advanced use, having the rule apply to the main QUDT object would be the way to go (a filtering query).

By explicitly stating the elements included in the profile though, we would remove the need for tagging them in QUDT whole, so for this reason, and simple ease of use, I propose to explicitly list them, at least in testing.

4. One could then export an rdf file

Yes, although, as above, the explicit statement of units will make export per se redundant.

Is this [the Chemistry discipline] along the lines of what you are proposing?

Yes though, of course, the use of PROF would allow the listing to be a whole new artefact, not just a node within the DISCIPLINES graph. This means it can be managed a little separately and, critically, it can support more than just RDF things, such as Geosceince-specific validators, text documents (guidance notes), imagery etc. I think these other things, which I would make, are important for a community coming to grips with the use of (a part of) QUDT.

[steveraysteveray]

@nicholascar, we discussed it, and invite you to go ahead and create a profile instance to meet your needs. The philosophy we're comfortable with is the "outside pointing in" approach. The one request I have is that the file(s) you create live in a new folder I just created at the top level, called "community". We think that this could be a good place for all kinds of extensions and other things that build on the core QUDT ontology and vocabularies. And of course, please do this in a new branch that we can then review and merge.

I'm looking forward to seeing what this will look like!

[nicholascar]

Just a note on progress: I'm building the profile from queries against QUDT total and should have a PR in for it perhaps next week. I've formulated the content collection scripts (in https://github.com/geological-survey-of-queensland/qudt-geo-profile-ont) and will now build up the static metadata (e.g. the profile declaration itself using PROF).