search

WGBH / PBCore2.0

Public Broadcasting Metadata Dictionary Project
http://www.pbcore.org
32 stars 9 forks source link

Expanding pbcoreRelation to include </pbcoreRelationDescription> #60

Open caseyedavis12 opened 10 years ago

caseyedavis12 commented 10 years ago

I think that it would be useful to have a pbcoreRelationDescription element so that pbcore users can provide contextual information about how items are related.

The pbcoreRelation container element contains two elements: pbcoreRelationType and pbcoreRelationIdentifier. pbcoreRelationType identifies the type of intellectual content bond between a media item you are cataloging and some other related media item, such as "is clone of", "references", or "is required by."

I do not think that the pbcoreRelationType controlled vocabulary provides enough contextual information about the relationship between the media items.

Also, what if a PBCore user would like to include metadata about related materials that are not a single media item, such as an archival collection at the Wisconsin Historical Society, ancillary materials at University of Maryland's National Public Broadcasting Archives, etc.? I do not think that the current element allows for rich description of related materials.

AllisonAnn commented 10 years ago

I agree - I think that most pbcore elements could use a note field, not embedded as an attribute, but as a nested sibling element, sort of like this:

Element (pbcoreRelation) ElementType (pbcoreReleationType) ElementNote (pbcoreRelationNote)

Each sibling element could then have the ability of containing source, ref, version, annotation attributes.

caseyedavis12 commented 10 years ago

I also agree that most PBCore elements could use a note element as opposed to an attribute.

Can someone clarify the difference in the the intended value of the current @annotation attribute and the value of a proposed nested element?

Thank you, Casey

From: AllisonAnn notifications@github.com<mailto:notifications@github.com> Reply-To: "WGBH/PBCore2.0" reply@reply.github.com<mailto:reply@reply.github.com> Date: Friday, August 1, 2014 1:17 PM To: "WGBH/PBCore2.0" PBCore2.0@noreply.github.com<mailto:PBCore2.0@noreply.github.com> Cc: Casey Davis casey_davis@wgbh.org<mailto:casey_davis@wgbh.org> Subject: Re: [PBCore2.0] Expanding pbcoreRelation to include (#60)

I agree - I think that most pbcore elements could use a note field, not embedded as an attribute, but as a nested sibling element, sort of like this:

Element (pbcoreRelation) ElementType (pbcoreReleationType) ElementNote (pbcoreRelationNote)

Each sibling element could then have the ability of containing source, ref, version, annotation attributes.

— Reply to this email directly or view it on GitHubhttps://github.com/WGBH/PBCore2.0/issues/60#issuecomment-50910674.

awead commented 10 years ago

I feel I should interject a word of caution here. Adding a "note" sub-element to every element in the schema would make things very complex. Attributes generally should inform the element, and sub-elements should reflect the structure of parent element. However, there is the tendency in a lot of xml schemas where sub-elements actually assert qualifications or clarifications to a parent element.

There's nothing wrong about this, but it leads to certain computational gymnastics when it comes to figuring out which element is which. For example:

<greeting note="English">Hello</greeting>
<greeting note="German">Guten tag</greenting>

Is simpler than

<greeting>
  <message>Hello</message>
  <language>English</language>
</greeting>
<greeting>
  <message>Guten tag</message>
  <language>German</language>
</greeting>

Furthermore, it's a lot easier to find the German greeting in the former example. In the latter, I would have to search through every greeting element and look for a sub-element matching "German" and then grab the text from the sibling element... this is complicated. Whereas in the first example, just give me the text in the element where the attribute is "German", is much easier.

Granted, there are cases where you have to do such things, but I would only do it when the structure of the concept/idea that the element expresses merits it.

Regarding relations, you could do:

<pbcoreRelation src="Dublin Core" ref="http://dublincore.org/documents/2012/06/14/dcmi-terms/#terms-isPartOf" annotation="isPartOf">
  <pbcoreIdentifier>x</pbcoreIdentifier>
  etc...
</pbcoreRelation>
AllisonAnn commented 10 years ago

Hi Casey -

This is how I distinguish between @annotation (attribute) vs. [element]Note

I think that the @annotation should be about clarifying the element, mainly its definition or usage, and not be used for additional information / clarification about the asset itself - use a Note element. Not sure that helps...but, I just found this on the web about when to use an attribute, and when to use an element. I think it helps explain my own preference for using one over the over.

http://www.xmlfiles.com/xml/xml_attributes.asp

On Fri, Aug 1, 2014 at 1:37 PM, American Archive of Public Broadcasting < notifications@github.com> wrote:

I also agree that most PBCore elements could use a note element as opposed to an attribute.

Can someone clarify the difference in the the intended value of the current @annotation attribute and the value of a proposed nested element?

Thank you, Casey

From: AllisonAnn notifications@github.com<mailto:notifications@github.com>

Reply-To: "WGBH/PBCore2.0" <reply@reply.github.com<mailto: reply@reply.github.com>> Date: Friday, August 1, 2014 1:17 PM To: "WGBH/PBCore2.0" <PBCore2.0@noreply.github.com<mailto: PBCore2.0@noreply.github.com>> Cc: Casey Davis casey_davis@wgbh.org<mailto:casey_davis@wgbh.org> Subject: Re: [PBCore2.0] Expanding pbcoreRelation to include (#60)

I agree - I think that most pbcore elements could use a note field, not embedded as an attribute, but as a nested sibling element, sort of like this:

Element (pbcoreRelation) ElementType (pbcoreReleationType) ElementNote (pbcoreRelationNote)

Each sibling element could then have the ability of containing source, ref, version, annotation attributes.

— Reply to this email directly or view it on GitHub< https://github.com/WGBH/PBCore2.0/issues/60#issuecomment-50910674>.

— Reply to this email directly or view it on GitHub https://github.com/WGBH/PBCore2.0/issues/60#issuecomment-50919626.

caseyedavis12 commented 10 years ago

I am imagining a "Note" sub-element in the PBCore relation field having more narrative text instead of being a one-word attribute value. For example:

<pbcoreRelation>
<pbcoreRelationType>References</pbcoreRelationType>
<pbcoreRelationIdentifier>National Educational Television Records, 1951-1969</pbcoreRelationIdentifier>
<pbcoreRelationNote>The National Educational Television Records, 1951-1969 collection, located at the Wisconsin Historical Society, includes a series of Programming Records, 1953-1968 and subject and title files. Box 2 Folder 11 of Subseries 8A contains program development, promotion and descriptive materials on The Cathode Colors Them Human. The finding aid is available here: http://digicoll.library.wisc.edu/cgi/f/findaid/findaid-idx?c=wiarchives;view=reslist;subview=standard;didno=uw-whs-us0066af;focusrgn=C01;cc=wiarchives;byte=391523778</pbcoreRelationNote>
</pbcoreRelation>

Although, use of PBCoreRelation in this way would expand the element's current intention as a way to provide information about related individual media assets.

AllisonAnn commented 10 years ago

This looks good to me. I vote for this - :) Wouldn't the relationshipIdentifier element hold the URI or UniqueID though, instead of embedding it in the note?

Allison

On Mon, Aug 4, 2014 at 8:06 AM, American Archive of Public Broadcasting < notifications@github.com> wrote:

I am imagining a "Note" sub-element in the PBCore relation field having more narrative text instead of being a one-word attribute value. For example:

<pbcoreRelation>
<pbcoreRelationType>References</pbcoreRelationType>
<pbcoreRelationIdentifier>National Educational Television Records,
1951-1969</pbcoreRelationIdentifier>
<pbcoreRelationNote>The National Educational Television Records, 1951-1969
collection, located at the Wisconsin Historical Society, includes a series
of Programming Records, 1953-1968 and subject and title files. Box 2 Folder
11 of Subseries 8A contains program development, promotion and descriptive
materials on The Cathode Colors Them Human. The finding aid is available
here:
http://digicoll.library.wisc.edu/cgi/f/findaid/findaid-idx?c=wiarchives;view=reslist;subview=standard;didno=uw-whs-us0066af;focusrgn=C01;cc=wiarchives;byte=391523778</pbcoreRelationNote>

</pbcoreRelation>

Although, use of PBCoreRelation in this way would expand the element's current intention as a way to provide information about related individual media assets.

From: Adam Wead notifications@github.com<mailto:notifications@github.com>

Reply-To: "WGBH/PBCore2.0" <reply@reply.github.com<mailto: reply@reply.github.com>> Date: Friday, August 1, 2014 3:13 PM To: "WGBH/PBCore2.0" <PBCore2.0@noreply.github.com<mailto: PBCore2.0@noreply.github.com>> Cc: Casey Davis casey_davis@wgbh.org<mailto:casey_davis@wgbh.org> Subject: Re: [PBCore2.0] Expanding pbcoreRelation to include (#60)

I feel I should interject a word of caution here. Adding a "note" sub-element to every element in the schema would make things very complex. Attributes generally should inform the element, and sub-elements should reflect the structure of parent element. However, there is the tendency in a lot of xml schemas where sub-elements actually asset qualifications or clarifications to a parent element.

There's nothing wrong about this, but it leads to certain computational gymnastics when it comes to figuring out which element is which. For example:

HelloGuten tag Is simpler than Hello English Guten tag German Furthermore, it's a lot easier to find the German greeting in the former example. In the latter, I would have to search through every greeting element and look for a sub-element matching "German" and then grab the text from the sibling element... this is complicated. Whereas in the first example, just give me the text in the element where the attribute is "German", is much easier. Granted, there are cases where you have to do such things, but I would only do it when the _structure_ of the concept/idea that the element expresses merits it. Regarding relations, you could do: ``` xml x etc... — Reply to this email directly or view it on GitHub< https://github.com/WGBH/PBCore2.0/issues/60#issuecomment-50923506>. — Reply to this email directly or view it on GitHub . ```
AllisonAnn commented 10 years ago

Actually - I have another idea. The relationshipIdentifier field could have source, ref, version, annotation attributes (which again, I think should be available to all elements), and the link/URI could go in the ref attribute...

On Mon, Aug 4, 2014 at 8:23 AM, Allison Smith serendipity3@uwalumni.com wrote:

This looks good to me. I vote for this - :) Wouldn't the relationshipIdentifier element hold the URI or UniqueID though, instead of embedding it in the note?

Allison

On Mon, Aug 4, 2014 at 8:06 AM, American Archive of Public Broadcasting < notifications@github.com> wrote:

I am imagining a "Note" sub-element in the PBCore relation field having more narrative text instead of being a one-word attribute value. For example:

<pbcoreRelation>
<pbcoreRelationType>References</pbcoreRelationType>
<pbcoreRelationIdentifier>National Educational Television Records,
1951-1969</pbcoreRelationIdentifier>
<pbcoreRelationNote>The National Educational Television Records,
1951-1969 collection, located at the Wisconsin Historical Society, includes
a series of Programming Records, 1953-1968 and subject and title files. Box
2 Folder 11 of Subseries 8A contains program development, promotion and
descriptive materials on The Cathode Colors Them Human. The finding aid is
available here:
http://digicoll.library.wisc.edu/cgi/f/findaid/findaid-idx?c=wiarchives;view=reslist;subview=standard;didno=uw-whs-us0066af;focusrgn=C01;cc=wiarchives;byte=391523778</pbcoreRelationNote>

</pbcoreRelation>

Although, use of PBCoreRelation in this way would expand the element's current intention as a way to provide information about related individual media assets.

From: Adam Wead notifications@github.com<mailto:notifications@github.com>

Reply-To: "WGBH/PBCore2.0" <reply@reply.github.com<mailto: reply@reply.github.com>> Date: Friday, August 1, 2014 3:13 PM To: "WGBH/PBCore2.0" <PBCore2.0@noreply.github.com<mailto: PBCore2.0@noreply.github.com>> Cc: Casey Davis casey_davis@wgbh.org<mailto:casey_davis@wgbh.org> Subject: Re: [PBCore2.0] Expanding pbcoreRelation to include (#60)

I feel I should interject a word of caution here. Adding a "note" sub-element to every element in the schema would make things very complex. Attributes generally should inform the element, and sub-elements should reflect the structure of parent element. However, there is the tendency in a lot of xml schemas where sub-elements actually asset qualifications or clarifications to a parent element.

There's nothing wrong about this, but it leads to certain computational gymnastics when it comes to figuring out which element is which. For example:

HelloGuten tag Is simpler than Hello English Guten tag German Furthermore, it's a lot easier to find the German greeting in the former example. In the latter, I would have to search through every greeting element and look for a sub-element matching "German" and then grab the text from the sibling element... this is complicated. Whereas in the first example, just give me the text in the element where the attribute is "German", is much easier. Granted, there are cases where you have to do such things, but I would only do it when the _structure_ of the concept/idea that the element expresses merits it. Regarding relations, you could do: ``` xml x etc... — Reply to this email directly or view it on GitHub< https://github.com/WGBH/PBCore2.0/issues/60#issuecomment-50923506>. — Reply to this email directly or view it on GitHub . ```
awead commented 10 years ago

Yes, this is how the Rockhall does it. We use relationships to link items to accession numbers, collections, and series:

<pbcoreRelation>
  <pbcoreRelationType ref="http://pbcore.org/vocabularies/relationType#is-part-of" source="PBCore relationType">Is Part Of</pbcoreRelationType>
  <pbcoreRelationIdentifier annotation="Accession Number">LA.xxxx.xx.xxx</pbcoreRelationIdentifier>
</pbcoreRelation>
<pbcoreRelation>
  <pbcoreRelationType source="PBCore relationType" ref="http://pbcore.org/vocabularies/relationType#is-part-of">Is Part Of</pbcoreRelationType>
  <pbcoreRelationIdentifier ref="http://repository.rockhall.org/collections/ARC-0008" source="Rock and Roll Hall of Fame and Museum" annotation="Archival Collection">
    Immaculate Funk Collection (Rock and Roll Hall of Fame and Museum Collection)
  </pbcoreRelationIdentifier>
</pbcoreRelation>
<pbcoreRelation>
  <pbcoreRelationType source="PBCore relationType" ref="http://pbcore.org/vocabularies/relationType#is-part-of">Is Part Of</pbcoreRelationType>
  <pbcoreRelationIdentifier ref="http://repository.rockhall.org/collections/ARC-0008/components/ref15" source="Rock and Roll Hall of Fame and Museum" annotation="Archival Series">Tapes 68-71, Al Bell (120 mins.)</pbcoreRelationIdentifier>
</pbcoreRelation>