– DRAFT –
DXWG DCAT subgroup teleconference 28 November 2018 21:00 UTC
28 November 2018
<alejandra> https://www.w3.org/2017/dxwg/wiki/Meetings:DCAT-Telecon2018.11.28
<alejandra> https://www.w3.org/2018/11/21-dxwgdcat-minutes
0 (not there)
<riccardoAlbertoni> +1
<Makx> 0 not there
proposed: resolve minutes of 21 Nov 2018
<DaveBrowning> +1
<SimonCox> +1
<alejandra> I was present even if I am not listed at the top
<alejandra> +1
Resolved: resolve minutes of 21 Nov 2018
<alejandra> https://www.w3.org/2017/dxwg/track/actions/open
riccardoAlbertoni:
alejandra: we have replied to everyone but we need to follow up
SimonCox: I would like to draft something more cogent for Clemens, but would like to get team approval before I reply
alejandra: draft for next week and share in a google doc. we can discuss next week
SimonCox: In
SimonCox: I'm just wanting to ensure there is no confusion
Action: SimonCox to create googledoc for draft reply to Clemens
<trackbot> Sorry, but no Tracker is associated with this channel.
alejandra: we can have the same approach for the reply to Luca Trani
alejandra: qualified attribution has a PR that needs to be handled
<alejandra> https://github.com/w3c/dxwg/wiki/DCAT-Identifiers
alejandra: we have 3 issues related to identifiers and whatever we consiser should cover all 3
… the proposal from riccardoAlbertoni is in the link just posted
… the idea is to use dct:identifier for the primary and use adms for the others
<riccardoAlbertoni> https://github.com/w3c/dxwg/wiki/DCAT-Identifiers
riccardoAlbertoni: the link to the wiki page is posted
… the 3 issues are interlinked. they should solve the issue we have
… I tried to organise a proposal - see the wiki page
dct for the primary; adms for the second; use HTTP URIs because they are actionable
riccardoAlbertoni: dct for the primary; adms for the second; use HTTP URIs because they are actionable
… in the section on identifier types there is no HTTP URI, so we need one
… we decided to stick with adms and using the schema:agency when the agency has no URI
alejandra: one comment; even though the examples are good, we need a solution that addresses identifiers for any other entity - catalogues; people (e.g. orcid) etc. so we need a solution for all identifier types.
… keeping dct and adms, there might be benefit in providing some additional context that helps programmatic access
<riccardoAlbertoni> i think the same solution can be applied to other kind of identifiers
<riccardoAlbertoni> no just datasets,
riccardoAlbertoni: one issue - if we have http uri, everything is in the link. in cases of non-http identifiers schema information and resolution info is required
… this follows from the discussion in the issue
… e.g. in example 4 there is an identifier from the USA copyright office where a skos:notation is given, but that is a literal
alejandra: your last comment confirms my thoughts that catalogues can have identifiers that are not dereferencable
alejandra: in catalogues that are not already in RDF there are non-dereferenceable IDs, but when they move to RDF they should turn to using dereferencable IDs
alejandra: my use case could be a catalogue of datasets that are available in other catalogues.
Makx_: I think this is an issue we cannot solve. assumptions around what happens to datasets in different catalogues might be something left to profiles.
… with EC DCAT-AP the harvesting data structure might not be able to create a coherent view on any kinds of environments
Makx_: a solution to 'identifiers' might be application-specific and non-generalisable
… hence profile proposal
<riccardoAlbertoni> let's do not have this part as normative
alejandra: I think that the distinction between primary (http URI) identifier is dct, but the secondary might not be dereferencable, hence adms and the additional context that it allows
… if we assume that it is always needed for secondary IDs,....
<alejandra> this is the original use case: https://www.w3.org/TR/dcat-ucr/#ID11
Makx_: I have difficulty with use of terms primary and secondary. these are not used in DCAT or DCAT-AP. There is no notion of primary & secondary. This is not appropriate for a primary standard. we should assume dct:identifier to be resolveable
DaveBrowning: Makx_ says what I think. primary and secondary are dangerous terms when we deal with non-RDF information. there are lots of thing 'out there' that have primary IDs that are not dereferencable because the publisher doesn't have a digital strategy
… I need to think about profiles setting the rules
alejandra: I pasted Andrea's link to the primary use case, but even for data sets there are use cases of the data set being in multiple catalogues. the dct would be for the data catalogue that you are describing, and the adms for the ones you're just referencing
Makx_: I want to make sure we take into account that in the base DCAT these are optional
… for the environment you have in mind you use identifiers the way you want. in the DCAT we shouldn't be imposing, but we can suggest patterns of use
alejandra: we should look at the use cases and issues to decide a way forward
… there is a need with the applications i've been involved with which might differ from that of DCAT-AP. We need to ensure that riccardoAlbertoni proposal covers all the issues we need to cover
<Zakim> riccardoAlbertoni, you wanted to say I agree on having guidelines, and you might have a dct:identifier "https://example.org/id"^^ex:type
Makx_: the primary/secondary needs to be separated from the issue of dereferenceable IDs
alejandra: my understanding was that adms:identifier could also include HTTP URI
Makx_: yes. there is a notation there, you can put anything there.
alejandra: we still need more input on this
… let's continue the discussion
<alejandra> https://github.com/w3c/dxwg/pull/611
<SimonCox> preview here https://rawgit.com/w3c/dxwg/dcat-issue79/dcat/index.html#qualified-attribution
SimonCox: a lot of list discussion about funder
<alejandra> issue on Funding source: https://github.com/w3c/dxwg/issues/66
<trackbot> Sorry, but no Tracker is associated with this channel.
<alejandra> and issue about qualified forms: https://github.com/w3c/dxwg/issues/79
SimonCox: that prompted bottoming out the qualified relations / qualified attribution pattern stuff, in the link
… we already have contributor, creator, publisher ... but there are a number of roles we can use, and there are mechanics in Prov-O that might help here
… the wrinkles are domain constraints which require a new property, and a new set of roles used in the examples here.
… I have added an example from the ISO geospatial metadata standard
… the role codes are in a list that covers more that the agent/entity examples
… so I'll point to ISO 19115 list
alejandra: if that list of roles is not a prescription from DCAT, can people use other roles
<SimonCox> https://rawgit.com/w3c/dxwg/dcat-issue79/dcat/index.html#Property:hadRole
SimonCox: yes; in this link I have put it into the normative reference section of the doc
… the usage note provides the explanation
<alejandra> this roles vocabulary might be also useful: https://dictionary.casrai.org/Contributor_Roles
Makx_: I think this is a good way of doing things, but we need to define a dcat "hadRole" prop. we are just proliferating properties
… this seems silly
SimonCox: it is unfortunate. we either proliferate props or we create new namespaces
alejandra: is there another vocab we can use
Makx_: looking at LOV there are 505 'role' properties - there are some in obscure namespaces, but I think SimonCox has the right approach
DaveBrowning: I agree with Makx_
… there are use cases covering qualified relations and when considering the PR I wondered how much this is a pattern we should promote, or is it simply a response to the role problem?
SimonCox: It is a discrete example of a general pattern and the wiki page has 2 specific high priority examples. The recommendation might not be the place for this advice, but it is something that we need to include along with dataset -> dataset relationships
… resource -> resource relationships are more elaborate/complex as they comprise everything
… I thought that the attribution one is uncontentious
… but we might need a DCAT funder
alejandra: a role , as prov indicates, is temporary and related to the situation.
SimonCox: in prov it is activity centric. it puts the activities at the centre of the model, but in DCAt we put the entities (endurants) at the centre of the model
<alejandra> PWinstanley: I've been raising that this requirement is much more centered around the univeristy and research arena
<alejandra> ... than the general case
<alejandra> ... so I've been suggesting that this should be left to profiles
<alejandra> ... I was proposing that if you put it into core DCAT, people that are not research related may feel that it is not for them
<alejandra> SimonCox: this doesn't come from the academic area, but to the geospatial area
<alejandra> ... it is worth having a general solution
reminder about promotion of 2nd PWD
<riccardoAlbertoni> thanks bye
Succeeded: s/looking at prov there are 505 properties/looking at LOV there are 505 'role' properties/