- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Mon, 15 Dec 2014 08:33:55 -0800
- To: public-data-shapes-wg@w3.org
Thanks, Holger. This is looking quite comprehensive. One requirement that comes to mind that I'm not sure is covered in the list so far is related to SKOS -- SKOS itself has a number of validation requirements [1], and those might provide some hints for us. The key ones that the DC group is interested in have to do with rules for labels: - one prefLabel per language tag - altLabel, prefLabel and hiddenLabel cannot have the same value (per language tag) Are these already covered by the requirements in the list? (And I can imagine that these requirements would be an obvious macro/template in a validation language.) kc [1] https://github.com/cmader/qSKOS/wiki/Quality-Issues On 12/14/14 8:39 PM, Holger Knublauch wrote: > I am basically done with my input to the Requirements page [1]. I have > written down all requirements that I am ready to stand up for, explain > and defend (therefore I tagged them with my initials HK). I also went > through the DC requirements database and believe most its scenarios are > covered, except that I left out everything related to inferencing (the > DC database felt like a dump of all OWL features at times). > > My focus was also on low-level language elements that can be used to > build higher-level elements. In particular, I believe if we implement > the requirements as listed then it is possible to use them to represent > higher-level definitions such as irreflexive properties. Macro > mechanisms are covered. Therefore I believe it would be unnecessary to > enumerate all OWL features here, as long as they can be expressed in > lower-level terms. > > I welcome others to contribute, too. Once we have a better feeling about > what the page will contain, we should discuss what to actually do with > all these requirements. Obviously our goal should be to cover as many > requirements as possible, as long as the resulting language doesn't > become an over-complicated mess. Every requirement proposed by group > members should be considered, and introducing yet another intermediate > step to filter out certain requirements before they were considered > sounds like an unnecessary and potentially harmful step. We could get > lost in an over-complicated formal process for the next half a year. I > think we should swiftly move from the list of requirements to the > solution proposals, because it will be important to look at the > implementability and the elegance of the resulting language for those > requirements *before* we can decide whether requirements are in scope or > not. > > Holger > > [1] https://www.w3.org/2014/data-shapes/wiki/Requirements > > > On 12/13/2014 9:38, Peter F. Patel-Schneider wrote: >> I would say no, proposed requirements should be examined before they >> become under consideration, just like issues are first raised and then >> opened and then closed. >> >> peter >> >> >> On 12/12/2014 03:12 PM, Holger Knublauch wrote: >>> >>> On 12/13/14, 2:51 AM, Peter F. Patel-Schneider wrote: >>>> I notice that these are all in the "Under Consideration" section. >>> >>> I moved all new entries from Under Consideration to Unofficial. >>> >>> My assumption was that all Requirements proposed by WG members are Under >>> Consideration. Why would an intermediate step be needed? >>> >>> Also, most user stories have sufficiently matured so that many >>> requirements >>> are crystal clear and well understood, even if the stories are not >>> officially >>> frozen yet. In fact, writing the requirements helped me remember other >>> relevant stories, so this is potentially an interactive process that >>> should be >>> started sooner than later. >>> >>> I would encourage others to start contributing to that page too, so >>> that we >>> can make progress. It's just a Wiki page, not more! >>> >>> Holger >>> >>> >>>> >>>> I was hoping that the working group would adopt a mechanism that >>>> would not >>>> allow working group members to automatically put proposed >>>> requirements under >>>> consideration, but that instead explicit approval would be needed >>>> from the >>>> working group to place requirements under consideration. >>>> >>>> Also, the added requirements have derived-from information that is very >>>> different from the derived-from information that I added. This new >>>> kind of >>>> information needed a different tag, I think. Also, there needs to be >>>> links >>>> to whatever is being referenced, not just simple text tags. >>>> >>>> I would much prefer it if these requirements were moved into the >>>> unofficial >>>> section, at least until the working group has a chance to review >>>> what I did >>>> in response to my action. >>>> >>>> peter >>>> >>>> >>>> On 12/11/2014 08:31 PM, Holger Knublauch wrote: >>>>> I have started adding a few requirements, also to fine tune the >>>>> format and the >>>>> benefits of nesting them in a hierarchy: >>>>> >>>>> https://www.w3.org/2014/data-shapes/wiki/Requirements#Declarations_of_Member_Properties_at_Classes >>>>> >>>>> >>>>> >>>>> >>>>> On this occasion I slightly adjusted Peter's suggested formatting >>>>> to use >>>>> bullet lists and bold face font - to me this looks a bit easier to >>>>> read. I >>>>> hope this is OK. >>>>> >>>>> Holger >>>>> >>>>> >>>>> On 12/12/2014 8:46, Holger Knublauch wrote: >>>>>> Hi Peter, >>>>>> >>>>>> many thanks for starting this. We can iterate it from here. I just >>>>>> wanted to >>>>>> confirm a couple of things. >>>>>> >>>>>> I notice you have apparently bypassed the concept of a hierarchy >>>>>> between the >>>>>> requirements, and instead made a top-level categorization of >>>>>> "Approved" and >>>>>> "Under Consideration". Eric's work had some top-level nodes such as >>>>>> >>>>>> - High-level Language Requirements >>>>>> - Modularization >>>>>> - UI Generation >>>>>> - Foundation >>>>>> - Reasoning/Inference >>>>>> - RDF target constructs >>>>>> - Expressivity >>>>>> - algebraic >>>>>> - lexical patterns >>>>>> - value sets >>>>>> - cardinality >>>>>> - negation >>>>>> - other >>>>>> - multi-record >>>>>> - Protocol/invocation >>>>>> - Implementability >>>>>> - Translation >>>>>> - Outreach >>>>>> - Unclassified >>>>>> >>>>>> I am not saying we should follow the above hierarchy, because even >>>>>> agreeing >>>>>> on such a hierarchy may be too difficult at this stage. So I guess >>>>>> your >>>>>> structure suggests we simply start collecting and then do a second >>>>>> pass to >>>>>> organize and regroup requirements. I can imagine the flat list >>>>>> will quickly >>>>>> be filled with (too) many items. >>>>>> >>>>>> Under "Derived from" I assume we also put links to the user stories. >>>>>> >>>>>> My suggestion is that anyone can now start adding requirements >>>>>> following the >>>>>> template used by Peter, using the controlled term "Derived from" >>>>>> before >>>>>> hyperlinks to details. >>>>>> >>>>>> I believe we should also have a category "Tags" which we could use >>>>>> incrementally to categorize the items. In particular the tags >>>>>> could contain >>>>>> the ID of the original author of the requirement, so that we can >>>>>> keep track >>>>>> of who created what if there are questions for clarification. So, >>>>>> an item >>>>>> could have a line >>>>>> >>>>>> Tags: HK >>>>>> >>>>>> for requirements that were created by myself. The first tag could >>>>>> be the >>>>>> author, and other tags can be added later (esp something like >>>>>> "Expressivity" >>>>>> sounds like a useful tag). >>>>>> >>>>>> Holger >>>>>> >>>>>> >>>>>> >>>>>> On 12/12/2014 7:42, Peter F. Patel-Schneider wrote: >>>>>>> Done. See https://www.w3.org/2014/data-shapes/wiki/Requirements >>>>>>> >>>>>>> peter >>>>>>> >>>>>>> >>>>>>> On 12/11/2014 11:40 AM, RDF Data Shapes Working Group Issue >>>>>>> Tracker wrote: >>>>>>>> shapes-ACTION-5: New wiki page for requirements (probably only >>>>>>>> with a few >>>>>>>> to start) >>>>>>>> >>>>>>>> http://www.w3.org/2014/data-shapes/track/actions/5 >>>>>>>> >>>>>>>> Assigned to: Peter Patel-Schneider >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>> >>> > > > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Monday, 15 December 2014 16:34:25 UTC