- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Tue, 2 Jul 2019 19:12:40 +0200
- To: <public-dxwg-wg@w3.org>
And adding to Karen's precision, at a different level... Some of the discussion about adding the "may" in the definition comes from trying to capture the notion of specification/profile as it's currently in DCAT (well, one of the two notions that DCAT has) and CONNEG. So we inherit their cases, here. Antoine On 02/07/2019 00:07, Karen Coyle wrote: > Anything with "may" is not a strict constraint. We have a lot of > requirements in section that read "may" and "should" but not "must". > Remember, and this gets confusing, we are talking about the definition > of profiles in general - any one profile could be quite specific, but a > statement like "Profiles may provide rules governing value validity" is > not a strict constraint on profiles. They may provide those rules, but > if they don't, they don't. > > In checking, in the requirements document, section 6.11, there are no > instances of MUST, and the requirements are generally worded as "can" > "may", etc. In the profiles guidance document (which admittedly is > incomplete) we have only one instance of MUST: discoverability of the > profile: > > "5.1 Profile metadata [RPFMD] > > Profiles must be discoverable through a machine-readable metadata that > describes what is offered and how to invoke the offered profiles." > > There is a note about requiring a URI for a profile as MUST, but it is > from a github discussion, not a requirement: > > "Note > (Antoine:) From > https://github.com/w3c/dxwg/issues/242#issuecomment-408916364, > Administrative metadata: > > A profile MUST have URI (or an IRI?) identifying it. The URI SHOULD > be an http URI > creator/maintainer (+ contact info) > date/version > etc" > > kc > > On 7/1/19 2:46 PM, Rob Atkinson wrote: >> I think it may be even more useful to try to capture what seem to be >> missing requirements and propose a Use Case that explains what you are >> getting at with notions of suggestions that are not strict constraints. >> I have no objections to expanding the scope of the definition to meet >> such needs if there is a consesus to accept such a use case, but i dont >> think we can ignore effort and process so far and develop a definition >> not supported by agreed use cases. >> >> E.g. i can see a value in a new property prof:followsRecommendations to >> use in conjunction with dc:conformsTo and a property >> prof:makes Recommendations rdfs:range dct:Standard >> >> And even prof:constrainsProperty x >> And prof:suggestsUseOf x >> >> Etc. >> >> As long as we follow a procesd of grounding in agreed use cases. >> >> >> >> On Tue, 2 Jul 2019, 05:53 Karen Coyle <kcoyle@kcoyle.net >> <mailto:kcoyle@kcoyle.net>> wrote: >> >> All, >> >> In order to get some traction on profile definition, I'd like to suggest >> that we do a very loose straw poll just to see how the group is leaning. >> There is a lot of discussion but only a few actual proposals, so I >> suggest taking a straw vote on these three proposals, which seem to >> cover the main directions: >> >> 1) Antoine's version of the current definition using "may" [1] >> 2) Tom's version but with the looser list of qualities suggested by >> Karen [2] >> 3) Richard's version emphasizing conformance [3] >> >> We can up/down vote these on github with the emoji's. We could limit >> each person to one up vote, but I think we should ask people to vote on >> each one, either up or down, as a way to testing the waters. This won't >> be a deciding vote but a view of how people are leaning today, and some >> folks may be happy enough with more than one option. >> >> How does that sound? >> kc >> >> [1] https://github.com/w3c/dxwg/issues/963#issuecomment-506436886 >> [2] https://github.com/w3c/dxwg/issues/963#issuecomment-507129887 >> [3] https://github.com/w3c/dxwg/issues/963#issuecomment-506438552 >> -- >> Karen Coyle >> kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net >> skype: kcoylenet >> >
Received on Tuesday, 2 July 2019 17:13:06 UTC