– DRAFT –
DXWG DCAT Subgroup Weekly Meeting

Admin

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

<alejandra> Minutes from two weeks ago: https://‌www.w3.org/‌2018/‌08/‌16-dxwgdcat-minutes

<roba> +1

proposed: approve minutes 2018-08-16

<alejandra> PROPOSED: approve minutes from two weeks ago: https://‌www.w3.org/‌2018/‌08/‌16-dxwgdcat-minutes

<roba> +1

<alejandra> +1

<DaveBrowning> +1

Resolved: approve minutes 2018-08-16

proposed: approve minutes 2018-08-23

<alejandra> https://‌www.w3.org/‌2018/‌08/‌23-dxwgdcat-minutes

<alejandra> +1

<DaveBrowning> +1

+1

Resolved: approve minutes 2018-08-23

<riccardoAlbertoni> +0 ( i was absent)

open actions

open actions

<alejandra> https://‌www.w3.org/‌2017/‌dxwg/‌track/‌actions/‌open

<alejandra> https://‌www.w3.org/‌2017/‌dxwg/‌track/‌actions/‌153

DaveBrowning: #153 is ongoing

<alejandra> https://‌www.w3.org/‌2017/‌dxwg/‌track/‌actions/‌173

<alejandra> the property is described here: https://‌w3c.github.io/‌dxwg/‌dcat/#Property:dataset_wasgeneratedby

PWinstanley: needing clarification about where it should go

<alejandra> some examples of wasGeneratedBy here: https://‌w3c.github.io/‌dxwg/‌dcat/#quality-example1

PWinstanley: thanks for the pointer

DaveBrowning: we have good examples for this too, but it will be 3-4 weeks before I can deliver them

DaveBrowning: there are 3 linked actions - #153. 184, 186. Some is editorial, but there is other stuff depending on how we do the release (hidden behind #186)

DaveBrowning: there are detailed questions about links within the document that I need to discuss with Dave Raggett. Early next week for editorial work

Public Comments

alejandra: none

Data Citation

<alejandra> https://‌github.com/‌w3c/‌dxwg/‌issues/‌61

alejandra: we discussed in the plenary that Dave Raggett needs to be involved and given dates of proposed publication of 2nd draft

alejandra: I've already made a PR that was merged, it included a note indicating the data citation as a potential profile

<alejandra> Note about data citation at section https://‌w3c.github.io/‌dxwg/‌dcat/#class-dataset

<DaveBrowning> Dave Raggett was emailed today, telling him about the date etc

<alejandra> Addition of dataset creator: https://‌w3c.github.io/‌dxwg/‌dcat/#Property:dataset_creator

alejandra: we also added a requirement for a dct:creator as part of a dataset

alejandra: we are not including a profile, but there is scope for creating a ShEx or SHACL constraint

riccardoAlbertoni: I can close the issue, but I would like a link, the one I tried was broken

alejandra: I will add a comment
… in issue #61 it is hard to understand what has happened

proposed: close issue #61

<DaveBrowning> +1

<riccardoAlbertoni> +1

<roba> +1

+1

<alejandra> +1

Resolved: close issue #61

Blank Nodes

<alejandra> https://‌github.com/‌w3c/‌dxwg/‌issues/‌300

alejandra: this started from another issue, then Jakub sought inclusion of some guidance against using blank nodes
… "should" rather than "must"
… can someone provide text and PR?

riccardoAlbertoni: the sentence I cited could be a good starter, so I could make the contribution

alejandra: I thought that we should initially define a blank node
… but please riccardoAlbertoni provide some text and a PR

actionn: riccardoAlbertoni to provide text for issue #300

assign: riccardoAlbertoni to provide text for issue #300

dataset size

<alejandra> https://‌github.com/‌w3c/‌dxwg/‌issues/‌313

alejandra: we discussed some time ago the current use by DCAT of bytesize which takes an integer, but there was discussion about UoM

<alejandra> https://‌lists.w3.org/‌Archives/‌Public/‌public-gld-wg/‌2012Oct/‌0117.html

alejandra: this topic has already been discussed and there was a previous proposal on size that needed blank nodes, so this was deprecated in favour of byteSize
… In microscopy files can be terabytes, so I wondered if we could find out about integer size
… so perhaps we need to have a UoM

roba: I see lots of places where sizes are arranged in a microformat, and this feels terse and natural. I think that using blank nodes it not a good idea, but a microformat with a qualified size might be better

roba: I'll find some

alejandra: do you have examples?

<roba> https://‌en.wikipedia.org/‌wiki/‌Microformat

<alejandra> PWinstanley: there's probably a need to leave open the possibility of units of measure

<alejandra> ... we are dealing with data streams where the size is infinite

<alejandra> ... but what might be relevant is the rate

<alejandra> ... that might be a very worthwhile thing to include

<alejandra> ... bytes per second

<alejandra> ... we need to think more deeply about this if we are going to use it at all

riccardoAlbertoni: I was thinking that it isn't necessary to add a blank node. we could have a new class with a number and a unit of measure. This would future-proof it

alejandra: then you assign an IRI to the object

+1 to riccardoAlbertoni

<Zakim> DaveBrowning, you wanted to mention support for rates

riccardoAlbertoni: there is a need for flexibility and durability in the long term and a new class would sort this

DaveBrowning: I want to support and disagree with PWinstanley . For streams a data rate would be helpful, but byteSize is already part of the 2014 standard, but if we use rates then that might be better supported by a separate issue. I cannot see an integrated solution

alejandra: I think it does deserve a new issue

Action: PWinstanley to create a new use case for rate

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

<riccardoAlbertoni> ok

<alejandra> continue the discussion in the issue: https://‌github.com/‌w3c/‌dxwg/‌issues/‌313

alejandra: we now need to investigate the microformat option suggested by roba . I think that a new class as described by riccardoAlbertoni might be overkill if we are moving to a new issue about rate

<DaveBrowning> ok for continuing conversation

roba: is this something we can leave in limbo whilst connecting up with people involved in data streaming at TPAC?
… there might be expertise we can pull from participants at that meeting

roba: a lot of people are concerned about describing size and there needs to be alignment across W3C work

<alejandra> https://‌github.com/‌w3c/‌dxwg/‌issues/‌125

alejandra: one issue was describing size - so we leave open for continued analysis and discussion,
… but there is also issue #125 - the constraints that dcat:byteSize has and if there needs to be some relaxation of constraints
… any views?
… one case is that we allow loose files to be connected with dct:relation

DaveBrowning: I think that is a good observation. supporting collections of files need to be done consistently. the domain constraint doesn't make sense. I agree we should relax the constraint

<riccardoAlbertoni> +1 to relaxing the domain, also because this change seems to be back compatible ..

roba: this raises an interesting issue - in e.g. SKOS there is detail about the entailments that are supported. I've yet to see a strategy for coherently documenting this
… any suggestions?

roba: I find that this happens so often that we need to have guidance on the assumptions that can be made

<alejandra> at the moment the range is rdfs:range rdfs:Literal ;

<alejandra> note indicating "The literal value of dcat:byteSize should by typed as xsd:decimal".

alejandra: maybe we're not now in a position to decide, but removing domain constraints would not make much different. In both issues there is also discussion about range. At the moment it is a literal
… but there is a scope note suggesting it could be a decimal

<alejandra> https://‌www.w3.org/‌TR/‌xmlschema11-2/#positiveInteger

<alejandra> optional positive sign ('+') followed by a non-empty finite-length sequence of decimal digits (#x30-#x39)

alejandra: Makx pointed out that there are implementations using xsd:decimal, but Simon suggested using positiveInteger
… this refers to a lexical representation of a plus sign followed by decimal digits of finite length

<roba> if the positive sign is mandatory i think its a problem..

<roba> *oops i see optional !

alejandra: are we limiting by only using bytes, this gives a upper limit and it might preclude describing really large files (e.g. MRI files)

<riccardoAlbertoni> yes I think so , we have a limit, even if I don't know which limit is

<roba> limit will be implementation specific

alejandra: so I think we should consider other units of measure

<alejandra> PWinstanley: byte sizes - issue about precision...

<alejandra> ... and UTF8 / UTF16

riccardoAlbertoni: it seems there is no solution that fits all situations, it depends on the use. we need to be flexible, and perhaps put this into the profile
… the UoM could be expressed explicitly in the profile. Specific communities in defining a profile can specify their UoM

roba: radical proposal - if we want the semantics of an exact size we probably need byteSize (integer) and an approximate size (which could take a microformat). i think this would be practical

alejandra: the previous spec considered approximate size
… on issue 313,

<alejandra> https://‌github.com/‌w3c/‌dxwg/‌issues/‌313

alejandra: the indicated that the same property can be used for accurate and approximate byte sizes

roba: we need exact measures to know if we have everything. vague statements are hard to work with in practice

alejandra: let's continue the discussion in github

<alejandra> https://‌github.com/‌schemaorg/‌schemaorg/‌issues/‌1855

alejandra: for now let's leave
… There was a related schema.org issue worth looking at in this context

<alejandra> https://‌github.com/‌w3c/‌dxwg/‌issues/‌300

dct:type Class vs Concept

<alejandra> https://‌github.com/‌w3c/‌dxwg/‌issues/‌314

roba: an assertion from SDWWG where range was formally an rfds:Class, but is used as a skos:Concept
… I think that is a suggestion for a strong requirement for OWL-DL compatibility- but we don't have this at present so we need to make a use case and decide if it is for DCAT of for the Profiles group to consider
… we need the UC developed
… we don't know yet if it is a valid requirement. this at present is a philosophical conversation about whether punning should be allowed or not

DaveBrowning: I agree with roba . it is a theological debate
… we need to be led by use cases

alejandra: who should do this UC work?

roba: external comments brought this to our attention, but it needs group involvement for us to consider

<riccardoAlbertoni> Thanks a lot, bye

alejandra: let's leave this for the time being and follow up later