<SimonCox> https://www.w3.org/2017/dxwg/wiki/Meetings:DCAT-Telecon2018.02.28
SimonCox: review of the agenda
<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
<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
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
<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
alejandra: When was the profiles meeting?
PWinstanley: 09:00 UTC on 28th Feb
<SimonCox> ca. 12 hours ago - no one here
<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
Succeeded: s/SDOW/SDWWG/
Succeeded: s/... It also seems a good practice (from the sensor networks vocab example)/... It is also good modularization practice in vocabularies (and demonstrated in the sensor networks vocabulary)/
Succeeded: s/Idenitification /Identification /
Succeeded: s/mentiones/mentions/
Succeeded: s/rance/range/
Succeeded: s/dct:rights/dct:accessRights, both subproperties of dct:rights/
Succeeded: s/rrsagent draft minutes//
Succeeded: s/rrsagent: draft minutes//
Succeeded: s/rrsagent: draft minutes//