public-dxwg-wg@w3.org from June 2018 by subject

[DCAT] - Draft agenda telecon 2018-06-07

[DCAT] group meeting 2018-06-28

[DCAT] team meeting 2018-06-28 - Agenda

[DCAT] Telecon2018.06.14 - Dataset Exchange Working Group

[DCAT] Telecon2018.06.21 - Proposed agenda

[dxwg] [conneg] IETF submission must not include query param pattern requirements

[dxwg] [profiledesc] role assumes closed world of the document

[dxwg] A profile must be packaged as a self-contained artefact

[dxwg] Add Czech translation to dcat.ttl

[dxwg] Add void:rootResource as property of dcat:Resource ?

[dxwg] Added a section to deal with quality and started some guidance for r…

[dxwg] Adding dct:accessRights to DCAT

[dxwg] Allow license property to link to other than LicenseDocument

[dxwg] Best practice for a loosely-structured catalog

[dxwg] Catalogues in which dataset is a bag of files

[dxwg] Datasets vs. Catalog relation [RDSCR]

[dxwg] DCAT - CERIF alignment (profile)

[dxwg] DCAT - DATS alignment (profile)

[dxwg] DCAT - LDP (Linked Data Platform) alignment

[dxwg] DCAT - schema.org alignment (profile)

[dxwg] dcat:accessURL - check constraints

[dxwg] dcat:downloadURL - check constraints

[dxwg] dcat:mediaType - check constraints

[dxwg] Define conneg interaction with media types that have a profile param

[dxwg] Distribution definition [RDIDF]

[dxwg] Distribution schema [RDIS]

[dxwg] Entailment of schema.org [RES]

[dxwg] Examples of quality for services

[dxwg] Extending DCAT for services

[dxwg] further PROV alignment, including for mooted WebService class

[dxwg] How to express distributions provided as compressed files

[dxwg] Incorrect type for *URL properties - should be owl:DatatypeProperty with range xsd:anyURI

[dxwg] Licenses/rights/obligations on Services

[dxwg] new commits pushed by agbeltran

[dxwg] new commits pushed by davebrowning

[dxwg] new commits pushed by dr-shorthair

[dxwg] new commits pushed by nicholascar

[dxwg] Profile Composition and Languages

[dxwg] Profile negotiation [RPFN]

[dxwg] profileDesc and the Guidance document

[dxwg] Profiles have URI identifiers that resolve to more detailed descriptions (6.1)

[dxwg] Profiles listing [RPFL]

[dxwg] Profiles must support declaration of vocabulary constraints (6.1)

[dxwg] Profiles must support discoverability via search engines (UC 5.40)

[dxwg] Profiles should provide both machine and human readable views (6.1)

[dxwg] Provenance information [RPIF]

[dxwg] Pull Request: Add description of relation to LDP and LDN

[dxwg] Pull Request: dcat:keyword - Remove sub-property axiom for consistency with document

[dxwg] Pull Request: further PROV alignment, including for mooted WebService class

[dxwg] Pull Request: Remove minor nits left behind in copy-and-paste

[dxwg] Pull Request: Replace vann:usageNote with skos:scopeNote

[dxwg] Qualified forms [RQF]

[dxwg] Quality-related information [RDQIF]

[dxwg] Related datasets [RRDS]

[dxwg] Remove one instance of "government"

[dxwg] 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.

[dxwg] Requirement: a client should be able to determine which profiles are supported by a server, and with which content types or other properties, in order to receive the one most appropriate for their use.

[dxwg] Requirement: A profile can be modular, with a given response made up of more than one module. A server can indicate that a response conforms to multiple, modular profiles

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

[dxwg] Requirement: a profile may be (partially) "implemented" by "schemas" (in OWL, SHACL, XML Schema...) that allow different levels of data validation

[dxwg] Requirement: a profile must have an identifier that can be served with a response to an API or http request. [ID2] (5.2)

[dxwg] 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.

[dxwg] Requirement: a profiles offered by a service must be discoverable through a machine-readable graph of metadata that describes what is offered and how to invoke the offered profiles. [ID5] (5.5)

[dxwg] Requirement: a vocabulary or data model can be a profile of several other vocabularies or data models at once

[dxwg] Requirement: data publishers may publish data according to different profiles, either simultaneously (in one same data "distribution") or in parallel (via content negotiation).

[dxwg] Requirement: Enable the ability to negotiate the metadata profile via http, similar to the negotiation of metadata formats today. [ID30] (5.30)

[dxwg] 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.

[dxwg] Requirement: Invocation of a profile may be by profile name, a schema choice, an encoding, and/or a language. (schema? And assume that encoding is type as in type="application/xml".) [ID5] (5.5)

[dxwg] Requirement: Metadata about server profile support can be used for discovery and mediated traversal via content negotiation. [ID5] (5.5)

[dxwg] Requirement: one can create a profile of profiles, with elements (constructs, axioms…) potentially inherited on several levels

[dxwg] Requirement: Profiles are "named collections of properties" or metadata terms (if not RDF) [ID41] (5.41)

[dxwg] Requirement: Profiles can have human-readable definitions of terms and input instructions [ID46] (5.46)

[dxwg] Requirement: Profiles can have what is needed to drive forms for data input or for user display. [ID46] (5.46)

[dxwg] Requirement: Profiles may be written in or may link to a document or schema in a validation language (ShEx, SHACL, XMLschema). [ID41] (5.41)

[dxwg] Requirement: Profiles may express dependencies between elements of the vocabulary (if A then not B, etc.) [ID41] (5.41)

[dxwg] Requirement: Profiles may provide lists of values to pick from in order to populate data elements [id46] (5.46)

[dxwg] Requirement: Profiles may provide rules governing value validity [ID41] (5.41)

[dxwg] Requirement: Profiles may provide rules on cardinality of terms (including “recommended”) [ID41] (5.41)

[dxwg] Requirement: Profiles should be able to indicate what external standards are expected to be applied/have been applied to the data provided.[ID43] (5.43)

[dxwg] Requirement: Return http link headers using the following relationship types... [ID30] (5.30)

[dxwg] Requirement: there is a need to distinguish between distributions that package the entire dataset and those that support access to specific items, queries, and packaged downloads of data. [ID51] (5.51)

[dxwg] 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)

[dxwg] Requirement: There needs to be metadata about the views provided by profiles (“named collections of properties”) that can included in a http header [ID5] (5.5)

[dxwg] 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)

[dxwg] Responses can conform to multiple, modular profiles (UC 5.3)

[dxwg] Revision to UC19

[dxwg] Usage notes [RUN]

[dxwg] Use case: web browser navigation of profile information

[dxwg] vann:usageNote used incorrectly in DCAT RDF representation

[ExternalEmail] Media Types URIs - profileneg

[ExternalEmail] Media Types URIs - profileneg - lang

ACTION-120: Add requirements to the europeana use case (Dataset Exchange Working Group)

ACTION-125: Coordinate qualified relations topics (Dataset Exchange Working Group)

ACTION-126: Prepare a proposal for issue 57 about quality information (Dataset Exchange Working Group)

ACTION-127: Re-write requirement from id46 "profiles can have rules for data value validation, including pick lists [id46] (5.46) [profile]" (Dataset Exchange Working Group)

ACTION-128: Re-write requirement: profiles should be able to indicate what external standards are expected to be applied to the data provided. [id42, id43] (5.42, 5.43) [profile] (Dataset Exchange Working Group)

Agenda for plenary June 12

Agenda June 26

Agenda Tuesday 19 June

Best practice for a loosely-structured catalog?

Closed: [dxwg] ID49 created - dataset business context / 'Project' class

Closed: [dxwg] Incorrect type for *URL properties - should be owl:DatatypeProperty with range xsd:anyURI

Closed: [dxwg] Profiles SHOULD have both both machine and human-readable views. (6.1)

Closed: [dxwg] Quality-related information [RDQIF]

Closed: [dxwg] 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)

Closed: [dxwg] vann:usageNote used incorrectly in DCAT RDF representation

Closing requirement issues on github?

Content Negotiation subgroup meetings (RE: Introduction - Rob Sanderson, J Paul Getty TrustI

DCAT sub-group meeting 2018-06-21

DCAT sub-group meeting 208-06-14

DCAT-rev as First Public Working Draft

DCMI/ASIS&T Webinar slides on profiles

dxwg-ACTION-127: Re-write requirement from id46 "profiles can have rules for data value validation, including pick lists [id46] (5.46) [profile]"

dxwg-ACTION-128: Re-write requirement: profiles should be able to indicate what external standards are expected to be applied to the data provided. [id42, id43] (5.42, 5.43) [profile]

dxwg-ACTION-129: Create new use case and requirements for more complex situation

dxwg-ACTION-130: Create github issue for id42

dxwg-ACTION-131: Report back this expectation to plenary (accepting in the plenary meeting will generate action to generation pr against ucr)

dxwg-ACTION-132: Report back this expectation to plenary (accepting in the plenary meeting will generate action to generation pr against ucr)

dxwg-ACTION-133: Report back progress to plenary.

dxwg-ACTION-134: Draft some text about the drivers for DCAT

dxwg-ACTION-135: Acknowledge comment

dxwg-ACTION-136: Create issue from mailing list comment

dxwg-ACTION-137: Add some notes into https://??github.com/??w3c/??dxwg/??issues/??259 about our discussion

dxwg-ACTION-138: Trigger feedback from ANDS

F2F4 registration fee rates

Fwd: Publication moratoria for second half of 2018

Fwd: TPAC 2018 registration now open

In DCAT, Is is possible to specify an void:rootResource in DCAT?

Initial notes on profileDesc

Introduction - Rob Sanderson, J Paul Getty Trust

List of proposed new use cases

Media Types URIs

Meeting details for the CNEG subgroup meeting on Wednesday, June 20

Minutes from the CNEG meeting 2018-06-20

New requirements on github?

New use-case - Catalogues in which dataset is a bag of files

ODRL community group - and profiles

Plenary agenda June 5

Plenary agenda June 5 / Partial list of requirements for approval / Informative supplement

Poll for new time for the CNEG meeting

Regrets for the next two plenary meetings and the next CNEG meeting

TPAC 2018 registration now open

Updates to G-Doc

Use case/requirement ID40

Was this Use Case ever accepted?

Last message date: Saturday, 30 June 2018 16:40:47 UTC