Report back from F2F3


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:
Day 2:

* 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
* 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

Resolved (Day2):

Explore placing ProfileDesc as basis for Guidance deliverable

Requirements (Day 1):


* Clarify any relationship between
profiles and validation languages (6.1) #204
* Profiles have URI identifiers
that resolve to more detailed descriptions (6.1) #205
* Profiles should provide both
machine and human readable views (6.1)
* 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
* 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
* Profiles extend or refine (UC
5.37) #216
* Profiles should reuse vocabulary
terms defined elsewhere
* Profiles support data creation
functions (UC 5.46)

Merged into one: Application profiles need a rich
expression for the validation of metadata (6.1) Profiles must support declaration
of vocabulary constraints (6.1) Profiles describe conformance to
metadata standards (6.1)

Closed: Profile representation [RPFRP]
(redundant) 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: 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: Profiles must support
discoverability via search engines (UC 5.40) Each application profile needs to
be documented, preferably by showing/reusing what is common across
profiles (6.1) #207 Responses can conform to
multiple, modular profiles (UC 5.3) Profiles list valid vocabulary
terms for a metadata usage environment (UC 5.37) Profile vocabulary lists may be
defined as closed (no other terms are allowed) or open (other terms are
allowed) (UC 5.37) Profiles must have properties for
at least two levels of documentation: 1) short definition 2) input and
editing guidance (6.1) use standard for profile
identification Entailment of [RES] ID37 Europeana profile ecosystem:
representing, publishing and consuming application profiles of the
Europeana Data Model (EDM)
Karen Coyle
m: 1-510-435-8234 (Signal)
skype: kcoylenet/+1-510-984-3600

Received on Thursday, 10 May 2018 09:10:29 UTC