- From: Rob Atkinson via GitHub <sysbot+gh@w3.org>
- Date: Thu, 31 Jan 2019 03:33:00 +0000
- To: public-dxwg-wg@w3.org
The answer is not "you shouldn't do that" but rather "we expect people to do any of these things" noting that prof:inheritedFrom applies to the qualified associations of type "ResourceDescriptor" - not on the profile... if Profile "X" has a resource RX declaring a set of constraints on properties A, B,C,G and Profile "Y" is a profile of X and has a resource RY declaring a set of constraints on properties A,B,C,D then... a) the constraints in profile Y on A,B,C must be compatible with the constraints in profile X b) the declared role of resource RY has to be some form of "partial" because is does not include constraints on property G so - we must use declared roles to allow clients to know if they need to look at inherited constraints to validate - or if a full set of constraints have been conveniently packaged. it is up to implementations to worry about checking constraints are satisfiable (non-contradictory) - all we can do is allow these to be found and classified in the chosen flattening/packaging strategy. In guidance - we _could_ suggest that profiles are available in the flattened view with resources defining the full constraints - we could declare a canonical name for this profile of the Profile ontology if you think it would help. to a certain degree, the constrain language will need to define its own syntax and semantics for inheritance - the profiles ontology only allows declaration of intent. -- GitHub Notification of comment by rob-metalinkage Please view or discuss this issue at https://github.com/w3c/dxwg/issues/642#issuecomment-459202204 using your GitHub account
Received on Thursday, 31 January 2019 03:33:02 UTC