Thank you so much, Tom, for your phantastic work sorting out all these issues!
Cheers, Joachim
> -----Ursprüngliche Nachricht-----
> Von: DCMI Usage Board [mailto:[log in to unmask]] Im Auftrag von
> Thomas Baker
> Gesendet: Freitag, 20. Juli 2018 08:11
> An: [log in to unmask]
> Betreff: [DCUB] Status of all issues related to ranges
>
> Dear all,
>
> This review covers all remaining issues related to ISO 15836 that I see:
>
> Key issue with multiple dimensions:
> -- 43. Coining and applying dcam:rangeIncludes
>
> Almost done? Just vote.
> -- 22. Comment and examples for dct:language
> -- 23. Literal example for dct:coverage
> -- 30. Literal value for dct:rights
> -- 42. What should metadata creators do when...
>
> Nearing completion?
> -- 25. Comments for dct:creator
> -- 26. Literal comments for dct:format
> -- 29. Pointer to User Guide in dct:relation
>
> More work/discussion required?
> -- 28. Definition of dct:related
> -- 31. Comment for dct:rightsHolder
>
> Tom
>
> ----------------------------------------------------------------------
> 43. Coining and applying dcam:rangeIncludes
>
> Issue 32: "Broken ranges? [3] and "Issue 42: Recommended practice, when
> non-literal values are not available" [5] generated some great discussion,
> covering among other things the history of how `rdfs:domain` and
> `rdfs:range` ended up being defined as they currently are. The issue was
> also discussed in the June 26 telecon. It looks like we have converged on
> the following approach:
>
> * Coin `http://purl.org/dc/dcam/rangeIncludes`, e.g., as defined in the
> current ISO draft:
>
> Class of which a value described by the term may be an instance.
>
> * Coin `http://purl.org/dc/dcam/domainIncludes`:
>
> Class of which a resource described by the term may be an instance.
>
> * Substitute `dcam:rangeIncludes` for `rdfs:range` (and
> `dcam:domainIncludes` for `rdfs:domain`) for all properties _except for_
> properties with a range of `rdfs:Literal` (which will continued to use
> `rdfs:range`).
>
> Note that the definition of `dcam:rangeIncludes` proposed here is only
> slightly different from that of `rdfs:range` ("class of which a valued
> described by the term _is_ an instance"). For comparison, see the
> Schema.org definitions [1,2].
>
> Note that the definitions of rangeIncludes and domainIncludes would be
> included in ISO 15836, but as part of Section 3.1 ("Terms and
> definitions"), where they would be defined in words only (i.e., no URI),
> and not in Section 3.3 ("DCMI properties"), which lists properties of the
> /terms/ namespace with their URIs.
>
> I have created a new issue (https://github.com/dcmi/usage/issues/43) in
> which I split the problem into several aspects:
>
> * changing rdfs:range into rangeIncludes for properties that use non-literal
> values
> * not changing rdfs:range rdfs:Literal
> * definition of rangeIncludes based on current DCMIMT and ISO draft
> * definition of rangeIncludes based on Schema.org
> * definition of range used in current DCMIMT and ISO draft
>
> [1] https://meta.schema.org/rangeIncludes
> [2] https://meta.schema.org/domainIncludes
> [3] https://github.com/dcmi/usage/issues/32
> [4] https://github.com/dcmi/usage/blob/master/minutes/2018/2018-06-
> 26.dcub-telecon-minutes.md
> [5] https://github.com/dcmi/usage/issues/42
>
> ----------------------------------------------------------------------
> 22. Comment and examples for dct:language - the ISO draft currently says:
>
> Note 1 to entry: Recommended practice is to use either a non-literal value
> representing a language from a controlled vocabulary such as ISO 639-2 or
> ISO
> 639-3, or a literal value consisting of an IETF Best Current Practice
> 47 [BCP 47] language tag.
>
> EXAMPLES http://id.loc.gov/vocabulary/iso639-2/eng
> (English language in the Library of Congress vocabulary of ISO
> 639-2 languages)
> http://iso639-3.sil.org/code/eng
> (English language in the SIL International vocabulary of ISO
> 639-3 languages)
> en-US (BCP 47 tag for American English)
> zh-Hant-HK (BCP 47 tag for Hong Kong Chinese in Traditional script)
> http://catalogue.bnf.fr/ark:/12148/cb119308987 (English language
> in Rameau)
>
> This follows Osma's proposal, which has been upvoted by Osma, Tom, Karen,
> and Antoine.
> A few more votes are needed for approval - see
> https://github.com/dcmi/usage/issues/22#issuecomment-406253315
>
> ----------------------------------------------------------------------
> 23. Literal example for dct:coverage
>
> Proposed:
>
> EXAMPLES 1700/1799
> Boston, MA
>
> Please vote/comment at:
> https://github.com/dcmi/usage/issues/23#issuecomment-406355149
>
> ----------------------------------------------------------------------
> 25. Comments for dct:creator
>
> The current ISO draft has the following comment for dct:creator:
>
> Recommended practice is to refer to the creator with an URI. If no
> such URI is available, it is acceptable to refer to the creator with a
> literal, such as a name or label of the creator which indicates the
> entity. Literals for personal names should be listed surname or family
> name first, followed by forename or given name. When in doubt, give the
> name as it appears, and do not invert.
>
> Please comment/vote, bearing in mind Joachim's preference not to
> encourage
> the use of literals with `dct:creator`, but rather to point users with literals to
> `http://purl.org/dc/elements/1.1/creator`.
>
> Comment/vote at
> https://github.com/dcmi/usage/issues/25#issuecomment-406359726
>
> ----------------------------------------------------------------------
> 26. Literal comments for dct:format
>
> The current ISO draft reads:
>
> Note 1 to entry: Examples of dimensions include size and duration.
>
> Note 2 to entry: Recommended practice is to use a controlled
> vocabulary
> such as the list of Internet Media Types [MIME].
>
> EXAMPLES text/xml
> 4 kB
> 40 x 512 pixels
> 22 in.
>
> Please note @rguenther52 comment that the PREMIS ontology is removing
> the
> assertion that premis:hasMedium is a subproperty of dcterms:medium. See:
> https://github.com/PREMIS-OWL-Revision-Team/revise-premis-
> owl/issues/60
>
> Comment/vote at
> https://github.com/dcmi/usage/issues/26#issuecomment-406362768
>
> ----------------------------------------------------------------------
> 28. Definition of dct:related
>
> DCMI Metadata Terms defines both dce:relation and dct:relation
> with the following definition and comment:
>
> A related resource.
>
> Recommended best practice is to identify the related resource by means
> of a string conforming to a formal identification system.
>
> The current ISO draft proposes a different definition, a slightly different
> comment, and a second comment:
>
> A reference to a related resource.
>
> Best practice is to identify the related resource by means of an URI or
> a string conforming to a formal identification system.
>
> Dublin Core Usage guide contains more information about various
> relations and how they should be encoded.
>
> In https://github.com/dcmi/usage/issues/28, I split out three separate
> issues:
> -- Definition of dct:relation
> -- Comment on "recommended practice"
>
> ----------------------------------------------------------------------
> 29. Pointer to User Guide in dct:relation
>
> I had closed this issue because the latest ISO draft removed the examples.
> However, I then noticed a second comment that had previously escaped my
> attention:
>
> Note 2 to entry: Dublin Core Usage guide contains more information
> about various relations and how they should be encoded.
>
> This points to the old User Guide [1], which was superseded 2005.
>
> I suggest we either drop the comment (and reference) entirely - or point to
> the 2011 User Guide, which Paul and I will soon copy to a more citable
> location.
>
> [1] http://www.dublincore.org/documents/usageguide/elements/
> [2] http://wiki.dublincore.org/index.php/User_Guide/Creating_Metadata
>
> Comment/vote at
> https://github.com/dcmi/usage/issues/29#issuecomment-406318810
>
> ----------------------------------------------------------------------
> 30. Literal value for dct:rights
>
> The latest iteration of the ISO draft adds a second comment for
> dct:rights which, when slightly edited to match the DCMIMT style,
> reads:
>
> Note 2 to entry: Recommended practice is to refer to a rights
> statement with a URI. If this is not possible or feasible,
> a short textual description of rights may be provided.
>
> Please comment/vote at:
> https://github.com/dcmi/usage/issues/30#issuecomment-406321858
>
> ----------------------------------------------------------------------
> 31. Comment for dct:rightsHolder
>
> There are several proposed wordings in this thread, so I cannot with
> confidence make a counter-proposal. I suggest we take the (slightly
> edited) text of the current ISO draft as a starting point:
>
> Note 1 to entry: Recommended practice is to refer to the rights holder
> with a name or URI.
>
> Note:
> * in other issues, we have rejected the notion that a literal and a URI be
> used in a single value
> * Juha, Karen, and Osma seem to be saying that if the value is a literal,
> it should not be limited to the name of the rights holder because RFC
> 3986 covers things like email addresses and telephone numbers.
>
> @aisaac Would you like to make a new proposal?
>
> Follow the thread at
> https://github.com/dcmi/usage/issues/31#issuecomment-406339352
>
> ----------------------------------------------------------------------
> 42. What should metadata creators do when a property has a non-literal range
> and
> they have only literals?
>
> It looks to me like a rough consensus has emerged:
>
> * We recommend URIs as the first option and provide examples.
> * In general, we allow (though not encourage) the use
> of literal values.
> * In the ISO standard, where needed, we provide usage recommendations,
> especially to address common problems (e.g., "CC-BY" for Rights, "French"
> for Language).
> * In the non-normative Annex B to ISO 15836-2, page 27, we add a
> paragraph
> or two briefly outlining the options for using literals with properties
> with non-literal ranges -- directly as the object, with blank nodes, with
> hash URIs -- and characterize the advantages and disadvantages of each
> approach.
> * In our message to the world about the outcome of this whole batch of
> ISO-related decisions, we acknowledge, in addition to the above, that it
> would not actually be incorrect to use `/elements/1.1/` properties but
> that using just one namespace keeps down the complexity of the data
> model
> and of queries.
>
> Do you agree? Comment/vote at
> https://github.com/dcmi/usage/issues/42#issuecomment-405961529
>
>
> --
> 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
########################################################################
To unsubscribe from the DC-USAGE list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=DC-USAGE&A=1
|
