W3C

– DRAFT –
DCAT team 2018-04-18

18 April 2018

Meeting Minutes

<SimonCox> rrsagent: make logs public

<NicholasCar> Morning, can hear but will limit speach - sleeping kids

<SimonCox> Problem with webex DaveBrowning ?

<DaveBrowning> Will join soon

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

<NicholasCar> issue above is license/ODRL

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

confirm agenda

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

<SimonCox> confirmed

approve minutes of last meeting

<SimonCox> https://‌www.w3.org/‌2018/‌04/‌11-dxwgdcat-minutes

<AndreaPerego> +1

<riccardoAlbertoni> 0 ( i was absent)

<DaveBrowning> 0 also absent

<SimonCox> 0 (absent)

+1

<stijn_goedertier_AIV> +1

<NicholasCar> +1

Resolved: approve minutes of last meeting

licenses and rights

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

<SimonCox> https://‌github.com/‌w3c/‌dxwg/‌issues/‌114#issuecomment-382298577

SimonCox: drawing attention to this topic of discussion. Makx providing clarification as per comments
… in earlier conversations best practice would be to refer to existing, but we need to have the possibility of coping with new options and other elements that ODRL allows.
… An informal use case has been added. Other contributions are welcomed

<SimonCox> Should we add odrl:hasPolicy as an additional property recommended for use on a dcat:Distribution?

NicholasCar: is it sensible to have policy associations? Anything that retains flexibility is a good thing

SimonCox: OWL/RDFS constraints are not there, it is simply a recommendation
… but do we formally include ODRL as a suggestion in the spec?

NicholasCar: I think that is helpful
… it is a useful pointer to developers/catalogue managers

DaveBrowning: I agree with NicholasCar . ODRL provides scope for wide coverage within the publishing industry and provides economies of scale - it is a one-stop shop

<roba> if we need a machine readable validation around use of a recommended vocabulary then we have a formal profile..

AndreaPerego: we need to clarify the use cases where ODRL is helpful. We already have dct:rights and others. I don't recall any use case not covered by the generic

SimonCox: we are aware that there is no documented use case and hence NicholasCar has added a full additional use case specifically using ODRL
… there needs to be proper guidance in the doc

<stijn_goedertier_AIV> Andrea refers to the ODRS http://‌schema.theodi.org/‌odrs/

AndreaPerego: We still need to discuss the the ODI vocabulary - ODRS
… it is worth looking at this because they found a way to use a standard license and determine the text for the attribution.
… this is dependent on the dataset that one is licensing

SimonCox: AndreaPerego can you please add to #114

NicholasCar: Am aware of ODRS. Have used. Next question is do we need both, or will ODRL do everything? I'm implementing a license register in a project and will have an ODRL test case in Linked Data using real data

SimonCox: It is premature to consider the agenda proposal but that conversation provided issues that we add to the discussion

Consequences of expanded scope of dcat:Catalog

SimonCox: 2-3 weeks ago we agreed that DCAT would explicitly cover data services, but we haven't considered specific proposals for new properties

<SimonCox> specific or general property for catalog contents - https://‌github.com/‌w3c/‌dxwg/‌issues/‌116

SimonCox: a long thread on issue 116 is about the range of dcat:Dataset.
… the dcat:dataset pred has been used to link to things that hitherto would not have been considered as datasets,
… but we are proposing to extend the use of dcat:dataset so that one looks at the items to determine their class rather than inferring from the range
… Next step is to mint specific predicates for different catalogue contents

<roba> we can hear you nick

NicholasCar: isn't this direct predicate minting against the qualified association pattern we are implementing elsewhere?
… isnt' a generic approach better?

SimonCox: when modelling the tension between generic and specific is always there. No 'right' answer. specific preds are there for 'important' relationships
… The qualified association pattern requires a sideways look to determine the class
… in this situation the name of the predicate is unsuitable for classes that are not datasets. If we are expanding to include services it makes sense to have a service-specific pred

<SimonCox> Please see https://‌github.com/‌w3c/‌dxwg/‌wiki/‌Cataloguing-data-services

<roba> wonders if we are we talking about data sets exposed by services - or data-less transformation services?

SimonCox: the 2nd diagram in the above wiki page shows the most common use case and the relations between the service and the datasets

<Zakim> AndreaPerego, you wanted to say that the two approaches (generic vs specific properties) are not mutually exclusive

<roba> the proposal does not change the scope of dcat:dataset - it adds finer grained semantics around distribution

AndreaPerego: we have an example taken from different context that include resources that are dcat:Dataset, but we also have events which can be either datasets or physical things like chemical samples.
… we need to leave the door open for diverse classes, so a generic property can help with this

<roba> but is a data access service a virtualised "set of datasets" ?

SimonCox: in some examples in the past AndreaPerego you used dc:terms?

<SimonCox> dcterms:hasPart

AndreaPerego: yes, because no other was available/suitable

<riccardoAlbertoni> s\dc:terms\dcterms:hasPart

AndreaPerego: the point is that this predicate is overused and it has become ambiguous

SimonCox: it is from observiing that that the motivation for other predicates originated
… we should allow ourselves to include other predicates than dcat:dataset
… and this means that we don't need to relax the range of this pred
… the thinking originates from observing what AndreaPerego has done before

<Jaroslav_Pullmann> Hello everybody, I am travelling with no reliable connection.

SimonCox: this list of predicates will be small in number (<5) but will be specific to the class

<SimonCox> PROPOSED: the range of dcat:dataset shall not be relaxed, and the DCAT backbone shall have specific properties for other types of resource included in a catalog (sub-properties of dct:hasPart)

<SimonCox> PROPOSED: the range of dcat:dataset shall not be relaxed, and the DCAT backbone shall have specific membership predicates for other types of resource included in a catalog (sub-properties of dct:hasPart)

<Jaroslav_Pullmann> * Hi Andrea!

<Zakim> AndreaPerego, you wanted to ask is this includes a possible super-property for them

<SimonCox> PROPOSED: the range of dcat:dataset shall not be relaxed

AndreaPerego: for clarification - the proposal is for 5 props, or are these to be sub-props of a more generic super-prop?

<SimonCox> issue #116

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

<riccardoAlbertoni> +1

<AndreaPerego> +1

<SimonCox> +1

+1

<Jaroslav_Pullmann> +1

<DaveBrowning> +1

<stijn_goedertier_AIV> +1

<roba> dataservice as a subtype of dataset that has1+ service distributions and may have multiple other datasets exposed (finer grained semantics?)

<SimonCox> so we can close https://‌github.com/‌w3c/‌dxwg/‌issues/‌116

roba: I think this comes down to finer grained semantics. I think services look like datasets

SimonCox: the boundary between serialised resources and services is blurred

<roba> +1

Resolved: the range of dcat:dataset shall not be relaxed

<SimonCox> class and property for data distribution service https://‌github.com/‌w3c/‌dxwg/‌issues/‌180

issue 180

<roba> so if a distribution was able to specify service type would this motivation still hold?

Resolved: the range of dcat:dataset shall not be relaxed

<riccardoAlbertoni> \me ok

<roba> (note a subproperty of dcat:dataset where range is a subclass of Dataset meets the proposal)

<roba> ... that was my suggestion

SimonCox: roba please can you explain your vision in a diagram?
… then we can do a comparison

roba: going back to the original proposal - the one on the wiki page -- 2 classes, almost identical.

<roba> ok

<roba> so if a distribution was able to specify service type would this motivation still hold?

Action: RobA to make more detailed counter-proposal

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

<roba> especially if a sub-type of Dataset which is a collection of other datsets is also supported (i.e we have data set relationships)

<roba> otherwise we may have multiple ways of doing this when those facilities are available

SimonCox: This goes back to the earlier part of the discussion - many solutions and we decide to give names to some properties and not others depending on the way the model is going to be used

<AndreaPerego> @roba, yes it holds for me. The service itself won't be "hidden" into a distribution, but a standalone entity.

SimonCox: frm the discussion coming from AndreaPerego services needed to be first class objects in a data catalogue.
… there might appear to be an implicit super class,

<roba> @AndreaPerego - yes it still will be as a sube type of Dataset...

<AndreaPerego> The distribution can be linked to the service, but it is not the distribution itself.

SimonCox: we might be mixing the abstractions in the background with requirements in the foreground.

<roba> yes an implicit superclass would help but changes the range of dcat:dataset :-(

SimonCox: the diagram might be showing only a part view of the requirements, with some components not shown

<Jaroslav_Pullmann> Dear all, before this meeting ends - I started to include Øystein's proposals like here: https://‌github.com/‌w3c/‌dxwg/‌issues/‌56#issuecomment-382467602

I have lost audio

<roba> anyway - I'm pointing out what looks like an antipattern in the model, and missing consideration of the implications of service types in distribution semantics - i would rather see this discussed when those facilities are on the table

riccardoAlbertoni: the services are not only ones exposing data, they can be other types. In this case it is perhaps better not to use a subclass. It would be reasonable to have class specialisation if they are services exposing data, but a DCAT catalogue can include other kinds of services
… it is not a matter of object orientation, it is a matter of what the classes represent

<roba> @riccardoAlbertoni I agree - but i would model it differently if thats the case... we perhaps need a superclass or "mix-in" for generic catalog entry metadata

SimonCox: this discussion needs to be continued next week

<AndreaPerego> +1 to riccardoAlbertoni

Summary of Action Items

  1. RobA to make more detailed counter-proposal

Summary of Resolutions

  1. approve minutes of last meeting
  2. the range of dcat:dataset shall not be relaxed
  3. the range of dcat:dataset shall not be relaxed
Minutes formatted by Bert Bos's scribe.perl version 2.41 (2018/03/23 13:13:49), a reimplementation of David Booth's scribe.perl. See CVS log.

Diagnostics

Succeeded: s/clasrification /clarification /

Succeeded: s/RESOLVED: the range of dcat:dataset shall not be relaxed, and the DCAT backbone shall have specific membership predicates for other types of resource included in a catalog (sub-properties of dct:hasPart)/RESOLVED: the range of dcat:dataset shall not be relaxed/

Succeeded: s/but it is the distribution itself/but it is not the distribution itself/