– DRAFT –
DCAT vocabulary team 2018-02-28

confirm agenda

<SimonCox> https://‌www.w3.org/‌2017/‌dxwg/‌wiki/‌Meetings:DCAT-Telecon2018.02.28

Admin

SimonCox: review of the agenda

approve minutes of last meeting

<SimonCox> https://‌www.w3.org/‌2018/‌02/‌21-dxwgdcat-minutes

<SimonCox> +1

<alejandra> +1

<DaveBrowning> +1

<Jaroslav_Pullmann> 0 (absent)

+1

<NicholasCar> +1

Resolved: minutes approved

current draft

<Stijn_Goedertier_AIV> +1

<SimonCox> https://‌w3c.github.io/‌dxwg/‌dcat/#issue-summary

SimonCox: the main thing is having a doc which when released gives people an idea of the areas where change is proposed
… It doesn't reflect all the issues in the tracker, so please consider including into the draft any change proposals that are not already mentioned in the draft

github etiquette

SimonCox: A reminder (from Nic) about github etiquette - merges only done by the nominated editors please
… Note that editors don't merge their own proposals

<Zakim> DaveBrowning, you wanted to ask what we need to do for FPWD

DaveBrowning: How do we know when we're ready for producing the FPWD?

SimonCox: my understanding is that there is a time box. This team doesn't vote, that's for the plenary to decide on release schedule

<Zakim> alejandra, you wanted to propose that we put as reviewers all the editors in the tracker (explore github groups)

alejandra: going back to etiquette - I want to propose that pull requests are not one of the editors but using github groups (there is a problem in that it might not notify) . This would allow any one of us to review and merge

SimonCox: sounds reasonable

alejandra: if we assign the group we (the editors group) all get a notification, and that could distribute the load easier

RDF files

<SimonCox> https://‌github.com/‌w3c/‌dxwg/‌issues/‌134

SimonCox: issue 134 attempts to simplify the SDWWG approach of modularising the RDF
… the underlying goal is to permit clean documents and discussions
… To establish the proposition that more than one RDF file can be involved, I want to suggest that modularisation is the approach we use

<alejandra> I agree

PWinstanley: are there any heuristics do help determine when it becomes too complex

alejandra: The issue initially is regarding PROV, but addressing the complexity I think we can use the PROV discussion to see how the modularisation approach simplifies / facilitates the discussion
… I think it is a good to solution to help the discussion
… It is also good modularization practice in vocabularies (and demonstrated in the sensor networks vocabulary)

<AndreaPerego> +1 from me, to allow us work in parallel on possible DCAT extensions, leaving at a later moment the decision on how they should be integrated.

<DaveBrowning> +1 from me, too

Jaroslav_Pullmann: Identification of the normative and the optional parts of DCAT isn't the easiest task

SimonCox: as alejandra mentions, anything that isn't underpinned by requirements is probably not normative

Jaroslav_Pullmann: most of the requirements are looking at extensions, so they are perhaps additional to the 'core'

<SimonCox> motivations should be driven by data! - see https://‌github.com/‌w3c/‌dxwg/‌issues/‌137

Jaroslav_Pullmann: We could use e.g. the European Open Data portal to review how DCAT is currently being used to determine the 'core'

SimonCox: The new issue 137 anticipated this need for test data sets
… It will help us build the evidence base for our recommendations

<SimonCox> Proposed: Additional RDF files can be created alongside dcat.ttl to test proposals around modularization and alignment with other RDF vocabularies. Note: These may or may not be merged into fewer or one RDF files prior to publication.

<alejandra> +1

<SimonCox> +1

<Jaroslav_Pullmann> +1

<DaveBrowning> +1

+1

<Stijn_Goedertier_AIV> +1

<AndreaPerego> +1

<NicholasCar> +1

<arminhaller> +1

Resolved: Additional RDF files can be created alongside dcat.ttl to test proposals around modularization and alignment with other RDF vocabularies. Note: These may or may not be merged into fewer or one RDF files prior to publication.

<alejandra> I can now merge https://‌github.com/‌w3c/‌dxwg/‌pull/‌94

profiles

license and rights

alejandra: When was the profiles meeting?

PWinstanley: 09:00 UTC on 28th Feb

<SimonCox> ca. 12 hours ago - no one here

license and rights

<alejandra> it would be good that these meetings are announced in the mailing list (and notes distributed)

<SimonCox> https://‌github.com/‌w3c/‌dxwg/‌issues/‌104 https://‌github.com/‌w3c/‌dxwg/‌issues/‌114

SimonCox: let's consider issues 104 and 114
… the main proponents are NicholasCar and Makx

NicholasCar: The intention is to enable us to indicate sophisticated/machine-readable licensing in a form other than free text
… URIs might link to RDF objects that would allow reasoning

<SimonCox> ... and aisaac involved in license-document discussion as well

NicholasCar: the recently published ODRL might provide a class or two that describes the intention that I'm looking for that, unlike dct:license, doesn't have a document as the range

<SimonCox> we are talking about #114 first

<alejandra> ODRL link: https://‌www.w3.org/‌TR/‌odrl-model/

<SimonCox> Definition of dct:LicenseDocument ```dcterms:LicenseDocument dcterms:hasVersion <http://‌dublincore.org/‌usage/‌terms/‌history/#LicenseDocument-001> ; dcterms:issued "2008-01-14"^^<http://‌www.w3.org/‌2001/‌XMLSchema#date> ; a rdfs:Class ; rdfs:comment "A legal document giving official permission to do something with a Resource."@en ; rdfs:isDefinedBy <http://‌purl.org/‌dc/‌terms/> ; rdfs:label "License Document"@en ; rdfs:subClassOf[CUT]

<SimonCox> http://‌dublincore.org/‌2012/‌06/‌14/‌dcterms#LicenseDocument

Makx: you cannot redefine dct:license . Antoine mentioned that the current usage of putting a URL to a license there is not in line with the model, but it is common practice

SimonCox: Is the restriction from the range of dct:license as onerous as is being implied. The RDF definition of a license document is a shell, it doesn't being any other entailments along. Is there any problem? the entailment implied is that the range would also be classified as a dct:license doc

<SimonCox> what is the harm from the target of dct:license being a dct:LicenseDocument?

<SimonCox> There are no strong entailments ...

NicholasCar: technically there might not be, but there is an ongoing issue - we would need to let people know that it might be more than a document
… we would need to put that into notes
… Technically we might not be constrained, but we would do ourselves a disservice if we didn't indicate that other more sophisticated objects might be used as the range

<AndreaPerego> Definition of dct:LicenseDocument: "A legal document giving official permission to do something with a Resource."

Makx: looking in detail, it relates to a legal document
… an ODRL resource would be outwith the specification provided by DCMI

NOTE: Makx's audio dropped at this point

AndreaPerego: we should focus on usage rather than the DCMI spec

Makx: There could be people who have problems with the DCMI definition limiting the way that dct:license is used
… If we don't want to put ODRL into dct:license then this is wider that just DCAT
… Maybe we need to talk to ODRL and see how they envisage pointing to a rights object

<SimonCox> AndreaPerego: dct:license is only about _use_ conditions

AndreaPerego: there is a distinction between access and usage rights

<alejandra> dct:license and dct:accessRights, both subproperties of dct:rights

AndreaPerego: it is important to keep these two separate
… I don't have a problem in using ODRL for license, but this should be for usage and not for access

<SimonCox> ODRL is only about use conditions, not access

<Zakim> SimonCox, you wanted to note that 'document' is a rather general concept on the web and to note 'legal' may be seen differently in statutory vs common-law traditions ...

SimonCox: 2 technical points: document used in a web context refers to a serialisation
… #2, responding to Makx who focused on 'legal' - there are issues with common law jurisdictions in relation to contract. There may be culturally specific issues to consider here

SimonCox: re: ODRL, Makx is suggesting that we reach out to the ODRL group to get their input

SimonCox: Makx , please can you get a clarification from the ODRL group
… this discussion relates to issue #114 . Can some of this discussion be added to that / alert Antoine to this conversation

Makx: I am ok with using dct:license with ODRL

<SimonCox> AndreaPerego: is concerned that we also clarify distinction between access and use rights

AndreaPerego: we should also ask the ODRL about use / access. A permission relates to an action over an asset. This could be access

SimonCox: in the current documentation do you AndreaPerego see opportunity for improving the wording?

<SimonCox> should dcat also refer to dct:accessRights ?

SimonCox: potentially you are proposing that dct:accessRights be mentioned in the DCAT doc

<Makx> will do this in the next couple of days

<NicholasCar> must go, bye!

<Makx> hope to have an answer by next week

<AndreaPerego> bye, NicholasCar !

Action: Makx to clarify the expections of ODRL about the use of ODRL in the contect of dct:license

<trackbot> Sorry, but no Tracker is associated with this channel.

<alejandra> Is IRC already linked to the action tracker?

<AndreaPerego> Nope.

<Makx> ok thanks see ou next time

<Stijn_Goedertier_AIV> bye bye

<Jaroslav_Pullmann> bye & thanks!

<alejandra> thanks, and bye

Action: AndreaPerego to verify if changes to documentation of use of dct:license and dct:rights are needed

<trackbot> Sorry, but no Tracker is associated with this channel.

Action: AndreaPerego to consider if dct:accessRights should be inlcuded in DCAT

<trackbot> Sorry, but no Tracker is associated with this channel.

Action: SimonCox to add some notes to #114 pointing to this discussion, so aisaac can get caught up on the discussion

<trackbot> Sorry, but no Tracker is associated with this channel.

<SimonCox> bye