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 notifications@github.com 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 https://github.com/dcmi/usage/issues/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] https://github.com/dcmi/usage/issues/27#issuecomment-394979379 [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] https://github.com/dcmi/usage/issues/28#issuecomment-406493908

[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]