<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.
<SimonCox> https://www.w3.org/2017/dxwg/wiki/Meetings:DCAT-Telecon2018.04.18
<SimonCox> confirmed
<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
<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
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
<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
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/