-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What is the level of the inheritance link? #857
Comments
There are some discussions in #642 about 'flattening' profiles but I am not sure this is about the issue. |
From the definition of
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 @aisaac does this explain the 'level' question adequately? |
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). |
@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:
|
This issue already in the right place covers this - and has an updated definition already: closing this now as its not relevant in tjhis repo and the link to a current issue is present. |
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) |
@rob-metalinkage @aisaac note I used the |
@nicholascar good point! I could completely live with the issue being open only "from the perspective of Profile Guidance" for the moment. |
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. |
@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. |
Annotate w3c/dx-prof#18 with any details you think show an issue with the PROF approach, then very happy to look into them, |
@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. |
not a prof or connegp issue - its a profile guidance discussion as per @aisaac comment |
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.
The text was updated successfully, but these errors were encountered: