The PRISM working group has adopted this technique for people listed in its pending PRISM Metadata for Images schema: creators, contributors, and peoplePictured.

Contract this to IPTC Core which uses 9 of its 40 elements to capture the contact information for the Creator, or PLUS which uses 12 of is 85 element to capture the contact information for Licensor(s).

1) On the topic of Linked Data, the idea is you could have a Contributor named “Hughes, Langston,” or “Smith, John” where the common name may or may not be ambiguous or unique. But if you add an actual UID to the name, it would be unambiguous and machine-readable. The Linked Data way of doing this is to include a URI for the person. This makes it possible to traverse the universe of objects containing this URI, and it links our PBCore object to that universe. We could optionally add URIs to place names, organizations, subjects, and relationships in the PBCore record. The way to allow this would be to add optional attributes to the PBCore schema, so you could include UIDs inside elements. I wouldn’t make it mandatory though, because many PBCore users might not be ready to go to the effort of adding UIDs like this. (On the other hand, I’m thinking about ways to automate the inclusion of UIDs in our cataloging tools and workflow. The payoff from doing this seems likely to be worth the effort.)

2) The recommendation of adding Profiles seems very important to me. For example, a PBCore record conforming to a COVE profile would be able to validate against COVE metadata requirements. The COVE metadata requirements include a character-count limit on Title and Description fields, and a specific COVE taxonomy. If I could feed COVE a PBCore record that COVE knows is COVE-compliant, I wouldn’t have to enter metadata into COVE by hand which is the current workflow. You could specify a Profile by adding a namespace attribute in the PBCore document root, and attributes inside the relevant elements. So COVE would need a schema to validate the document, but that’s easy. I’m guessing Public Media Publisher or whatever is coming down the pike could function in the same way. PBCore documents based on Profiles would remain valid and parse-able by applications that don’t care about Profiles. All we’d be doing is adding functionality for applications that do know about them…and make it easier for people like me at stations that need to feed the same content to different systems

Attributes would have to be allowed by the PBCore schema to make any of this possible. Then you could unambiguously identify a wide number of values, include URIs for elements like subject, contributor, and identifierSource, ease PBCore into the Linked Data universe, and enable the construction of usable (and machine-readable) profiles.

Respectfully,
Jack Brighton

thx,
y.

Thanks,

Stefan Wray