What is the level of the inheritance link?

[aisaac]

This is a spin-off from #642. The example provided there uses the property prof:inheritedFrom between a Resource Descriptor and a Profile.

As @kcoyle noted, all of the requirements related to inheritance all speak of profile inheritance. From the draft profiles guidance document: "2..4 Profile inheritance [RPFINHER] Profiles may add to or specialise clauses from one or more base specifications. Such profiles inherit all the constraints from base specifications."

In addition we have this, which I think may also refer to resources rather than profiles:
"2.3 Profile of profiles [RPFPP] One can create a profile of profiles, with elements potentially inherited on several levels."

We've talked a lot about 'profile inheritance' and prof:isInheritedFrom may be about something slightly different (maybe a "consequence" of profile inheritance, but for the resources that embody these profiles).

NB: this issue is part of a wider discussion on profile inheritance (#748, #795 , #842, maybe #800, and 769), and we should try to avoid putting everything of that discussion into it!!!

In particular PROF's take on the matter of inheritance (as per the level where prof:inheritedFrom should be applied) is only one of the aspects to consider.

[aisaac]

There are some discussions in #642 about 'flattening' profiles but I am not sure this is about the issue.

[nicholascar]

From the definition of prof:isInheritedFrom:

:isInheritedFrom rdf:type owl:ObjectProperty ;
               rdfs:domain :ResourceDescriptor ;
               rdfs:range :Profile ;
               skos:definition "This property indicates a Resource Descriptor described 
                                by this Profile’s base specification that is to be 
                                considered a Resource Descriptor for this Profile 
                                also"@en ;
               ...

This description may not have been fully present in PROF which this issue was first raised.

The reference to base specification in the description above indicates that the 'level' may be any 'level' by which I mean path distance through a hierarchy of prof:isProfileOf. A profile's ResourceDescriptor instances can be inherited from anything (Profiles/Specifications) that this profile profiles directly or indirectly.

@aisaac does this explain the 'level' question adequately?

[nicholascar]

PROF's view on this hasn't changed for a while so I'm removing the PROF link to this Issue (after a week's prof-due-for-closing).

[aisaac]

@nicholascar is the definition you've cited still up-to-date (and expected to be stable)?

If yes it doesn't answer the question. Well, more precisely there's a contradiction between:

• the definition of the property "This property indicates a Resource Descriptor described by this Profile’s base specification"
• the formal rdfs:range of the property (apparently set to Profile, not to Resource Descriptor as the definition indicates)
• your claim "A profile's ResourceDescriptor instances can be inherited from anything (Profiles/Specifications) that this profile profiles directly or indirectly."

[rob-metalinkage]

This issue already in the right place covers this - and has an updated definition already:

w3c/dx-prof#18

closing this now as its not relevant in tjhis repo and the link to a current issue is present.

[aisaac]

No w3c/dx-prof#18 cannot be used to close this issue. #18 is very technical (vocabulary-level) and can be solved without an appropriate answer to this issue.

I happened to mention these vocabulary issues because @nicholascar wanted to use the vocabulary to answer the question for this issue. But essentially this issue is one of data modeling. This is not to say that @nicholascar was wrong when trying to use the vocabulary to bring an answer to the question. It's just that because of the contradictions in the vocabulary, I couldn't really see the data modeling rationale behind.

(by the way the technical problems I've mentioned for PROF in my comment above are not handled by w3c/dx-prof#18, so maybe you'd want to create another issue for them)

[nicholascar]

@rob-metalinkage @aisaac note I used the prof-due-for-closing, not the due for closing tag. My intention was that, after a week, to remove the profiles-vocabulary tag so this would be an issue left in the DXWG repo for Guidance only! So we shouldn't close it but it is now irrelevant to PROF!

[aisaac]

@nicholascar good point! I could completely live with the issue being open only "from the perspective of Profile Guidance" for the moment.

[rob-metalinkage]

OK happy for this to be moved to a guidance if people want to scope profile guidance to look at the general nature of conformance and testability that is fine and up to them - we shouldnt need to reference PROF as that discussion wont affect the specific case PROF supports, which is machine readability of transitive conformance statements and discovery of related resources. PROF provides A solution to these requirements - other approaches are possible, and profile guidance may even choose to allow anybody to call things a profile even if they dont meet these or any other identifiable requirements.

i suggest rewording this issue however because the first statement is explicitly about use pf prof: - thats the wording that will appear when including into a guidance document, and it certainly made me misinterpret the scope of this issue.

[aisaac]

@rob-metalinkage good point. I've tried to add a last scoping sentence on the issue to clarify that PROF is only one element of the discussion.
In fact I think that what is needed from PROF is only a clarification on what is the level where prof:inheritedFrom applies. Then we could decide whether the more general group take on it would be the same, or something more general, or no stance at all.
The problem is that as per my comment at #857 (comment) when looking at the detail there is a lack of consistency on the PROF approach. It would be nice if there would be a (separate) PROF action that solves this and then we can give you a break for a while!

[rob-metalinkage]

Annotate w3c/dx-prof#18 with any details you think show an issue with the PROF approach, then very happy to look into them,

[aisaac]

@rob-metalinkage ok done! Note it may not be a problem with the approach, but with the implementation of the approach (or the discourse around it), some components seeming at odds with others. Let's discuss this there.

[rob-metalinkage]

not a prof or connegp issue - its a profile guidance discussion as per @aisaac comment