<alejandra> Minutes from two weeks ago: https://www.w3.org/2018/08/16-dxwgdcat-minutes
proposed: approve minutes 2018-08-16
<alejandra> PROPOSED: approve minutes from two weeks ago: https://www.w3.org/2018/08/16-dxwgdcat-minutes
Resolved: approve minutes 2018-08-16
proposed: approve minutes 2018-08-23
Resolved: approve minutes 2018-08-23
<riccardoAlbertoni> +0 ( i was absent)
DaveBrowning: #153 is ongoing
<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
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
Resolved: close issue #61
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
alejandra: we discussed some time ago the current use by DCAT of bytesize which takes an integer, but there was discussion about UoM
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?
<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.
<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: 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> 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: 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: for now let's leave
… There was a related schema.org issue worth looking at in this context
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
No scribenick or scribe found. Guessed: pwinstanley