Relationship of profile to base vocabulary

[kcoyle]

A profile re-uses terms that have been defined previously in some vocabulary(ies). This means that there should be some coordination between the usage in the profile and the original vocabulary. This could become complex, leading us down the road of defining rules for inheritance, but it would be best if we can keep it simple.

Here are some options, please add others, and discuss:

1. Do nothing - leave this up to the humans creating the profiles, with only an admonition that they should not do anything that would conflict with the base (with some examples). The user documentation would ask developers to read the definitions and domains/ranges of the base carefully
2. Define "conflict with the base" in a way that it can be tested. (Note that the simple profile does not have a way to re-define domains but could potentially conflict with ranges)
3. Define "inheritance" from the base, as in: "if label is left blank, use label from base vocabulary"

[tombaker]

Profiles should not depend on upstream vocabularies in any algorithmic sense -- e.g., by "inheriting" their semantics (in the sense of "importing"), or by somehow extracting and reusing their labels, which would be impractically brittle.

It is IMO enough to say that, in general, vocabularies define, while profiles cite, re-use, and constrain. For example, the Primer can suggest that users and developers read the vocabulary specs carefuly (w.r.t. domains and the like). It can also suggest that developers get labels from the base vocabulary if they are left unspecified in the profile. It is enough simply to say this.

Inheritance is a can of worms because the meaning of "inheritance" will always be specific to a particular language or technology. This is basically a term from OO programming, where different programming languages are not even aligned on how to handle things like multiple inheritance. Note that the SHACL and ShEx specifications make no reference to inheritance per se, though they can emulate inheritance-like behaviors in much different ways. Defining "conflict with the base" between a profile and its underlying vocabularies in any sort of algorithmic or formal-semantic way would also inevitably involve different sets of assumptions.

I strongly feel that we should aim at producing a short spec that people can use without too much study. We should avoid getting too fancy with semantics.

[philbarker]

@tombaker I find your first two pararaphs somewhat difficult to understand and on first reading contradictory, but I think that is maybe because of certain meanings you're putting on to "profile" and "inherit". By profile do you mean the csv file or the thing it defines? Because I don't see how you can have a profile that does not depend on upsream vocabularies unless you mean something like the former.

Is it enough to say that instance data that conforms to an application profile must also conform to the vocabularies being profiled? (If data is allowed not to conform to the base vocabulary then I think that you are defining a new spec.)

[tombaker]

@philbarker I did not express my point well. I was trying to say that the interpretation of profiles should not depend on being able to access specific vocabulary files and read or extract their contents algorithmically.

I think we agree that profiles are based on (and in that sense "depend on") vocabularies.

Is it enough to say that instance data that conforms to an application profile must also conform to the vocabularies being profiled?

I agree with this, though "conformance" at this level is not necessarily testable algorithmically, ie in the way that a ShEx schema can be compared to a given graph of data to produce a validation result. It is more like a general principle.

[philbarker]

@tombaker yes, I pretty sure we agree, we're just both finding it difficult to express what we agree on :)

[kcoyle]

Discussion in meeting of October 13, 2022 referred to the assignment of local labels in a profile. Information in cookbook should address the difference between local usage and what happens if RDF inferencing functions are used during processing of data. Local labels should be distinguished from rdfs labels, otherwise conflicts can arise that are difficult to manage programmatically. Essentially a dctap propertyLabel is not an rdfs:label.

[kcoyle]

Covered in cookbook, including the ability to define local labels.