- These minutes: https://github.com/dcmi/usage/blob/master/minutes/2018/2018-06-27.dcub-telecon-minutes.md
- Attended: Tom (chair), Valentine, Karen, Osma, Stefanie, Joachim
16: Comments for dct:date - #16
Joachim: Issue: extending comments with time. Just refer to ISO 8601? Link to W3 note about a subset? Has been solved by a suggestion from Juha that we link to both. LC suggestion has been input to ISO process, "extended version" covering uncertain and approximate dates, but not yet available to public. My suggestion simply says:
Date may be used to express temporal information at any level of
granularity. Recommended practice is to express the date, time, or period
according to a published profile of ISO 8601.
Plus examples. But not uncertain or approximate dates because they are not yet standard. I propose that we add the examples, citing W3DTF and EDTF. Can be changed easily when ISO standard is published. Should mention:
- The extended features of EDTF 1.0, such as uncertain and approximate
values, have been incorporated, with some syntactic changes, into the
ISO-8601-2 draft.
- The publication of an ISO 8601 profile is not subject to any formal
requirements.
- See [ISO 8601 on Wikipedia https://en.wikipedia.org/wiki/ISO_8601) for
more information.
Tom: What would be put into ISO standard vs into DCMI Metadata Terms? Put it all into both? DCMI will have one page per term, with room for examples. On the other hand, we could take the position that if it is useful to have information like this in the ISO document (and I think it is - example of a range, etc) then it could be done as the ISO committee would like to see it done - as a comment plus examples - then we could leave it out of DCMI Metadata Terms but put it into the usage section for each per-term page.
Stefanie: I see problem if examples differ between ISO and DCMI Metadata Terms, because this is what will happen.
Tom: So you are in favor of keeping guidance out of both?
Stefanie: Prefer to have examples in DCMI Metadata Terms but not in ISO document, which would just link to the examples in DCMIMT.
Tom: If we decide we do not want to put examples into ISO document, then issues involving examples would all be affected.
Joachim: Not sure if the examples in the ISO document are so important. In the case of ISO 8601, it is the only authoritative source, but few people will refer to that, if they just want to look up something quickly. So they will look at what is easily accessible online. This is why I include Wikipedia entry in remarks - covers things not covered (eg, "partially unknown" dates). Since people normally do not have access to full ISO standard, this is helpful.
Karen: Including extensive examples in the actual standard may not -- Stefanie's remarks -- may not be a good idea. Good argument for having a best practices document. Understand desire to have something that includes examples, but good to keep separate from standard per se.
Tom: I meant that DCMIMT would remain much as today, but in addition for each property we would have a page for usage examples and possibly make that available for crowdsourcing, pull requests, etc. So you would be able to click on the property and see a web page for that property - section clearly demarcated below for "usage examples".
Karen: People still need an overall picture. Looking at things item by item may not give them that. The ISO standard should be minimal -- bare bones -- not giving advice on what to do because we may want to change the advice we give.
Tom: Does everyone agree to keep it minimal?
Osma: Would not remove them completely from ISO standard. The readers of ISO standard are different set of people from readers of dublincore.org. Should have enough info in the ISO standard, in hand, to be useful.
Tom: How much of the full proposal would you put in?
Osma: Not sure. But I do not think it is helpful to have policy of not having exampes.
Joachim: A problem, because our ISO standard will be published before the Date Time standard. So the values we can give are, particularly with approximate dates etc - we could update the example section, documented on Github or wherever - but this would not find its way back to printed ISO 15836.
Osma: Wouldn't worry too much about it. The ISO standard is a snapshot of DCMI terms. If then evolves, references to new standards and examples, then that's what's supposed to happen. ISO standards are renewed every five years or so - evolve, but more slowly. We can make best effort to make good definitions and examples. If we then want to change, we change - not a problem. Will eventually be out of date, but.
Tom: Stefanie, object? That we know it will go out of date.
Stefanie: Can live with that but not happy - end up with two versions of the same standard, but ok.
Joachim: I can turn this into a formal proposal and link to it for the vote. Question whether we should include uncertain and approximate values - tend to think we should leave them out because we do not know whether they will end up in the standard.
ACTION: Joachim to propose resolution to #16.
15: Comment for subproperties of Date - #15
Joachim: Just link to Date as a superproperty or repeat definition as it was given for the Date property? If in future we have separate page for each term, could include the examples. What is most useful to people?
Tom: Basic issue: whether to include more detailed examples for the subproperties. Overall, it is a short document. In the document, makes sense to me that we could put the examples under Date then refer back to them.
Osma: I like Antoine's proposal to add comment that Date is the superproperty. The vote in the issue tracker does not yet reflect this.
Joachim: We have not yet resolved whether to link to one page with full definition or examples or repeat on each subproperty. We should decide that beforehand.
Osma: Becoming clear that repeating everything doesn't make sense.
Stefanie: Better to have it in one place (Date), and to say that Date is the superproperty. And when they have to go back to Date, it reminds them of the connection, which is important.
Karen: The fact that it's long makes a difference at this point. If we have lengthy examples, may have to point elsewhere. Unfortunate, but if it is long, could be too much [to repeat it].
Joachim: Would change "Date" to "date". Would also update the title of the issue.
Tom: The name used in the URI is lowercase, but in DCMIMT, all properties have labels - e.g., "Date" - in uppercase.
Joachim: Date is not a class. So in the text, could use dct:date.
Tom: That would entail a number of related changes: "Examples of resources to which a Date Submitted...". Unless we think it is confusing people, suggest we continue doing it this way. Also, I do not think people would see "Date" in the example and assume it is referring to a class. Do not see this as cause for worry.
Joachim: In #15, should add "dates, times, and periods" so we have no difference. Also: special case of dateCopyrighted, which should not have the full range of possible Date Time expressions. Comment for that issue: in the text, only mentions year. Suppose it is a legal thing that copyright dates are years. Don't think we should, in this case, add anything else but years.
ACTION: Joachim to propose resolution to #15 (subproperties of Date).
8: Definition of dct:available #8
Tom: Seems pretty straightforward. Have had five up-votes, but discussion.
Karen: Issue is with the range. "An estimate, often a range" -- to me, it is not "often".
Tom: Current comment is flawed?
Karen: Never heard of it being a range - can anyone give examples? Can't be a range for when it became available. Examples?
Tom: Resource can be available for a range of time.
Karen: But text says become - fixed times, even if they are estimates.
Stefanie: Two problems: 1. Original definition is murky. 2. What ISO made of this is different from original: the estimate could be a range.
Tom: We have a bad definition?
Stefanie: Yes, but we should for now stay with bad definition and ignore the proposed change, because we'd have to change the definition. Not a good idea to change the definition.
Tom: Would be harder to discuss and approve a new definition. Would anyone be unhappy if we stay with current definition, even if flawed?
Karen: Agree with Stefanie - better than taking up a definition that is even more flawed.
Osma: Checked lodalot dataset to see what values used, this was used 2,000+ times and none were ranges. Saying "often a range" does not reflect reality.
Tom: What about dropping "often a range"?
Antoine: Reluctant to change semantics of something I do not understand. I cannot think of an example, but someone could.
Tom: Dropping "often a range" would not actually preclude using a range because we have defined the Date property to include ranges. If "often a range" makes no sense to us and we are not seeing it in the data, makes sense to me that we could take it out. Would not consider it to be a huge change. Would remove a potential source of confusion. But would not mean that it could not be used with a range.
Antoine: Because of natural semantics of word "date", implies point in time. Can think of an example of a range: review periods. A document was published to be reviewed, then replaced by something else. But comfortable, but agree.
Stefanie: Maybe we can change "often" to "sometimes".
Antoine: Would prefer this.
ACTION: Tom to propose "date, sometimes a range".
37: Where to put the examples - #37)
Tom: Can we close this? Can the examples for Date serve as a template for how to handle these?
33: Example for class dct:Standard - #33
Tom: Remaining: five issues related to comments and three for examples:
- 20: Comment for dct:title #20
- 19: Comment for dct:mediator #19
- 17: Comment for dct:dateCopyrighted #17
- 14: Comment for dct:audience #14
- 10: Comment for dct:Frequency #10
17: Comment for dct:dateCopyrighted #17
Joachim: Let's look at 17: Comment for dct:dateCopyrighted #17.
Tom: I think you were proposing not to apply the note about "Date as superproperty", which is fine.
Karen: Are we sure that copyright dates are always a year, everywhere in the world. Haven't gone back and looked at WIPO stuff to see whether limited to year.
Tom: Problem here: ISO WG has suggested a text for "copyright" that is itself copyrighted.
Joachim: Should not refer to jurisdiction.
Tom: This seems like a minefield.
Karen: Just: "The date of copyright". You no longer need copyright notices - they were eliminated in the 1970s. So: "typically, a year".
Stefanie: We are talking about the date it became copyrighted.
Karen: For serials, it is a range. This is the only copyright property we have.
Antoine: Disagree with this ISO WG proposal. Second sentence is a minefield. And there is an ISO WG working on copyright -
Karen: Think we need to reject. But agree that comment should be different from other dates.
Stefanie: Keep as simple as it is.
[Broad agreement.]