– DRAFT –
Dataset Exchange Working Group Teleconference

<kcoyle> https://‌www.w3.org/‌2018/‌06/‌12-dxwg-minutes

Minutes of previous meeting

Resolved: accept minutes of 06/12

UCR

<kcoyle> https://‌docs.google.com/‌document/‌d/‌13hV2tJ6Kg2Hfe7e1BowY5QfCIweH9GxSCFQV1aWtOPg/‌edit#heading=h.m03bsvydfkcm

Profiles may be written in or may link to a validation language (ShEx, SHACL, XMLschema). ID41 (5.41)

<kcoyle> https://‌docs.google.com/‌document/‌d/‌13hV2tJ6Kg2Hfe7e1BowY5QfCIweH9GxSCFQV1aWtOPg/‌edit#heading=h.gx1l7t7tl8iq

Profiles may be coordinated with validation schemas. ID48 (5.48)

<ncar> An obvious pair of in scope I think

<roba> +1 in scope - what does coordinated mean?

<roba> reference?

alejandra: what does related to/ ? mean

<roba> include?

<alejandra> +1 to changing the wording

<alejandra> associated?

kcoyle: may point to a validation schema -- could use a different form of words. Associated, etc

alejandra: I can't see the difference between the two.

kcoyle: there may be a link, but it might be server information (eg with conneg)

annette_g: giving a human readable description might be put here - not necessarily machine-redable

<alejandra> ok, the mention of validation language vs validation schema is implying two different associations

Jaroslav_Pullmann: what are we going to express with linking schema to profiles - a hint on where to find a schema, or an idea of which schema the instance has been validated with?

<annette_g> I think whatever gets validated should be machine-readable.

kcoyle: none of the use cases say that the instance should be valid

Jaroslav_Pullmann: the resource might link the the validation source to state formally what validated

kcoyle: I am nervous of people declaring that their instances are valid.

<ncar> me!

ncar: can I suggest that we vote on these separately

<kcoyle> PROPOSED: accept Profiles may be written in or may link to a validation language (ShEx, SHACL, XMLschema). ID41 as in scope

<ncar> 1+

<roba> +1

<annette_g> +1

<ncar> +1

+1

<SimonCox> +1

<DaveBrowning> +1

<LarsG> +1

alejandra: the first discusses validation language, so we need to adjust the wording

<alejandra> +1 with rewording, clarifying that it points to a document written in a validation language

Resolved: accept Profiles may be written in or may link to a document or schema in a validation language (ShEx, SHACL, XMLschema). ID41

<Jaroslav_Pullmann> +1

<annette_g> +1

<roba> -1 on basis of redundancy

<kcoyle> PROPOSED: accept as in scope Requirement: Profiles may be coordinated with/associated with validation schemas that would validate the instance data.

<ncar> -1

<roba> now i mean -1 on basis of redundancy

<alejandra> -1 as it is redundant and equivalent to the previous one

<DaveBrowning> -1 - redundant

<roba> the second...

annette_g: are people giving -1 to the first, or to the second proposal

kcoyle: to the second

<Zakim> LarsG, you wanted to ask about policy of duplicates

LarsG: do we have a policy about duplicate requirements, or are we normalising?

kcoyle: we can have duplicate or overlapping requirement - we can remove or blend during the UCR process

<LarsG> in that case +1

kcoyle: we haven't resolved this - do we think additional discussion will resolve? if not then we should drop

roba: I've been through the UCR and people can't trace back. I think we should avoid the UCR and just drop but make sure that the UCR traceability is clear

kcoyle: we need 1:1 or 1:n links. Can you link a single requirement to the use case?
… let's resolve in the following sense...

Resolved: Requirement: Profiles may be coordinated with validation schemas. is redundant; ID 48 will be linked to the same requirement

<annette_g> +1

+1

<roba> +1

<Jaroslav_Pullmann> +1

<alejandra> +1

<DaveBrowning> +1

<LarsG> +1

<ncar> +1

<kcoyle> ID2 https://‌docs.google.com/‌document/‌d/‌13hV2tJ6Kg2Hfe7e1BowY5QfCIweH9GxSCFQV1aWtOPg/‌edit#heading=h.bdr07yfzu6h

profiles must have identifiers that can be served with a response to an API or http request. ID2 (5.2)

<kcoyle> Requirement: profiles must have identifiers that can be served with a response to an API or http request. ID2

<ncar> +1

<annette_g> +10

+1

<alejandra> +1

<Jaroslav_Pullmann> +1

<roba> +1

<AndreaPerego> +1

<DaveBrowning> +1

Resolved: in scope: Requirement: profiles must have identifiers that can be served with a response to an API or http request. ID2

<LarsG> +1

<SimonCox> +1

<Jaroslav_Pullmann> ... but why mentioning concrete protocol/interface?

Jaroslav_Pullmann: does it mean profiles are resolved by URLs?

kcoyle: looking at the use case, it is specific to conneg

Jaroslav_Pullmann: the resolution isn't mentioned in the use case. are these concrete terms (API, HTTP request, etc) clearly in the use cases?

kcoyle: why don't we just say that profiles will have identifiers?
… but if you still have issues with the use case then put the discussion on github

kcoyle: the next is from that same use case (ID2)

<kcoyle> PROPOSED: accept as in scope Requirement: Clients should be able to determine which profiles are supported by a server, and with which content types. ID2

annette_g: here's where we start getting into conneg where the use cases seems to describe how conneg should work - it is getting circular. I would like a motivating use case. there have been some in the mailing list discussion

kcoyle: are you wanting the use case revised ?

annette_g: yes

Jaroslav_Pullmann: it goes into detail, but I understood the underlying motivation. we could make it more generally

<ncar> I volunteer

kcoyle: can someone take this offline and rewrite?

kcoyle: the use case must provide some sense of intent

<roba> the main thing UC should really do is specify pre and post-conditions..

kcoyle: you need to present the problem, not the solution

annette_g: it is a matter of finding the underlying problem

Action: ncar to re-create ID 2

<trackbot> Error finding 'ncar'. You can review and register nicknames at <https://‌www.w3.org/‌2017/‌dxwg/‌track/‌users>.

<ncar> ok, I accept!

LarsG: the point is the client needs to know if it can process the data, or not

<Zakim> LarsG, you wanted to give a reason

<annette_g> problem, with context

Jaroslav_Pullmann: is this a general motivation for profiles?
… to assure they are served in a way the client can use them
… do we have a statement of why profiles matter?

roba: profiles are a statement of interoperability

kcoyle: if you can't find that in any use cases, then you need to add one expressing this

<kcoyle> Requirement: There should be a way for a client to look up additional information about a profile.

kcoyle: ncar can you look at what Antoine did with the Europeana use case - rewrite and then re-extract the requirements

<annette_g> What I'm seeing a requirement for is a standardized way to indicate the

<annette_g> availability of alternative forms of a dataset with different profiles

<annette_g> and to enable the end user (human or script) to receive the most

<annette_g> appropriate one for their use.

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

roba: this is just addressing the previous point about need for profiles, the difference being that it is a statement about macine readability

kcoyle: does the use of 'graph' limit it to RDF?

roba: it just refers to objects and associations
… there are databases without graph models, but they can be expressed in graph terms

<Jaroslav_Pullmann> .. +1 for dropping graph, and what about turning service to web resource: Profiles offered by a web reesource must be discoverable ..

kcoyle: we are getting to the point where this should be made less specific as it refers to solution space

Jaroslav_Pullmann: what about service, because conneg is related to web resources

roba: I think that resources may or may not be backed by a service -I'm happy as it reflects the use case

<roba> I'm agnostic - all resources are backed by a service.. so its kind of redundant and can be removed

<kcoyle> PROPOSED: accept as in scope PROPOSED: Profiles must be discoverable through a machine-readable metadata that describes what is offered and how to invoke the offered profiles. ID5

+1

<SimonCox> +1

<alejandra> +1

<roba> +1

<DaveBrowning> +1

<annette_g> +1

<Jaroslav_Pullmann> +1

<AndreaPerego> +1 - but I'm unsure about the MUST

<LarsG> +1

<AndreaPerego> Agreed. Thanks, kcoyle.

Resolved: accept as in scope Profiles must be discoverable through a machine-readable metadata that describes what is offered and how to invoke the offered profiles. ID5

<annette_g> It must be possible for profiles to be made discoverable through machine-readble metadata that describes what is offered and how to invoke the offered profiles.

<annette_g> yes

<annette_g> np

<kcoyle> Requirement: Profiles must support discoverability via search engines (UC 5.40) #222 (Github discussion) ID40

<SimonCox> must? or should?

<kcoyle> https://‌github.com/‌w3c/‌dxwg/‌issues/‌222

kcoyle: yes, it probably is a 'should'

<roba> shuld

<SimonCox> 'support discoverability' or 'be discoverable'

<ncar> +1 if should - we *should* aim for this

<alejandra> +1 if changed to should

<annette_g> +1

+1

<kcoyle> PROPOSED: in scope Requirement: Profiles should support discoverability via search engines (UC 5.40) #222 (Github discussion) ID40

AndreaPerego: still unsure about what this requirement is about

<alejandra> https://‌w3c.github.io/‌dxwg/‌ucr/#ID40

roba: it was about exposing DCAT content . the requirement was originally related to schema.org equivalents

<Jaroslav_Pullmann> would we like to distinguish both cases - profiles should be modeled in a way supporting their discoverability by search engines <-> search engines may use profile links to support the discoverability of compliant data instances

AndreaPerego: it still isn't clear to me - there can be alignment between dcat and schema.org, but we are dependent on how search engines work
… this is about best practices in the publication of metadata, and is related to the DCAT/Schema.org alignment
… we are unable to control how search engines index profiles

alejandra: I agree with AndreaPerego - it isn't a good idea to be specific abotu things that we cannot control, such as how search engines work.

<roba> this isnt about profiles, other than delivering schema.org instead of DCAT may be done by profile negotiation.

alejandra: there may already be a requirement for the same metadata expressed in different vocabularies

kcoyle: let's try to resolve this in the github discussion. when we return we might have a rewording (put that in the github discussion)

<alejandra> +1 to roba, the requirement should be about having profiles referring different vocabularies (different context files for the same data)

<SimonCox> RRSAgent: draft minutes v2

<annette_g> bye all!

<AndreaPerego> Thanks, and bye!

<Jaroslav_Pullmann> bye!

<alejandra> thanks! bye all

<LarsG> bye all