<SimonCox> rrsagent: make logs public
+1 for reopening the time discussion
+1 for 8am UTC
<PWinstanley> +1 for time proposal
<stijn_goedertier_AIV> +1
<Jaroslav_Pullmann> +1 for times proposed (9 AM EST)
<roba> +1
<SimonCox> Maybe 8am UK, 9am Europe, 5pm Eastern Australia
<alejandra> impossible for me at 8 am
what about 9am?
<PWinstanley> how about 09:30?
<alejandra> 9:30 would work for me
Action: make suggestion for 9:30UK 10:30Europe, 18:30EAUst to the list
<trackbot> Sorry, but no Tracker is associated with this channel.
<alejandra> depends on the date
<PWinstanley> date or day?
<alejandra> day, thanks :)
<SimonCox> https://www.w3.org/2018/04/18-dxwgdcat-minutes
<SimonCox> +1
<stijn_goedertier_AIV> +1
<roba> +1
<DaveBrowning> +1
<alejandra> 0 (was absent)
0 (wasn't there)
<PWinstanley> +1
<Jaroslav_Pullmann> 0 (most of time absent)
resolved approve minutes
SimonCox: Proposal tabled last week, but no consensus yet
<SimonCox> https://github.com/w3c/dxwg/wiki/Cataloguing-data-services#alternative-views
SimonCox: discussion on a number of patterns last week
Diagram a: Represents the current use of Catalog in Europe
... uses dct:hasPart property to link to other resources other than Datasets
Diagram b: multiple services are modelled as subclasses of dctype:Service
Diagram c: DataService is a subClassOf Distribution with a relation back to Datasets
... However, in current DCAT, Distributions are not members of Catalogs, i.e. this pattern does not mean that the DataService is member of a Catalog
<roba> "<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"
alejandra: have you considered the definition of DataService and how it relates to dctype:Service
+1 that Model c is an antipattern
<PWinstanley> I'm favouring 'e' too
<Zakim> AndreaPerego, you wanted to note that, just looking at the geo domain, there are view, transformation etc. services - not "download" services, strictly speaking
AndreaPerego: there are multiple types of services
… which are not necessarily downloadservices
<alejandra> AndreaPerego: such as transformation services
<roba> I dont mind solving that issue now - just want it to be explicit :-)
<PWinstanley> AndreaPerego: would authentication services be included somewhere?
Diagram d: is a tweaked version of a, and accommodates other types of services
SimonCox: f relaxes the semantics of Dataset
… but then its name is confusing
<SimonCox> arminhaller: OWL-S is simpler model, though not widely used
Jaroslav: DataServices might be a special service that serves Distributions, i.e. I like proposal D
roba: what about using the dctype taxonomy
SimonCox: Inspire has a separate vocabulary of service types
<AndreaPerego> ^^ http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType
<Zakim> alejandra, you wanted to ask about the relationship between the whole Data Catalog and the DataService
alejandra: Diagram e makes it clearer that the catalog also has a Dataservice
<SimonCox> AndreaPerego: can you comment on alejandra question
<AndreaPerego> alejandra, there are actually two different scenarios: a catalogue as a service, and a catalogue as a subset of another catalogue
stijn_goedertier_AIV: both solutions e and f can address the need for sources, more inclined for f
stijn_goedertier_AIV: f allows other resources to be types of catalog
<Zakim> SimonCox, you wanted to point out that dcat:dataset and dcat:service are sub-properties of dct:hasPart
SimonCox: generic membership predicate provides a proper extensibility. dct:hasPart is used as a generic membership predicate in proposal A, for example
… dataService would be a subclass of dct:hasPart or another generic membership predicate
<roba> and A
SimonCox: same applies for service in proposal E, which would be a subclass of a generic membership predicate
<Jaroslav_Pullmann> @Simon: would such a "membership predicate" be re-used to indicate content hierarchies (of e.g. DataSets)?
+1 for Simon's proposal of a generic membership predicate that is subpropertied
<Zakim> AndreaPerego, you wanted to propose we add to the service-related wiki page a list of service "types" from existing standards (as ISO 19119)
AndreaPerego: it might be worth capturing this in the wiki page
<alejandra> +1 to capture the list of available services
AndreaPerego: in the current usage of DCAT, there are different types of catalogs, such as geospatial catalogs
… and to group datasets in these catalogs, i.e. have subcatalogs
… a specific property to link a catalog to a service would be needed
Jaroslav_Pullmann: selective dataservices might serve selected types of distributions
… reuse the same predicate that we propose to have a content hierarchy of service types
… we don't have a content model for datasets
<SimonCox> maybe this proposal: model dcat:Catalog membership according to pattern E with membership predicates (e.g. dcat:dataset and others) modelled as sub-properties of the generic membership predicate (perhaps dct:hasPart?)
+1 to the proposal with "servesDataset" a subproperty of output
<Jaroslav_Pullmann> +1 for re-using a (recursive) membership predicate for 1st and N-th level of containment
roba: what canonical subtypes do we need to add, e.g. like the one armin proposed for servesDataset?
SimonCox: roba are you suggesting that we need to nail down the semantics of these new properties?
<PWinstanley> +1 to roba
<Zakim> AndreaPerego, you wanted to make a correction about diagram A
roba: it is a problem that comes up time and time again, what bits are canonical and which bits are open
AndreaPerego: question mark on diagram e is the relation between service and dataset
… relaxing the domain of dcat:dataset would solve the problem too
… link between the Distribution and the DataService
… is missing in e
SimonCox: it should be in e, but i haven't carried it down from proposal d to e
stijn_goedertier_AIV: difference between e and f, are we not missing the opportunity to have a hierarchy of types
… i am in favour of changing DCAT rather than proposing new properties
<alejandra> +1 to a merge of solutions E and F
SimonCox: stijn_goedertier_AIV you are looking for a merger of e and f
<SimonCox> Proposed: model dcat:Catalog membership according to pattern E with membership predicates (dcat:dataset, dcat:service, dcat:catalog and perhaps others) modelled as sub-properties of the generic membership predicate (perhaps dct:hasPart?), and member classes as sub-classes of a generic catalogued-item
<roba> +1
<AndreaPerego> +1
<Jaroslav_Pullmann> +1
<stijn_goedertier_AIV> +1
<DaveBrowning> +1
<alejandra> +1
<SimonCox> i.e. merge E and F (and point out alignment to OWL-S)
0 (probably it would be worth seeing the final proposal in a diagram first)
<SimonCox> +1
<PWinstanley> +1
*thumbsup* for the diagrams
bye
<PWinstanley> bye
<Jaroslav_Pullmann> bye!
Succeeded: s/impler/simpler
Succeeded: s/seperate/separate
Succeeded: s/stijn_goedertier_AIV: DataServices/Jaroslav: DataServices
Succeeded: s/generic membership/generic membership predicate
Succeeded: s/memebrship/membership
Succeeded: s/servesDataset/servesDataset?
Succeeded: s/properties/properties?