APPROVED: Comments for Accrual properties

[tombaker]

PLEASE VOTE WITH THUMBS-UP/DOWN

See note_accrualX.md.

Note:

• Supersedes closed issues #11, #12, #13.
• Revised comment avoids "recommending" a particular vocabulary as per Makx's comment.
• Drops ISO-WG-proposed suggestion that "Where multiple policies apply, a separate statement should be used for each policy."

Issues:

• Do we want to recommend use of a controlled vocabulary (as for many other existing properties)?
• Do we want to call out these particular vocabularies, published by DCMI?

---

Add comment for http://purl.org/dc/terms/accrualMethod:

Recommended practice is to use a value from a controlled vocabulary such as
the Dublin Core Collection Description Accrual Method Vocabulary [1].  

[1] http://dublincore.org/groups/collections/accrual-method/

Add comment for property http://purl.org/dc/terms/accrualPeriodicity:

Recommended practice is to use a value from a controlled vocabulary such as
the Dublin Core Collection Description Frequency Vocabulary [1].

[1] http://dublincore.org/groups/collections/frequency/

Add comment for property http://purl.org/dc/terms/accrualPolicy:

Recommended practice is to use a value from a controlled vocabulary such as
the Dublin Core Collection Description Accrual Policy Vocabulary [1].

[1] http://dublincore.org/groups/collections/accrual-policy/

[aisaac]

I am split about dropping ISO-WG-proposed suggestion that "Where multiple policies apply, a separate statement should be used for each policy." This seems like a good metadata principle in general, not something that should be left to user guides as hinted in #11. Actually I think it's bad if a user guide would recommend to stack several individual policies in one statement. This said, I believe that we should have this as a general principle not only for accrualMethod. For example we don't want several creators to be stacked in one creator statement either. But I'm not in favour of adding such sentence for every DCMI term...

Otherwise I agree with the rest of the proposals. So since I'm split on the case of the note, I'm going to vote thumb-up but would be curious to hear what others think.

[tombaker]

@aisaac The draft ISO 15836-2, page 27 (password-protected), has an informative Annex B: "Dublin Core metadata as linked data". In its current form, this one-page annex talks only about URIs and their use in Linked Data. However, this section could potentially be extended with any other guidance we might want to provide (e.g., something that starts with "Linked Data is expressed in the form of statements, where each statement has just one value...").

Since Annex B is non-normative, we could propose such a change later in the ISO process than changes to the normative parts.

[larsgsvensson]

But if dct:accrualPolicy is only intended to work with "non-literal values" as specified in the DC Usage Guide it's not possible to have more than one policy per statment. So I'd say (and so does @sarahartmann) that this is a non-issue since it's only concerned with the case that someone uses dct:accrualPolicy with a literal value.

[tombaker]

@aisaac We could add a sentence to the ISO 15836-2 non-normative Annex B, page 27 (password protected) to the effect that Linked Data is expressed in statements that have one value per statement (or words to that effect). Since Annex B is non-normative, we could even add this relatively late in the process. The section currently talks only about the use of URIs in Linked Data but the title ("Dublin Core metadata as linked data") leaves room for discussing this and any other general issues we might want to highlight.

[aisaac]

@tombaker this seems a good idea. But I would make it even more general than Linked Data. As @larsgsvensson said for Linked Data contexts we should be relatively safe. What worries me is other contexts (and these 'rogue' Linked Data cases that won't use non-literal values ;-) ).

[tombaker]

APPROVED

See note_accrualX.md

ACTION:

• TC46 office edit ISO 15836-2.
• Tom edit DCMI Metadata Terms.

[aisaac]

I've created a new issue (#35 ) to keep a trace of the idea of adding recommendation on the granularity of value, which we raised towards the end of this issue.

[tombaker]

@aisaac Thanks :-)

[juhahakala]

I have added sentence "Note that linked data is expressed in statements that have one and only one value per statement." to Annex B.

[aisaac]

@juhahakala is this about #35 ? I'm lost.