Introduce Profiles

[fkleedorfer]

This is a first implementation that does something - but definitely not final, yet.

However, a version of the profile system is starting to take shape. Comments and contributions are highly welcome.

For details, see the profile README.md

How to see the results

Run

mvn install

This will generate the profiles in

target/dist/profile/[profilename]

After the first successful run, you can run just the profilePipeline with

mvn rdfio:pipeline@profile

Which saves a lot of time if all you changed was the profile pipeline or a profile configuration.

Requirements

• recombination of profiles should be possible
  • think about different dimensions of profiles (e.g. language of labels = German, no latex stuff ... , domain = microbiology)
  • also different algorithmic functions
    • filter entities/resources
    • filter triples in the result
• computed profiles (via a query)
• profile should carry a version so you know whether or not it is up to date ... or not?
• profile should have 'graphmetadata' or maybe 'profilemetadata'
• the graph should have a role - 'profile', ie:eg vaem:hasGraphRole vaem:ProfileGraph ;
• algorithm for including triples if they are needed
• what if people exclude things that are 'required'?
• NOTE: systemOfUnit is a kind of profile in its own right - let's not redefine that

[steveraysteveray]

Some initial impressions:

1. The generated QUDT-all-in-one-SHACL.ttl file should always include the src/main/rdf/validation/COLLECTION_QUDT_USER_TESTS.ttl contents, so that user validation can still occur.
2. It wasn't totally clear when reading the README.md, but I think I can just add one line directly after

<foreach>
    <values>
        <in>
           construction

such as

<foreach>
    <values>
        <in>
           construction
           myprofile

Right?

3. Suggest you rephrase:
   "Add two files in that folder:" to "Add two files in folder src/main/profile/<profile-name>:"
4. Your use of ?profile in the documentation had me confused for a while, as I thought it was just a variable name in the algorithms. After looking at your construction includes.ttl files I realized the README is using ?profile the way I have used <profile-name>. Not sure how to make that clearer other than encouraging the developer to look at the construction example.
5. I'm experimenting to see what else gets added beyond the unit being explicitly listed in the includes file. I had the impression that it would transitively follow links, such as the referenced quantitykinds and dimensionvector, but it's not doing that for me.

Very interesting so far...

[steveraysteveray]

Another question. In my experiment branch, my includes file contains:

profile:construction
  a qudt:Profile ;
  qudt:includes pfx:Kilo ;
  qudt:includes quantitykind:ElectricCurrent ;
  qudt:includes unit:A ;

...plus other units...

and my excludes file contains:

profile:construction
  a qudt:Profile ;
  qudt:excludes unit:A_Ab .

No problem that the same instance URI is used, i.e. profile:construction ?

Assuming the answer is no, the exclude statement seems to have no effect so far.

[fkleedorfer]

It wasn't totally clear when reading the README.md, but I think I can just add one line directly after

   <values>
      <in>
          construction

such as

<foreach>
   <values>
       <in>
          construction
          myprofile

Right?

Right.

[fkleedorfer]

No problem that the same instance URI is used, i.e. profile:construction ?

Yes and no:

• you should use the same IRI in both files to identify your profile
• you might not want to use an IRI that is already used to identify another profile (profile:construction identifies the profile for the construction industry)

[fkleedorfer]

Assuming the answer is no, the exclude statement seems to have no effect so far.

You are excluding unit:A_Ab, which will not have an effect unless you include it first. Excluding can only remove from already included entities. (in the current version of the algorithm)

[steveraysteveray]

unit:A_Ab got added I think because of a qudt:applicableUnit link from ElectricCurrent (I think). So then I tried blocking qudt:applicableUnit, which didn't help. I'm doing my experiment on the srr-test-profiles branch on top of yours. I'll push it so you can see. I'm just overwriting your construction profile on my branch.

My branch is way out of date from yours, so I'm going to start a new branch to catch up.