– DRAFT –
DCAT Vocabulary team 2018-04-25

<SimonCox> rrsagent: make logs public

+1 for reopening the time discussion

approve agenda

+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 :)

Approve minutes of last meeting

<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

Consequences of expanded scope of dcat:Catalog

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

<SimonCox> https://‌raw.githubusercontent.com/‌w3c/‌dxwg/‌gh-pages/‌dcat/‌images/‌Catalog-membership-options.png

<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!