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
|
