W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > May 2018

Report back from F2F3

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Thu, 10 May 2018 11:09:47 +0200
To: "public-dxwg-wg@w3.org" <public-dxwg-wg@w3.org>
Message-ID: <0d59b833-34a2-f721-bb69-8cd4cf3f7d40@kcoyle.net>
All,

We had a very productive meeting. This email points you to the minutes,
and enumerates resolutions and actions. There were some significant
decisions about direction that require us to modify our requirements for
the Guidance document, namely that we have agreed to anchor the guidance
document around the profileDesc work, although we have not determined
exactly how to do this. We created an outline for the guidance document
(which I need to clean up and will post as a Google doc soon). We
discussed the possibility of making the guidance document a Note rather
than a Recommendation for various good reasons, but need to better
understand the overall W3C implications. We also need to convene a group
of editors for the Guidance document and begin the work on that.

I'm sure that I have not captured everything here. I recommend continued
use of github issues where appropriate, and have a sense that we have
some work to do in the next weeks that will give us a better scope for
the Guidance deliverable.

Day 1: https://www.w3.org/2018/05/08-dxwg-minutes
Day 2: https://www.w3.org/2018/05/09-dxwg-minutes

Actions:
* Antoine to replace 'content negotiation' by 'profile negotiation'
where appropriate
* kcoyle find better wording for 216 especially "extend"
* kcoyle to find a new wording for
https://‌github.com/‌w3c/‌dxwg/‌issues/‌209
* Jaroslav_Pullmann to work with kcoyle on profile UCs and Requirements
* kcoyle to send actions and resolutions to mailing list [DONE!]
* danbri to write his blog post about use of JSON context for vocabulary
switching

Resolved (Day2):

Explore placing ProfileDesc as basis for Guidance deliverable

Requirements (Day 1):

Accepted:

*https://github.com/w3c/dxwg/issues/204 Clarify any relationship between
profiles and validation languages (6.1) #204
*https://github.com/w3c/dxwg/issues/205 Profiles have URI identifiers
that resolve to more detailed descriptions (6.1) #205
*https://github.com/w3c/dxwg/issues/211 Profiles should provide both
machine and human readable views (6.1)
*https://github.com/w3c/dxwg/issues/212 Profiles may inherit clauses
from one or more parent profiles (6.1)
	Wording changed to: Profiles may inherit clauses (modules, if designed
for this type of reuse) from one or more parent profiles to optimize
re-use of existing specifications
*https://github.com/w3c/dxwg/issues/214 A mechanism must be available to
identify conformance to each inherited profile given conformance to a
profile that specialises it (6.1)
	Reworded as: If conformance to a profile is claimed, then it should be
possible to confirm conformance to each parent profile
*https://github.com/w3c/dxwg/issues/216 Profiles extend or refine (UC
5.37) #216
*https://github.com/w3c/dxwg/issues/220 Profiles should reuse vocabulary
terms defined elsewhere
*https://github.com/w3c/dxwg/issues/221 Profiles support data creation
functions (UC 5.46)

Merged into one:

https://github.com/w3c/dxwg/issues/208 Application profiles need a rich
expression for the validation of metadata (6.1)
https://github.com/w3c/dxwg/issues/210 Profiles must support declaration
of vocabulary constraints (6.1)
https://github.com/w3c/dxwg/issues/215 Profiles describe conformance to
metadata standards (6.1)

Closed:

https://github.com/w3c/dxwg/issues/75 Profile representation [RPFRP]
(redundant)
https://github.com/w3c/dxwg/issues/206 Machine-readable specifications
of application profiles need to be easily publishable, and optimize
re-use of existing specifications (6.1) (after moving wording after
"and" to issue 212)

Out of scope:

https://github.com/w3c/dxwg/issues/213 Profiles must support a view that
includes all inherited constraints clearly identifying the parent
profile the constraint is defined in (6.1)

Not addressed or not finalized:

https://github.com/w3c/dxwg/issues/222 Profiles must support
discoverability via search engines (UC 5.40)
https://github.com/w3c/dxwg/issues/207 Each application profile needs to
be documented, preferably by showing/reusing what is common across
profiles (6.1) #207
https://github.com/w3c/dxwg/issues/217 Responses can conform to
multiple, modular profiles (UC 5.3)
https://github.com/w3c/dxwg/issues/218 Profiles list valid vocabulary
terms for a metadata usage environment (UC 5.37)
https://github.com/w3c/dxwg/issues/219 Profile vocabulary lists may be
defined as closed (no other terms are allowed) or open (other terms are
allowed) (UC 5.37)
https://github.com/w3c/dxwg/issues/209 Profiles must have properties for
at least two levels of documentation: 1) short definition 2) input and
editing guidance (6.1)
https://github.com/w3c/dxwg/issues/45 use standard for profile
identification
https://github.com/w3c/dxwg/issues/65 Entailment of schema.org [RES]
https://github.com/w3c/dxwg/issues/8 ID37 Europeana profile ecosystem:
representing, publishing and consuming application profiles of the
Europeana Data Model (EDM)
-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234 (Signal)
skype: kcoylenet/+1-510-984-3600
Received on Thursday, 10 May 2018 09:10:29 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 April 2019 13:44:59 UTC