dc/dcterms: source

[tombaker]

EDITED

• dc11:source (through 2019)

  Comment reads: "The described resource may be derived
  from the related resource in whole or in part.
  Recommended best practice is to identify the related
  resource by means of a string conforming to a formal
  identification system."

• dcterms:source (ISO 15836-2 / DCMIMT 2020)

  Comment reads: "This property is intended to be used
  with non-literal values."

CHANGING NOW (unless I hear objections!)

• dc11:source (DCMIMT 2020)

  No changes.

PROPOSING FOR FUTURE (to be voted)

• dc11:source

  Declare equivalent to dcterms:

  Change comment as per dcterms:

[kcoyle]

I like the dc11 definition better. Also, I don't see where we decided to change the definition of the dcterms:source. I tried a search on the closed issues and don't see it.

[tombaker]

I like the dc11 definition better.

(Note that this is a usage comment, not a definition.) I have reverted the comment in dc11.

Also, I don't see where we decided to change the definition of the

dcterms:source. I tried a search on the closed issues and don't see it. Thanks - I will double-check this too (I will look at past ISO drafts to see when this appeared). I checked to make sure our decisions were reflected in ISO 15836-2 but did not check that everything in ISO was reflected in the decisions. We have already found one instance where the record does not support a text (I don't recall which one, off-hand); maybe that is the case here too.

…

On Thu, Jan 16, 2020 at 4:00 PM Karen Coyle ***@***.***> wrote: I like the dc11 definition better. Also, I don't see where we decided to change the definition of the dcterms:source. I tried a search on the closed issues and don't see it. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#94?email_source=notifications&email_token=AAIOBJS76MAFG5CWGXD7ZADQ6BZBRA5CNFSM4KHBSUU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJELPOY#issuecomment-575190971>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIOBJTJ4A77F4INTNWDYVDQ6BZBRANCNFSM4KHBSUUQ> .

[tombaker]

In DCMIMT of 2012-06-14, which is still the "latest
version" on the DCMI website, the usage comment for
dcterms:source reads [1]:

The described resource may be derived from the
related resource in whole or in part. Recommended
best practice is to identify the related resource by
means of a string conforming to a formal
identification system.

In addition, the description of dcterms:source in the RDF
schema of 2012-06-14 has a skos:note that reads [2]:

This term is intended to be used with non-literal
values as defined in the DCMI Abstract Model
(http://dublincore.org/documents/abstract-model/).
As of December 2007, the DCMI Usage Board is seeking
a way to express this intention with a formal range
declaration.

Indeed, this comment had become a source of embarrassment.

Thanks to the Wayback Machine, I see that the note
disappeared from the DCMI Metadata Terms web page between
2019-03-07 [3] and 2019-03-21 [4], which is when we
started using
http://www.dublincore.org/specifications/dublin-core/dcmi-terms/
as the address for DCMIMT (the address
http://dublincore.org/documents/dcmi-terms/ is now an
alias and still resolves).

In the meantime, on 2018-06-06, we had unanimously
approved a resolution [6] to replace the old text with:

This property is intended to be used with non-literal
values.

At the time, I neglected to transcribe this decision to
the decision record on Github but have now rectified this
omission [7].

As of 2018-06-04, the "Note 1 to entry:" for
dcterms:source in the ISO draft read:

Best practice is to identify the related resource by
means of a URI or a string conforming to a formal
identification system.

This text raises two issues:

1. What happened to the following text?

   The described resource may be derived from the
   related resource in whole or in part.

The answer, I find, is that the sentence went missing in
a very early draft of ISO 15836-2. I pointed out this
omission in an email to the ISO draft editors on
2017-03-07, but unfortunately I neglected to follow up
and verify that the text was restored, so it remained
missing.

2. Where did the words "a URI or" come from?

The answer, I find, is that the editor of the ISO draft
proposed the additional words for inclusion in the usage
comment for dcterms:relation and we unanimously approved
this change on 2018-06-20 [9]. We approved this change
specifically for dcterms:relation, not for
dcterms:source, but since dcterms:source is a
sub-property of dct:relation, the change was applied to
dcterms:source in the ISO draft as well.

The ISO draft of 2018-07-11 [8] shows that a new
"Note 1 to entry:" was added to the fifteen
properties, such as hasFormat, subject, references,
relation... and source.

For fourteen of the fifteen properties, the new "Note 1
to entry:" was added to the existing usage comment, which
became "Note 2 to entry:".

For dcterms:source, however, the existing comment was
deleted, so that the term description now had just one
"Note 1 to entry:".

AFAICT, we never decided to delete the existing comment,
so I consider this omission to be a simple error. I have
restored the comment in its current form, with the
additional words "a URI or", plus the additional sentence
about "intended to be used with non-literal values". In
DCMIMT, we do not split comments into separate "Note x to
entry" sections, so the comment for dcterms:source now
reads, for publication on Monday:

This property is intended to be used with non-literal
values.  The described resource may be derived from
the related resource in whole or in part.  Best
practice is to identify the related resource by means
of a URI or a string conforming to a formal
identification system.

Thank you, Karen, for drawing attention to this problem.

One takeaway for me, having just spent alot of time
reconstructing the situation, is that every decision
taken in a Github issue, however minor (within reason),
should be transcribed into a decision document in the
'minutes' tree on Github.

[1] https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#terms-source
[2] https://www.dublincore.org/2012/06/14/dcterms.ttl
[3] https://web.archive.org/web/20180615154517/http://dublincore.org/documents/dcmi-terms/#terms-source
[4] https://web.archive.org/web/20190307110144/http://dublincore.org/documents/dcmi-terms/#terms-source - March 7
[5] https://web.archive.org/web/20190321010804/http://www.dublincore.org/specifications/dublin-core/dcmi-terms/#terms-source
[6] #27 (comment)
[7] https://github.com/dcmi/usage/blob/master/minutes/2018/2018-06-03.dcub-decisions.md
[8] https://github.com/dcmi/iso15836-2/blob/master/drafts/superseded/ISO_CD_15836-2_2018-07-11.pdf
[9] #28 (comment)

[aisaac]

I can live with publishing the new suggested note (with all the discussed "components"). But actually I would be happier if we could avoid "Best practice is to identify the related resource by means
of a URI or a string conforming to a formal identification system.". This sounds a bit at odds with "This property is intended to be used with non-literal values."

As a matter of fact I think I do not like the idea of propagating usage notes from a super-property to a sub-property. Sure, the semantics of super-properties should still apply to sub-properties. But in general I expect sub-properties will somehow refine the semantics of the super-property, so it seems unhelpful to re-stick the general notes right next to the generic ones.
Had we decided somewhere that we wanted to enforce this propagation in our notes? Do we do it for other properties than dcterms:source?

[kcoyle]

I agree with @aisaac that we need to give ourselves a task of looking again at the subclass relationships and the definitions of terms. When we were going over the ISO document it was kind of piecemeal and I admit that I didn't think hard about how it all fit together. I would like the 1.1 values to be as wide open as possible, consistent with their historical usage as essentially key/value pairs. (I guess they'd be owl:AnnotationProperty's) So we need to adjust the definitions and comments to fit this.

[Flaminggay]

EDITED

• dc11:source (through 2019)
  Comment reads: "The described resource may be derived
  from the related resource in whole or in part.
  Recommended best practice is to identify the related
  resource by means of a string conforming to a formal
  identification system."
• dcterms:source (ISO 15836-2 / DCMIMT 2020)
  Comment reads: "This property is intended to be used
  with non-literal values."

CHANGING NOW (unless I hear objections!)

• dc11:source (DCMIMT 2020)
  No changes.

PROPOSING FOR FUTURE (to be voted)

• dc11:source
  Declare equivalent to dcterms:
  Change comment as per dcterms:

{{Supplement}}

[Flaminggay]

Ф

[Flaminggay]

https://support.google.com/My-Ad-Center-Help/answer/12155656#personalized-ads-on-google&non-personalized-ads-on-google

[Flaminggay]

[endpoint][endpoint]