Re: [dxwg] Are PROF roles misplaced in resourceDescription? (#769)

I don't think it relates to those issues so I'm not going to close this. We'll work out how we want to manage the various modeling issues and then re-organize. 

What I'm questioning is whether a "qualified relationship/association" is what's desired here. I think this gets back to what @andrea-perego  was asking at the meeting today, which is what does the resourceDescription represent?  As defined the resourceDescription is a combination of role and dataset description. The other attributes are fine and don't look especially "qualified" to me - just regular description as one does in a catalog. As long as it is describing the nature of the "thing", not a temporary or variable condition, it works. It's just role that bothers me. However, I _am_ assuming that the statement "isInheritedFrom" is always true for the artifact that anchors the resourceDescription in something real. If not, ... well, we get back to "what does the resource descriptor describe"? Is it a thing or a temporary condition?

I'm not only fine with your "c)" I think it will be a fairly common use case. And I think that the roles may change over time. Which is why I want to separate the role and the resource, so those changes do not mean having to define a new resource. If my XX-AP.pdf is initially used for definition and vocabulary and documentation, then I create, as in my example, a SHACL file that includes my vocabulary, I create two new resource descriptions: one for definition and documentation and one for vocabulary. Is this what you intend?

I do think we need to work with examples, and some of those should show how changes take place. I also think that we should consider examples sharing of resources across profiles, even ones not managed by the same folks.  

-- 
GitHub Notification of comment by kcoyle
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/769#issuecomment-465386730 using your GitHub account

Received on Wednesday, 20 February 2019 01:51:40 UTC