W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > September 2017

Re: Organizing/prioritizing requirements ... via a tag filter

From: Rob Atkinson <rob@metalinkage.com.au>
Date: Tue, 05 Sep 2017 22:48:52 +0000
Message-ID: <CACfF9Lw9U79_VVF2cvCfnbXwRMcXa7vivbXTkFyaj1zF-qUvXg@mail.gmail.com>
To: kcoyle@kcoyle.net, public-dxwg-wg@w3.org
Having been through all the use cases and requirements and looking for
commonality, i would suggest that profiles and DCAT are not orthogonal
concerns.

Given the nature of profiles, and particularly the nature of negotiation by
profile and the impossibility of capturing all fine-grained semantics
inside DCAT vocabulary itself, perhaps the single most important functional
improvement for DCAT is the specification of profiles within DCAT. This
means (i expect) canonical ObjectProperties to specify the profile of DCAT
being used in the description, the interoperability profiles supported by
the dataset and the specific profiles supported by each distribution for
both access method and response.

IMHO Any large information infrastructure that supports heterogeneous data
is broken without the ability to declare and then link to descriptions of
data characteristics in this convenient manner.

Rob

On Wed, 6 Sep 2017 at 01:37 Karen Coyle <kcoyle@kcoyle.net> wrote:

> Jaro -
>
> The filtering works on the html version[1] for me. I selected the
> "profile" option and have MANY comments to make on the requirements, but
> I wonder if we all shouldn't look first at DCAT, as that is a priority.
>
> kc
> [1] https://w3c.github.io/dxwg/ucr/
>
> On 9/4/17 12:37 AM, Jaroslav Pullmann wrote:
> >
> >   Hello Karen,
> >
> >    Rob has merged in the code, you might now experiment with the
> prototype.
> >   I'd suggest to download/clone the UCR page and open in a browser
> locally.
> >   It uses the tags attached to use cases and resolves their related
> requirements.
> >
> >    Talk to you later, best regards
> >   Jaro
> >
> >
> >
> > On Saturday, September 2, 2017 19:18 CEST, Karen Coyle <
> kcoyle@kcoyle.net> wrote:
> >
> >> Jaro - yes, that sounds useful, if it can be done. We had noted that the
> >> requirements themselves were not tagged so we did not have an easy way
> >> to gather them by deliverable. Could you demonstrate what you describe
> >> below for the group?
> >>
> >> Thanks,
> >> kc
> >>
> >> On 9/1/17 2:49 AM, Jaroslav Pullmann wrote:
> >>>
> >>>  Dear Karen, dear all,
> >>>
> >>>> determine the requirements for the three deliverables
> >>>
> >>>  couldn't we use the tags to filter accordingly?
> >>>
> >>>  There are 3 deliverable tags (content_negotiation, dcat, profile)
> >>>  with every use case tagged with at least one of them.
> >>>
> >>>  The spec reader might create a view filtered by deliverable and
> further
> >>> tags.
> >>>  Only matching use cases and their related requirements were visible:
> >>> Tag > UC > Req.
> >>>
> >>>  Does this simple approach fit the task or are there exceptions, where
> e.g.
> >>>  requirements are relevant for a deliverable while none of the related
> >>> UCs does?
> >>>
> >>>   Best regards
> >>>  Jaroslav
> >>>
> >>>
> >>>> Some possible organizing principles are:
> >>>>
> >>>> - which requirements are for which deliverables? (Yes, some
> requirements
> >>>> may be valid for more than one deliverable.)
> >>>> - what are the logical categories that requirements fall into within
> >>>> each deliverable?
> >>>> - what is the priority for each requirement? (e.g. absolutely
> required;
> >>>> required if possible; nice to have but not required)
> >>>>
> >>>> Following are some examples from previous working groups that the team
> >>>> is aware of. If you know of others please reply with them.
> >>>>
> >>>> - https://www.w3.org/TR/dwbp/#challenges (DWBP challenges)
> >>>> - https://www.w3.org/TR/dwbp/#requirements (DWBP requirements)
> >>>> - https://www.w3.org/TR/shacl-ucr/#requirements (SHACL requirements)
> >>>>
> >>>> Please give some time to this and share an ideas with the group.
> >>>>
> >>>> kc for the team
> >>>>
> >>>
> >>
> >> --
> >> Karen Coyle
> >> kcoyle@kcoyle.net http://kcoyle.net
> >> m: 1-510-435-8234 (Signal)
> >> skype: kcoylenet/+1-510-984-3600 <+1%20510-984-3600>
> >>
> >
> >
> >
> >
>
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> m: 1-510-435-8234 (Signal)
> skype: kcoylenet/+1-510-984-3600 <+1%20510-984-3600>
>
>
Received on Tuesday, 5 September 2017 22:49:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 October 2019 00:15:38 UTC