## DCMI Usage Board - Telecon 2018-06-27 Wednesday - minutes
* 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
### dct:date (Joachim)
#### 16: Comments for dct:date - https://github.com/dcmi/usage/issues/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 - https://github.com/dcmi/usage/issues/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).
### Definitions
#### 8: Definition of dct:available https://github.com/dcmi/usage/issues/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".
## Examples
37: Where to put the examples - https://github.com/dcmi/usage/issues/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 - https://github.com/dcmi/usage/issues/33
__Tom__: Remaining: five issues related to comments and three for examples:
* 20: Comment for dct:title https://github.com/dcmi/usage/issues/20
* 19: Comment for dct:mediator https://github.com/dcmi/usage/issues/19
* 17: Comment for dct:dateCopyrighted https://github.com/dcmi/usage/issues/17
* 14: Comment for dct:audience https://github.com/dcmi/usage/issues/14
* 10: Comment for dct:Frequency https://github.com/dcmi/usage/issues/10
__Joachim__: Let's look at 17: Comment for dct:dateCopyrighted
https://github.com/dcmi/usage/issues/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.]
--
Tom Baker <[log in to unmask]>
########################################################################
To unsubscribe from the DC-USAGE list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=DC-USAGE&A=1
|
