Allow for @source attributions for both pbcoreDescription and descriptionType

[kvanmalssen]

As with title/titleType, one way to resolve this would be to create a separate descriptionType element, which could have it's own @source attribute. Another approach would be to include @source as part of descriptionTypeSourceVersionGroup. However, this attribute group already is quite long, and this solution wouldn't be in line with the principle of ensuring that all attributes refer to the value of the element

[awead]

So then you'll need to define an element for description:

<pbcoreDescription>
  <description>The text of the description</description>
  <descriptionType source="http://my.authority.orb/abstract>Abstract</descriptionType>
</pbcoreDescription>

Seems reasonable to me, except there are other attributes that do similar things. Would you be in favor of consistency and doing it across the board with the other elements as well?

Another point to raise is that this is a departure away from the current schema which puts additional information in attributes versus additional nested elements which you're advocating here. Other schemas use nested nodes in such a way, like MODS or VRA, and there's nothing right or wrong about it, I just think that distinction should be made more explicit in developing the new schema.

[kvanmalssen]

All good points. I think we should be sure that we are consistent for how we approach issues like this across the board (e.g. what we do for description/type should also apply to title/type), and also in how we define the use of attributes. I'm an advocate for maintaining the principle that all attribute values should qualify the element value. Right now this is not consistently applied, as these examples demonstrate. I would be in favor of solutions that take this approach rather than persist a mix of uses (attributes referring to other attributes in some cases, attributes referring to element values in others).

[awead]

:sunglasses:

[dmaccarn]

Well, if all agree that a description have a @source then we can just add the sourceVersionGroup attributes:

 <!-- the pbcore description - this element may occur as many times
                      as desired, however if it does occur, then a description tag is
                      required.  optionally, the description type may appear - but
                      it has a limited vocabulary -->
<xsd:element maxOccurs="unbounded" minOccurs="1" name="pbcoreDescription"
            type="descriptionStringType">
   <xsd:annotation>
      <xsd:documentation xml:lang="en">"The pbcoreDescription element uses free-form text
                  or a narrative to report general notes, abstracts, or summaries about the
                  intellectual content of a media item you are cataloging. The information may be in
                  the form of a paragraph giving an individual program description, anecdotal
                  interpretations, or brief content reviews. The description may also consist of
                  outlines, lists, bullet points, rundowns, edit decision lists, indexes, or tables
                  of content."</xsd:documentation>
   </xsd:annotation>
</xsd:element>
...
   <!-- descriptionStringType -->
   <xsd:complexType name="descriptionStringType">
      <xsd:annotation>
         <xsd:documentation>The descriptionType is a complex group of attributes that help define
            the description type, as well as allowing for descriptions of segments and relevant
            times."</xsd:documentation>
      </xsd:annotation>
      <xsd:simpleContent>
         <xsd:extension base="xsd:string">
            <xsd:attributeGroup ref="sourceVersionGroup"/>
            <xsd:attributeGroup ref="descriptionTypeSourceVersionGroup"/>
            <xsd:attributeGroup ref="segmentTypeSourceVersionGroup"/>
            <xsd:attributeGroup ref="startEndTimeGroup"/>
            <xsd:attribute name="annotation" type="xsd:string"/>
         </xsd:extension>
      </xsd:simpleContent>
   </xsd:complexType>

   <!-- sourceVersionGroup -->
   <xsd:attributeGroup name="sourceVersionGroup">
      <xsd:annotation>
         <xsd:documentation>"The grouping of attributes: source, reference, version and
            annotation."</xsd:documentation>
      </xsd:annotation>
      <xsd:attribute name="source" type="xsd:string" use="optional"/>
      <xsd:attribute name="ref" type="xsd:string"/>
      <xsd:attribute name="version" type="xsd:string"/>
      <xsd:attribute name="annotation" type="xsd:string"/>
   </xsd:attributeGroup>

   <!-- descriptionTypeSourceVersionGroup -->
   <xsd:attributeGroup name="descriptionTypeSourceVersionGroup">
      <xsd:annotation>
         <xsd:documentation>"This group is similar to sourceVersionGroup but description specific
            and with the addition of a descriptionType attribute."</xsd:documentation>
      </xsd:annotation>
      <xsd:attribute name="descriptionType" type="xsd:string"/>
      <xsd:attribute name="descriptionTypeSource" type="xsd:string"/>
      <xsd:attribute name="descriptionTypeRef" type="xsd:string"/>
      <xsd:attribute name="descriptionTypeVersion" type="xsd:string"/>
      <xsd:attribute name="descriptionTypeAnnotation" type="xsd:string"/>
   </xsd:attributeGroup>
...

[awead]

Seems like you're circling back to the discussion in #48 where you're trying to decide whether to use attributes to refine descriptions of elements, or use subelements. There's no right or wrong way. A general rule of thumb seems to be that attributes are used to define metadata about the element, and nested elements are for structural description, for example, the way instantiation is nested under document, or tracks are nested under instantiation. However, the current schema clearly uses subelements to reflect both metadata and structural description.

An interesting point raised here is that you might favor nested elements over attributes in order to aid in human-readability. Although, I strongly believe xml never was, and never should be, intended for human readability. :smile:

[AllisonAnn]

I like the idea of exploring the nested element/subelement idea where applicable. That way - we could strictly tie/link elements to each other that may each need SourceRefVersionAnnotation attributes, possibly in a much more straightforward and visual way. This would also accommodate the export/transfer of repeating sets of elements (with repeating sets of attributes/elements) from becoming confused in the XML document, in the browser, and/or by people in general.

[AllisonAnn]

Does this work for people - Upgrade all type attributes to nested elements, and add a note (or Annotation) element specific to that element.

pbcoreTitle example:

<xml>
<pbcoreTitle>
  <title>[Title]</title>
  <titleType source="" ref="" version="" annotation="">[Term]</titleType>
  <titleNote>[Notes]</titleNote>
</pbcoreTitle>
</xml>

Here is another example of using the nested elements, and including the source attribute for all of them. In this case, the source of the title might be the cataloguer, or, a published resource. Source for notes would probably be the cataloguer, or whomever supplied the note. I actually think source is overkill though - and that all this information could be put in the note field.

<xml>
<pbcoreTitle>
  <title source="">[Title]</title>
  <titleType source="" ref="" version="" annotation="">[Term]</titleType>
  <titleNote source="">[Notes]</titleNote>
</pbcoreTitle>
</xml>

[jackbrighton]

I think the point about attributes always referring to the value of any given element or subelement is the key. If we can do away with subelements, great, but if they are needed that's fine, just keep them to a minimum. For pbcoreTitle and pbcoreDescription, subelements are probably needed for titleType and descriptionType. Each of these would get the same optional source/ref/version/annotation attributes, which would always refer to the value of the subelements.