From Dataset Exchange Working Group
Jump to: navigation, search

Agenda Tuesday 26 June 2018 20:00 UTC (in your time zone)


Chair: Peter Winstanley

Regrets: DaveBrowning , SimonCox, Alejandra, Ixchel

Reminding attendees to put Present+ <nickname>

I. Appoint Scribe

II. Approve June 19 meeting minutes

III. Check who is on IRC and WebEx

Checking Open Action items

Timing of next drafts

Upcoming deadlines: July 4, July 25

Note publishing moratorium around TPAC (Begins Oct 17)

Do we have estimates on our next publications?!


  • Subgroup report
    • Responses to FPWD?

Profile Guidance group

  • subgroup report

Profile Negotiation

  • subgroup report


Requirements must be approved for Conneg and Profiles

From last week:

  • Requirement: There needs to be a property in the profile where the rules for the descriptive content can be provided. This would apply to the entire profile. [ID42] (5.42) (github)

For Approval (Profiles):

Querying and discovery

  • Requirement: Clients should be able to determine which profiles are supported by a server, and with which content types. ID2 (5.2) [conneg]
  • Requirement: There should be a way for a client to look up additional information about a profile. (What kinds of information? Can we clarify this?) ID2 (5.2) [conneg]

Proposed rewording:

"There should be a way to look up additional information about a profile - this may be machine readable for run-time mediation or used to develop or configure a client".

Proposed by CNEG: remove as redundant

  • Requirement: Profiles must support discoverability via search engines (UC 5.40) #222 (Github discussion) ID40 (5.40) [profile]

Reuse, composition, and compatibility

  • Requirement: Profiles can be modular, with a given response made up of more than one module. Servers can indicate that a response conforms to multiple, modular profiles. ID3 (5.3) [conneg] [profile]

Inheritance, conflict resolution and evaluation

  • Requirement: "Profiles may add to or specialise clauses from one or more base specifications. Such profiles inherit all the constraints from base specifications.” ID37 [ID39] #238

Europeana Use Case: Requirements for Profiles

See: ID37. Use case is greatly edited, new requirements replace requirement 12.:

  • 12.1 Requirement: a vocabulary or data model can be a profile of several other vocabularies or data models at once
  • 12. 2 Requirement [derived from the previous one: it's rather trivial, but one never knows…]: profiles may or may not be "exclusive" of other profiles, i.e. some profiles may forbid the use of their elements in combination of other profiles, while others (in a typical open-world fashion) will allow such combined use.
  • 12.3 Requirement: one can create a profile of profiles, with elements (constructs, axioms…) potentially inherited on several levels.
  • 12.4 Requirement: from the perspective of management of profiles, and guidance to users and data experts, ecosystems of profiles should be properly described (e.g. in profile catalogues/repositories), especially documenting the relationships between profiles and what they are based on, and between profiles that are based on other profiles.
  • 12.5 Requirement: a profile should have human-readable documentation that expresses for humans the main components of a profile, which can also be available as machine-readable resources (ontology or schema files, SHACL files, etc). This includes listing of elements in the profile, instructions and recommendations on how to use them, constraints that determine what data is valid according to the profile, etc. [From the documents accessible from references in this use case, it should be possible to infer more specific requirements in terms of profile documentation, but I lack time. It could be captured by other cases. It should maybe be addressed at a later stage of DXWG work.]
  • 12.6 Requirement: a profile may be (partially) "implemented" by "schemas" (in OWL, SHACL, XML Schema...) that allow different levels of data validation.
  • 12.7 Requirement: data publishers may publish data according to different profiles, either simultaneously (in one same data "distribution") or in parallel (via content negotiation).
  • ["Virtual" requirement: from the EDM profile(s) it should be possible to infer specific requirements in terms of data validation: this is probably out of scope of DXWG now, but we've done it for the DCMI WG that Karen and I co-chaired. It should also be possible to derive requirement in terms of description of profiles vs their implementations/schemas and how all this should be served. Now I see that there are some requirements like "Profiles are "named collections of properties" or metadata terms (if not RDF)", "Profiles may provide rules on cardinality of terms (including “recommended”)", "Profiles may provide rules governing value validity" "Profiles may express dependencies between elements of the vocabulary (if A then not B, etc.)" that go in this direction already. But I lack time and am hoping this will be captured by other cases, or will be addressed at a later stage of DXWG work]

Note: Conneg group should review conneg requirements; see if profileDesc functionality and conneg are adequately covered

In the queue

Proposed new use cases

Still needed?

Joining instructions: (official participants and invited guests only)

WebEx Details

For text discussions, minutes, joining the speaker queue, actions & issues IRC channel: #dxwg on IRC on port 6667

Please be sure to join both IRC and WebEx and use the same nick in both (or it gets very confusing)

When you join the IRC channel, please immediately type 'present+ {yourname}' (this adds your name to the participants list in the minutes)


Minutes +
Scribekcoyle +
SubjectProfiles Requirements +
TypeTelecon +
"Date" is a type and predefined property provided by Semantic MediaWiki to represent date values.
June 26, 2018 +