OPC Core Properties -- WAS: My latest draft of OPC

Thu Feb 23 13:46:56 CET 2017

Murata-san,

Thank you for generating a complete draft of this clause.  It is much
easier to evaluate when you can see it all together.  This set of
comments is from a straightforward read through your latest draft.  In
general, this seems considerably more readable than the previous
version I looked at.  Before the face-to-face, I plan to compare the
draft directly to the 2012 version.

    Hoping this helps.   Caroline

=====
Table 1.1
  Need to standardize on whether the Description entries end with
period or not.  If it would be permitted under ISO rules, I would like
the group to consider whether putting links to the DC elements into
the table makes sense.  An example is http://purl.org/dc/terms/subject

1.2   2nd para is missing closing period.

1.3.1 Last para.  Missing comma after version.   I would replace
"Here" by "In this example,".

1.3.3 Second para.  Says it's a note, but doesn't have [].  I'm not
sure why it should be a note.  Why not just add the sentence about the
namespace to the end of the first paragraph.

1.3.3. Third para.  For consistency, use "This standard" in place of
"This document."   "Neither" doesn't work with more than one item.

I suggest:
  In this standard, these elements shall not have child elements and
shall not have xsi:type or xml:lang attributes.

1.3.3.  Example numbering -- with one example referring immediately to
another is confusing.  This happens in several places.  One way to
address might be to invert the sentence, as in:
Four elements from Dublin Core Metadata Element Set, Version 1.1 are
in Example 10-1.

1.3.4   2nd para. Here the note does have enclosing [].  Again, I
wonder whether the sentence could not be combined with the previous
paragraph.

1.3.4   3rd para.  Again, I would use "standard" rather than
"document".  To match my suggestion for 1.3.3.
I suggest:
  In this standard, these elements shall not have child elements and
shall not have xml:lang attributes.

1.3.4.  Example numbering -- with one example referring immediately to
another is confusing.

1.3.5.  I would use "Standard" or "Specification" rather than
"Document" in the heading.

1.3.5   4th para.  typo in "xsd;string"  here and repeatedly in
following subclauses

1.3.5.3  2nd para.  "xm:lang" should be "xml:lang"  -- this typo is
also present more than once.
To me, the second sentence is awkward, although I realize that it is
lifted straight from Table 1 in the 2012 version.  If the only aspect
of a keyword that can be "flagged" is its language, I think that
should be made clear.

1.3.5.4 1st para.  I would use "keyword for the" rather than "keyword of the"

1.3.5.6  3rd para.  "xsd;dateTime" should be "xsd:dateTime"
I would like to see an example with time as well as date.

1.4
I would like to see a reference to the extensibility TR and have the
TR in a bibliography.

=====

I have one comment that does not relate to your changes.

 The value given for dc:subject in the examples is
  <dc:subject>Spec defines the schema for OPC Core Properties and
their location within the package</dc:subject>
This is not consistent with the intent of the element's usage in
Dublin Core.  See
http://dublincore.org/documents/dcmi-terms/#terms-subject

In Dublin Core -- dc:subject is, to quote, is typically "represented
using keywords, key phrases, or classification codes. Recommended best
practice is to use a controlled vocabulary."  In Dublin Core, although
not in OPC, all elements are repeatable.  The usual practice for
dc:subject is to have repeated elements, each with a term from a
controlled vocabulary.  The content of dc:subject in the OPC examples
is more consistent with the definition of dc:description.

I recommend changing the examples to use
  <dc:description>Spec defines the schema for OPC Core Properties and
their location within the package</dc:description>

=====

On Wed, Feb 1, 2017 at 3:29 AM, MURATA Makoto <eb2m-mrt at asahi-net.or.jp> wrote:
> Caroline,
>
> I think that the existing clause of core properties is short
> of providing normative definitions.  For example, the existing
> table of core properties does not make clear that the creator
> element can have no child elements.  Where is this requirement
> specified?  It is in "11.4 Schema Restrictions for Core
> Properties".  The same applies to the xml:lang attribute.  It
> is allowed only for the keywords element and the value
> element, but this requirement is shown in "11.4 Schema
> Restrictions for Core Properties" only.  I don' think that
> this is the right approach.
>
> Here is my proposed rewrite of this entire clause.
>
> https://1drv.ms/w/s!An5Z79wj5AZBgetAeukVNMdev5h9bA
>
> Regards,
> Makoto
>
>
>
> 2017-01-26 22:43 GMT+09:00 caroline arms <caroline.arms at gmail.com>:
>>
>> Murata-san,
>>
>> Thank you for clarifying that your intention was to retain the table
>> at the beginning of the Core Properties clause.  That had not been
>> clear to me.
>>
>> I would like to echo a comment made by Rex on yesterday's call that
>> Part 2 is so different from Parts 1 and 4 that it doesn't seem
>> necessary to follow the patterns established there in detail.  To me,
>> what matters is whether the clause is easy to understand.
>>
>> My concern is that following the shape of your suggestion here will
>> make the Core Properties clause much more awkward to read than it need
>> be and than it is now.  For example, for the element "identifier" you
>> would need to look at the table to understand its semantics, to
>> http://purl.org/dc/elements/1.1/identifier to see what Dublin Core
>> actually defines it as (which your increased emphasis on the fact that
>> it is borrowed from Dublin Core seems to require), and to the schema
>> in our Annex to find that it is optional (although your suggested
>> re-write doesn't point there for the borrowed elements).
>>
>> This all seems unnecessarily complex for elements that are almost all
>> of type xsd:string (or the equivalent SimpleLiteral from the Dublin
>> Core schemas our schema incorporates) and optional, and must not have
>> the xml:lang attribute.
>>
>> And for dcterms:created and dcterms:modified, we also need to look at
>> 10.5 Schema restrictions for Core Properties
>>
>> This morning I have not come to a conclusion as to how I would try to
>> address your concerns about missing information without making the
>> clause more cumbersome, but I'd like to encourage you to include the
>> whole clause in your next re-write suggestion to make it easier to
>> review.
>>
>> I need to turn to other matters now.
>>
>>    Thanks.  Caroline
>>
>> [Aside: The fact that our schema refers to
>> http://dublincore.org/schemas/xmls/qdc/2003/04/02/dc.xsd and
>> http://dublincore.org/schemas/xmls/qdc/2003/04/02/dcterms.xsd  for
>> typing is a complication we can't avoid.  I'm not sure I had looked at
>> those since they were first put together and it was strange to see the
>> names of good friends as the authors!]
>>
>>
>>
>>
>>
>> On Mon, Jan 23, 2017 at 10:03 AM, MURATA Makoto
>> <eb2m-mrt at asahi-net.or.jp> wrote:
>> > Dear colleagues,
>> >
>> > Attached please find my latest draft.  Carolline and Francis
>> > significantly
>> > contributed to it.  Recent changes relate to relationships parts.
>> >
>> > https://1drv.ms/f/s!An5Z79wj5AZBges7CzR1SJWYniS-Yg
>> >
>> > Long time ago, I proposed a rewrite [1] of OPC core properties.  Since
>> > WG4
>> > has
>> > not discussed it yet, I did not incorporate it into this rewrite.
>> >
>> > [1] http://mailman.vse.cz/pipermail/sc34wg4/2016-August/003941.html
>> >
>> >
>> > Regards,
>> > Makoto
>
>
>
>
> --
>
> Praying for the victims of the Japan Tohoku earthquake
>
> Makoto