From Dataset Exchange Working Group

Thursday, November 9

Time Group Requirement Scribe
8:30-9:00 Gather Coffee on your own
  • 6.21 Provide a way to specify access restrictions for both a dataset and a distribution. Provide a way to define the meaning of the access restrictions for a dataset or distribution and to specify what is required to access a dataset and distribution. (Are these two separate requirements?) RID19
  • 6.22 Ability to represent the different relationships between datasets, including: versions of a dataset, collections of datasets, to describe their inclusion criteria and to define the 'hasPart'/'partOf' relationship, derivation, e.g. processed data that is derived from raw data RID20
  • 6.38 Clarify the relationships between Datasets and zero, one or multiple Catalogs, e.g. in scenarios of copying, harvesting and aggregation of Dataset descriptions among Catalogs. RID35.1
Data info
  • 6.20 Identify common modeling patterns for different aspects of data quality based on frequently referenced data quality attributes found in existing standards and practices. RID18
  • 6.36 Express summary statistics and descriptive metrics to characterize a Dataset. RID33.1
  • 6.44 Define a means to advertise any quality-related information; this might be text-based or more machine-processable. RID45.1
  • 6.16 Provide a recommended way to attach usage notes to data descriptions. RID14
  • 6.17 Provide a way to link publications about a dataset to the dataset. RID15
  • 6.18 Provide a way to link to structured information about the provenance of a dataset RID16
10:30-11:00 Break
11-12:30 Versioning General versioning considerations Alejandra's spreadsheet DaveB
  • 6.5.1 Identify DCAT resources that are subject to versioning, i.e. Catalog, Dataset, Distribution. RVer1
  • 6.6.1 Provide a conceptual definition of what is considered a version with regard to modifications of the respective subject. The definition should provide a clear guidance on conditions, type and severity of a resource's update that motivate the creation of a new version in scenarios like dataset evolution, conversion, translations etc. RVer2
  • 6.7.1 Provide a means to identify a version (URI-segment, property etc.). Clarify relationship to identifier of the subject resource. (ACCEPTED)
  • 6.8.1 Indicate the status of a version in terms stability, fidelity etc. (e.g. major, minor, stable). The version identifier might refer to the version status (semantic version). RVer4
  • 6.9.1 Indicate the date when specific version was created (released). The version identifier might refer to the release date. (ACCEPTED)
  • 6.10.1 Indicate the change delta from one version to the next. RVer6
  • 6.11.1 Provide a means to search and discover existing versions of a DCAT resource. This should include both metadata elements referencing previous and next versions, lists of versions, and by implication the ability to search catalogs for related versions. RVer7
  • 6.45.1 Indicate the update method of a Dataset description, e.g. whether each new dataset entirely supercedes previous ones (is stand-alone), or whether there is a base dataset with files that effect updates to that base. RID47.1
12:30-13:30 Lunch
13:30-15:30 Versioning continued dsr
15:30-16:00 Break
Project Info
  • 6.35 Provide means to describe the funding (amount and source) of a Dataset (or entire Catalog). RID31.1
  • 6.46 Provide a means (e.g. a class) to define a "project" as a research, funding or work organization context of a Dataset. RID49.1
  • 6.47 Provide a means (e.g. a property) to indicate the relation of Datasets to a project. RID49.1
  • 6.39 Analyse and compare similar concepts defined by vocabularies related to DCAT (e.g. VOID, Data Cube dataset). RID36.1
  • 6.40 Define guidelines how to create a DCAT description of a VOID or Data Cube dataset RID36.2
  • 6.41 Define equivalents for DCAT properties to support entailment of compliant profiles of DCAT records. RID40.1
Qualified forms
  • 6.27 Define qualified forms to specify additional attributes of appropriate binary relations (e.g. temporal context). RID19.1
  • 6.28 Specify mapping of qualified to non-qualified forms (lowering mapping). The reverse requires information (qualification) that might not be present/evident. RID19.2

Friday, November 10

Time Group Requirement Scribe
8:30-9:00 Gather Bring your own coffee
  • 6.29 Define means to explicitly control the re-publication of Dataset and Catalog descriptions among data portals (policies). Obligations might apply e.g. to disclose the original source or keep the copies synchronized. RID25.1
  • 6.30 Define a reference to the original release of a re-published DCAT resource in a way indexable by search engines and processable by web clients. RID25.2
  • 6.45.1 Indicate the update method of a Dataset description, e.g. whether each new dataset entirely supersedes previous ones (is stand-alone), or whether there is a base dataset with files that effect updates to that base. RID47.1
  • 6.48 Metadata 'distribution' elements need a content model (see white paper referenced above) associated with links to communicate the protocol expected and the interchange formats (information model and encoding/serialization) available via the link. Content negotiation does not solve the problem very well because it requires the client to play a guessing game; it's better to explicitly identify the 'profile' for a link's behavior in the metadata so the client can pick the 'affordance' it needs. RID21.1
  • 6.14 Define a way to attach finer grained metadata for dcat:Distribution instances associated to a dcat:Dataset RID12
  • 6.15 Define a way to categorise web services descriptions in dcat:Distribution instances associated to a dcat:Dataset RID13
  • 6.23 Define way to specify content of packaged files in a Distribution. For example, a set of files may be organised in an archive format and then compressed, but dct:hasFormat property only indicates the encoding type of the outer layer of packaging. RID1.1
  • 6.37 Revise definition of Distribution. Make clearer what a Distribution is and what it is not. Provide better guidance for data publishers. RID34.1
10:30-11:00 Break
11:00-12:30 Profiles
  • 6.1.1 Create a sufficiently wide definition of an application profile to address declaration of interoperability profiles data may conform to, and through this mechanism provide the means for DCAT instances and collections to also declare the profiles of DCAT they conform to. RID1
  • 6.1.2 Clarify any relationship between profiles and validation languages RID1
  • 6.1.3 Profiles have URI identifiers that resolve to more detailed descriptions RID1
  • 6.1.4 Machine-readable specifications of application profiles need to be easily publishable, and optimize re-use of existing specifications RID1
  • 6.1.5 Each application profile needs to be documented, preferably by showing/reusing what is common across profiles RID1
  • 6.1.6 Application profiles need a rich expression for the validation of metadata RID1
  • 6.1.7 Profiles must have properties for at least two levels of documentation: 1) short definition 2) input and editing guidance RID1
  • 6.1.8 Profiles must support declaration of vocabulary constraints RID1
  • 6.1.9 Profiles should provide both machine and human readable views RID1
12:30-13:30 Lunch
13:30-15:00 Profiles
  • 6.1.10 Profiles may inherit clauses from one or more parent profiles RID1
  • 6.1.11 Profiles must support a view that includes all inherited constraints clearly identifying the parent profile the constraint is defined in RID1
  • 6.1.12 A mechanism must be available to identify conformance to each inherited profile given conformance to a profile that specialises it RID1
  • 6.1.13 Profiles may be used to describe the metadata standard a description conforms to, the standards to which the resource described (e.g. dataset) and the standards each distribution conforms to RID1
  • 6.2.1 Create a way to negotiate choice of information profile between clients and servers RID2
  • 6.3.1 Create a way to list the profiles implemented by a dataset or a specific distribution RID3
  • 6.4.1 Create a way to retrieve more information about a profile. This must be flexible enough to support human and machine readable resources, such as input and editing guidance, validation resources, usage notes etc. RID4
  • 6.42.1 Indicate in profiled vocabulary set of guidance rules applied. RID4
15:30-16:00 Break
  • 6.24 Encode identifiers as dereferenceable HTTP URIs RID11.1
  • 6.25 Indicate type of identifier (e.g. prism:doi, bibo:doi, ISBN etc.). RID11.2
  • 6.26 Provide means to distinguish the primary and alternative (legacy) identifiers. RID11.3
  • 6.43.1 Define a means to identify a serialized DCAT Data(sub)set (i.e. a particular Distribution of a Dataset or its subset). RID44.1
  • 6.19 Provide a way to specify information required for data citation (e.g., dataset authors, title, publication year, publisher, persistent identifier) RID17
Add'l details
  • 6.32 Allow for specification of the start and/or end date of temporal coverage. RID27.1
  • 6.34 Provide means to specify spatial coverage with geometries. RID29.1
  • 6.33 Provide means to specify the reference system(s) used in a dataset. RID28.1
  • 6.31 Define extension points (e.g. properties) for integration of external, specialized vocabularies. RID26.2