– DRAFT –
DXWG DCAT subgroup teleconference

<SimonCox> Hi Stijn

<SimonCox> Doesn't seem to be anyone else here - not sure what the confusion is, I guess I made a mistake somewhere

<StijnGoedertier_AIV> 3 gave their regrets https://‌www.w3.org/‌2017/‌dxwg/‌wiki/‌Meetings:DCAT-Telecon2018.02.07

<StijnGoedertier_AIV> Hi Simon

<SimonCox> I'll wait 3 more minutes then we'll give up - sorry

<StijnGoedertier_AIV> ok, I see Andrea Perego connecting

Approve last week minutes

<SimonCox> https://‌www.w3.org/‌2018/‌01/‌31-dxwgdcat-minutes

<SimonCox> +1

+1

<StijnGoedertier_AIV> +1

<NicholasCar> +1

Resolved: Last meeting minutes approved

<SimonCox> https://‌w3c.github.io/‌dxwg/‌dcat/

Actions from last meeting

SimonCox: [explaining work done in GH]

<SimonCox> https://‌github.com/‌w3c/‌dxwg/‌tree/‌simon-dcat-doc-issues

SimonCox: Relevant PR: https://‌github.com/‌w3c/‌dxwg/‌pull/‌102

<SimonCox> Use this syntax to link a document issue to GitHub issue <p class="issue" data-number="98">

SimonCox: This makes GH embed a link into a GH issue.

Review requirements

<SimonCox> https://‌github.com/‌w3c/‌dxwg/‌issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Adcat+label%3Arequirement+

<SimonCox> Encourage people to continue reviewing tags on github issues

SimonCox: A few people went through the GH issues. Labelling improved a bit (good!). We are making some progress. I encourage people to work this out.

SimonCox: I was hoping to discuss some of these issues. Alejandra and I identified some of them.
… One is #53

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

SimonCox: There's some discussion on this issue.

<NicholasCar> q

SimonCox: My understanding is that in RDF world this means HTTP URIs.

<SimonCox> AndreaPerego: main issue is that a number of other identifier systems are used for dat acitation, publishers, etc

<SimonCox> ... e.g. DataCite supports quite a few identifier systems

<SimonCox> ... DCAT-AP also discussed this at length

<SimonCox> ... agencies want to use their internal identifiers, not necessarily URIs

<SimonCox> ... may connect datasets using SPARQL queries, etc not just URIs

<SimonCox> ... what is needed by different communities is ability to specify different kinds of identifiers, and their *type*

<SimonCox> ... need to indicate that a string _is_ an identifier

<SimonCox> ... whenenver possible make identifiers resolvable by _encoding_ them as URIs, but this does not apply to all identifier systems

<SimonCox> ... situation is quite complicated

<SimonCox> there are some other URI systems, but not necessarily resolvable

<SimonCox> ... case sensitivity is also an issue

<SimonCox> ... proposal made in UC is to try to address both issue

<SimonCox> ... 1. encode as http URIs where possible

<SimonCox> ... 2. encode as a string using dct:identifier property, and note the type of the identifier using ^^type indicator

<SimonCox> ... Makx also suggests adms:identifier

<SimonCox> ... UC is about _providing guidance_ where standard RDF http URI does not apply

<SimonCox> ... also for how to use SPARQL queries, for example

NicholasCar: We had the same issue with physical samples.

<SimonCox> NicholasCar: similar issues with identifier off-web resources which have local/scoped identifiers

NicholasCar: The critical ID was the URI, since we have already other IDs as DOIs.

<SimonCox> ... recommendation there is to supplement identifier field with identifier-type

<SimonCox> ... need a comprehensive schema for alternative identifiers

NicholasCar: [missed]

SimonCox: Makx suggested looking at ADMS.

<SimonCox> https://‌www.w3.org/‌TR/‌vocab-adms/#identifier

<NicholasCar> It would be beneficial to have a comprehensive handling of identifiers, inc. type and other properties, as we need to use them in many situations, not just DCAT

SimonCox: There's an adms:Identifier class there.

<NicholasCar> Yes, ADMS seems to mostly do it!

SimonCox: It is based on UN/CEFACT. So, this appear that fullfills the proposal you made, AndreaPerego.

<SimonCox> Adopt or clone adms:Identifier

<SimonCox> AndreaPerego: alternative proposals: PRISM, BIBO,

<SimonCox> ... specific fields for well-known identifier schemes, e.g. bibo:DOI

<SimonCox> ... these are already used by some important services, e.g. crossRef

<SimonCox> ... need to explain how these different approaches map to each other

SimonCox: We should drop some of this discussion in GH.

Action: SimonCox to drop identifeir discussion into GitHub issue

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

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

<Zakim> StijnGoedertier_AIV, you wanted to comment on additional guidance on the type of HTTP IRIs for a dcat:Dataset vs dcat:CatalogRecord

<SimonCox> StijnGoedertier_AIV: use CatalogRecord as proxy for off-web resources

<SimonCox> ?

SimonCox: Could you provide a scenario?

NicholasCar: I think the issue StijnGoedertier_AIV mentioned was about what you get from an HTTP URI - the thing, or its description thereof.

StijnGoedertier_AIV: I have this doubt because of the definition of a catalogue record.

<SimonCox> AndreaPerego: relationship between CatalogRecord and Dataset needs clarification

<SimonCox> ... in the CatalogRecord can attach metadata about the metadata - e.g. who created the record, in contrast to metadata about the dataset, e.g. topic, publisher, etc

<SimonCox> ... is standard registry model (e.g. ISO 19135, Linked Data Registry, ISO 11179)

<SimonCox> ... where registration information is separate from the dataset description

<NicholasCar> clear to me

<NicholasCar> yes, I meant that two URIs for Cat. Rec. & Dataset are not used in practice, despite the DCAT option for it

<SimonCox> ... not sure any system actually assigns separate URIs for catalogue record and metadata entry

SimonCox: The Linked Data Registry actually can do that.

<StijnGoedertier_AIV> http://‌registry.it.csiro.au/

dataset type https://‌github.com/‌w3c/‌dxwg/‌issues/‌64

SimonCox: There was some discussion on this.
… A number of vocabularies have been mentioned.
… Issue #95 notes that dcat:Dataset is made a subclass of dctype:Dataset, and the latter is just one of the DCType classes that could be considered as dcat:Dataset's.

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

SimonCox: So, we should probably relax this. Moreover, dctype:Dataset has a quite weak definition.

<NicholasCar> agreed

SimonCox: The proposal is to remove the subclass axioms.

+1 from me.

<StijnGoedertier_AIV> +1 for me as well

<SimonCox> +1

<NicholasCar> +1

Resolved: Drop subclass axiom from dcat:Dataset

SimonCox: Related issue was how to associate dct:type for soft typing.
… There's a meta-issue on whether we should use more OWL axiomatisation to specify which properties should be used for which classes.

<SimonCox> Should we use OWL to bind predicates to classes? https://‌github.com/‌w3c/‌dxwg/‌issues/‌105

<SimonCox> DCAT 1.0 just says "The following properties are recommended for use on this class"

SimonCox: Makx and Andrea tend to support the idea of not using it.

<SimonCox> so just add dct:type to that list

SimonCox: So, this way we have more or less resolved issue #64

<SimonCox> with some indications of available type vocabularies

+1

<NicholasCar> +1

<SimonCox> +1

<StijnGoedertier_AIV> +1 Makes DCAT most broadly usable

<NicholasCar> (no other comments)

Resolved: Include dct:type in the list of properties recommended for dataset

Resolved: Include dct:type in the list of properties recommended for dataset, list some of the type vocabularies contributed in the GH issues. This resolves issue #64

<NicholasCar> I have 5

- https://‌github.com/‌w3c/‌dxwg/‌issues/‌95

<SimonCox> AndreaPerego: domain of contactPoint is limited to Dataset

<SimonCox> ... so can't be re-used in other context without entailment that they are a Dataset!

<SimonCox> ... contactPoint is one of the most imporant roles encoded in metadata!

<SimonCox> ... needs to be available in many places

<SimonCox> ... what was it set this way???

<SimonCox> +1

<StijnGoedertier_AIV> +1 to remove the domain restriction

SimonCox: I am not very much in favour of setting domain restrictions on properties, since this reduces reusability.

<NicholasCar> +1

StijnGoedertier_AIV: I think it is still important to have a range for interoperability purposes.

Resolved: Drop domain restriction from dcat:contactPoint

<SimonCox> Agreed - I will generate separate issue.

meeting adjourned