It’s going to be a crazy interesting challenge.  HP is huge and has a lot of hardware devices but a pretty poor consumer experience across the devices, especially when compared with Apple.  Not sure yet what I will be working specifically but there is a lot of interesting technology to explore, like WebOS from the Palm team, tablets, netbooks, media centers…

The blog will continue…

David Riecks, moderator of the group, points to the Metadata Manifesto posted at the Stock Artists Alliance as the guiding set of principles that the industry should follow.  The core guiding principles are:

• Metadata is essential to identify and track digital images.
• Ownership metadata must never be removed.
• Metadata must be written in formats that are understood by all.

Google would do well to follow these guiding principles for all media formats – not just images.  Let’s hope that Google adhere’s to it’s “do no evil” mantra and preserves the metadata in derivative files.

Google can maintain metadata within images by following the specifications that have been defined by companies such as Adobe, Apple, Canon, Nokia, Microsoft and Sony – all members of the Metadata Working Group.  The most recent public specification outlines how to reconcile various metadata formats within the image formats to increase metadata preservation across systems and when creating derivative files.

So, the industry guidance is there, as well as the technical steps to make it happen – what else are you waiting for Google?

What would you ask Google to do with your image metadata?

Technorati Tags: Google, media, images, search, metadata, xmp, MWG, SAA, ControlledVocabulary

Watching the video, the following question is asked – “If they drag and drop straight off of Google, the metadata is lost. … it seems that Google has dumbed down the photograph so it doesn’t contain our metadata.“  Which is very true.  Naughty Google stripping my information and creating orphan works.  What will your lawyers think about that?

When pressed for what they would do about it …”… A user that is informed and provided that metadata and a way to find the imagery in a way will not hurt your copyright is important to us, we want to improve in that area. We are not there today obviously … it’s going to be baby steps because it is a hard problem, its not just a people problem but it is also a technical problem.“

No. It’s not a hard technical or people problem.

Technically, just make the thumbnails you render include basic copyright information from the original image so that anyone that drags the file off the Google search can look into the file and see who owns the rights.  Jeez, the XMP SDK has been open source for how many years now??

Socially, more easily accessible information will help keep honest people honest.  Earlier in the video Zitzman  almost rationalized the Google metadata stripping situation as an image consumer problem “…if they are not going to do the right thing in the long term, that is the problem“.  Remember who your audience is – you need to see the image to think about licensing it.  Surface the metadata in the image in the results page.

There will always be people who steal.  That is not the problem to solve.  The challenge is to raise the overall awareness of the ownership of the media, and educate the consumer on the right ways to re-use the media.  Google could even be the hero by proactively adding metadata to thumbnails to link back to the webpage that it was posted on – how about that for service?

Technorati Tags: google, search, metadata, xmp, photography

Before we start, you should understand the benefits and downsides in creating your own schema.  Benefits include

• optimization of UI into one panel for critical properties
• support for properties that are not available in the standard panels
• integration with other systems that use your custom properties

Downsides include:

• maintenance of namespaces and property versions over time
• distribution of panel if others need to view your custom properties
• possible learning curve frustration

Most folks want to create their own panel for 2 main reasons:

1. optimize the editing and viewing of metadata
2. add support for custom properties

The following provides an overview and description of the Generic panel SDK sample properties.xml file.  It shows how the XML structure and definition is related to the UI and interaction that is shown in the File Info dialog.

Get the SDK

The first step is to download the latest XMP FileInfo SDK 5.1 libraries from XMP Developer Center.  After unzipping the libraries you will find within the Tools folder another folder called Generic.  We will be using the components of that folder to create custom panels

Copy the Generic Folder

Copy the Generic to:

MAC OS:  /Library/Application/Support/Adobe/XMP/Custom File Info Panels/3.0/panels/


WINDOWS XP: C:\Program Files\Common Files\Adobe\XMP\Custom File Info Panels\3.0\panels\

WINDOWS VISTA: C:\Program Files (x86)\Common Files\Adobe\XMP\Custom File Info Panels\3.0\panels\


The above is the easiest place to add custom panels if you have admin privileges since it is the location for the existing set installed with CS5.

The user specific locations are:
MAC OS: /Users/<username>/Library/Application Support/Adobe/XMP/Custom File Info Panels/3.0/panels

WINDOWS XP: C:\Document and Settings\<username>\Application Data\Adobe\XMP\Custom File Info Panels\3.0\panels


WINDOWS 7/VISTA: C:\Users\<username>\AppData\Roaming\Adobe\XMP\Custom File Info Panels\3.0\panels
If you use the user specific locations you will need to add the above path to the Flash Global Security Settings Manager:

1. Click on the Edit Locations… drop down and select Add Location…
2. Paste in the path as above (replacing <username> with your specific data)
3. Check to see location is added in the Manager
4. Copy Generic folder to location
5. Load up a CS5 app and check the File Info Dialog to see if it has been added (be sure to scroll the dialog and the drop menus to see if it might be hidden)

Since the Panels are Flex/Flash based and are being run locally, the panel path needs to be recognized by the Flash player as OK to run.

Modify the Properties.xml File

The Properties.xml file is located in the Generic folder and defines the namespaces, properties and basic UI of the panel.  So get out your favorite text editor – I suggest TextWrangler for the Mac since it is free and highlights the text nicely making it easier to read.  Do NOT use Word or other word processing editors unless you know that you are saving the file as pure text and not RTF or doc format.  Now let’s look at the content of the file:

The area we want to mess with is within the <xmp_definitions> </xmp_definitions> tags, starting with:

<xmp_schema prefix=”custom” namespace=“http://my.custom.namespace/” label=“$$$/Custom/Schema/Label=Custom Properties” description=“$$$/Custom/Schema/Description=This example panel contains most of the options available for the ‘Generic Panel’.”>

<xmp_schema – defines the beginning of the schema definition

prefix= this defines a variable name for the namespace URL, like a short reference name to be used only within this panel

namespace= define that namespace that you want your properties to be defined within

label= defines the Title of the panel NOT the Tab name – that is defined in the manifest.xml file

$$$/Custom/Schema/Label= defines the localization property that is used to store the different language versions.  If you go into the Generic/loc/ folder and open the “Generic_de_DE.dat” file in the text editor, you will see how the localization property is mapped to the German value.  If you are not localizing the panel, you can remove this property and just define the value, for example: label=”My Custom Label”

description= defines the description for the panel that is shown when the user rolls over the Tab Name.

$$$/Custom/Schema/Description= as described above, this is used for localization purpose, you can choose to include or not depending on your internationalization needs.

Simple Properties

Simple properties like, text, data, numbers, true/false are defined in one line entries of the form:

<xmp_property name=”Text” category=”external” label=”Text Field:” type=”text”/>

If you noticed I removed the localization variables for simplicity.

<xmp_property – defines the element that will describe the property

name= defines the UI widget that will be used to display the property type.  Includes the following simple types:

• Text – used for properties that can only hold a single value, like Country or City or Name
• TextML – used for properties that hold a single value but can be verbose, like description
• Boolean – used for check box like options, on or off, like male or female, or review status: yes/no
• Date – used for entering a single date, the calendar widget is the UI
• Integer – used for entering numbers, works with the ui:format variable to define the units, like cm, in

category= defines whether the field is displayed for editing (external) or read only (internal).

label= defines what label description is shown in the UI before the entry/display field

type= defines the type of value that can be stored in the property, works with the property_name variable:

• text = contains textual data
• boolean = if the checkbox is selected, the value of “True” will be set for the property
• date = the date will be stored in the property as yyyy-mm-dd
• integer = only the numeric value will be stored in the property, not the prefixes or suffixes

UI Control Properties

• ui:height= defines the height of the input field, can be absolute “=15″ or relative “=10%”
• ui:width= defines the width of the input field, can be absolute “=15″ or relative “=10%”
• ui:format=defines the prefix “re: {0}” or suffix “{0} cm” that is appended to the view of the value.  The prefix or suffix content is NOT added to the value stored in the metadata
• ui:multiline= defined as “true” or “false”, works best when combined with an the appropriate property_name and type

The above UI variables can be included with any of the property definitions BUT may or may not work or make sense depending on the types of properties.  Remember that in the Generic panel, each property is provided with a single horizontal space that it occupies.  Customizations are restricted to the labels and entry field properties.

Simple Properties Choices

These definitions allow us to create drop down and multiple choice entries for the panel.

<xmp_property name=”ClosedChoice” category=”external” label=”Closed-Choice Input:” type=”closedchoice” element_type=”text”>

name = defines the UI widget that will be used to display the property type.  Also includes the following simple types:

• ClosedChoice – defines the UI widget for a closed list of values that the user can chose from.
• OpenChoice – defines the UI widget for a list of values the user can chose from or they can write their own in

type = defines the type of property that will store the values, works together with the name property

• closedchoice – works with ClosedChoice to limit the selection of variables
• openchoice – works with OpenChoice to provide selection and option to provide custom entry

element_type = defines variable type that is stored in the property, similar to type for simple properties

Once the property and widget is defined, the choices for the drop need to be enumerated.

<xmp_choice raw_value=”" label=”(select color)”/>

xmp_choice – defines the elements that will provide the choices, each choice will have it’s own entry.

raw_value = defines the value that is stored in the property, in the above case it is set to null if the user has not selected anything.  Here is where you define what value you want stored in the metadata.

label = defines what is shown in the UI, since this is the first xmp_choice definition it is the default view and provides instructions on selecting the values.

Arrays

Arrays are useful for defining properties that can contain multiple values, like keywords, or contributors.

<xmp_property name=”TextArray” category=”external” label=”Text Array Input:” type=”bag” element_type=”text”/>

type = defines the array type which can be:

• bag – meaning it is unstructured and a ‘bag’ of values
• seq – meaning it is sequential and their is value in the sequence of values

The default display separator for values is the “;” semicolon.  However, if you enter values with a “,” comma it will be converter to a semicolon.  There are ways to change this but are beyond the scope of this intro.

There are some localization definitions that I am not going into, maybe that will be another post if people are interested.  I hope this is a good start on how to understand what the Generic panel is about and how to begin to use it to create custom schemas.

If you created a custom panel with Flex/Flash Builder, you will need to rebuild the panel with the new CS5 XMP FileInfo SDK 5.1 libraries.

If you used the Generic Panel and modified the properties.xml file, then you will need to use the new CS5 Generic Panel.  Most likely you can reuse the same properties.xml file – see caveat below…

From the Readme of the CS5 XMP File Info SDK

1) Custom Panels that have been built with the CS4 SDK
   have to be rebuild with this CS5 SDK to work within CS5.

2) The Generic Panel’s schema files are fully compatible,
   but the Generic Panel included with CS5 SDK has to be used.

3) Panels built with the CS5 SDK will also work in CS4
   as long as the XMPDataGrid component is not used.

If you are using Custom CS3 File Info panels, then you need to rebuild them completely using the Generic Panel or with Flex/Flash Builder.

First Look at CS5 File Info

Where did my panels go?

The first thing I noticed when I opened up the dialog is that there were far less panels than I had seen in CS4.  Many of the panels have been hidden from view – it is part of the new Panel Management feature that allows users to hide and show the metadata panels that they need.

Panel Management

Off to the side is a drop down menu that shows you the hidden list of panels that are not shown.  Simply select the panel and it

Panel Management

will appear in the dialog.  The panels can also be rearranged by dragging them in front of each other – the magic of Flex.

To hide a panel, simply hover over the title of the panel and a small “x” will appear. Clicking it will move it to the hidden list.

IPTC do you?  It’s a PLUS

The IPTC is an organization that is focused on developing standards for news and press agencies.  It has been around for quite a while and developed the first widely implemented metadata standards from the days when images were sent over the wire.  The IPTC has strong roots in the photography world, especially for tracking image description and credits.

IPTC Extended Panel

The IPTC has a long working relationship with Adobe.  They were the first major standard to adopt XMP when the migrated from their old binary

standard called IIM.  That new standard was called IPTC4XMP.

For the new extension to that standard, they have teamed up with PLUS to focus on digital rights expression and interoperability.  PLUS – Picture Licensing Universal System describes the vocabulary used to define rights usage terms.

The new IPTC Extended Panels standardize the metadata to be captured in the following areas:

• Description of the Image
• Artwork in the Image
• Models used in the Image
• Administrative Information
• Rights Related Information

The IPTC Standard Panel still exists and covers the basics such as:

• Contact Info
• Image Info
• Content Description
• Status Info

Preferences

Preferences

New to the File Info Panel are preferences.  From here you can turn the auto completion on or off, or clear the auto completion values that appear.  There is another way to control these lists in a more detailed way but that is a subject for another post.

Resetting all XMP changes effectively clears all that values that you have changed and restores them to the state when you originally opened the file.  It is the same as canceling the dialog and reopening it.

Restoring the default dialog displays all the panels in their default order in the dialog.

Templating

Templating

From the dialog one can create and apply metadata templates.  Creating a template is as simple as starting with a new blank document and entering values in the fields.  Then select Export and the XMP template will be saved in the templates folder.  It will also show up in the drop down list in the dialog and is made available in Bridge as well.

Bridge has a dedicated feature to create templates as well but it looks like it doesn’t support the IPTC Extension properties as yet.

To apply a template, you import it and then choose from the options to meld it with the existing metadata values.

Template Import Options

• Clear existing  properties and replace it with template properties – this will clear out all the existing subjective metadata and then add your templatevalues.
• Keep original metadata but replace matching properties from template – this will only replace the properties that have values in the template but leave all other existing values as they are, effectively appending the information.
• Keep original but append matching properties from template – this maintains the original properties but adds or appends the values that are in the template.  This can be useful for applying a base set of keywords for example, that would not delete the existing keywords.

Templating can be confusing and probably requires a devoted blog post on the nuances.

Overall the new dialog address the ever growing demand to add more metadata to media by enabling the end user to customize what standards to focus on.  Customization of the panels can be done but I will save that too for another post.

The concept is pretty simple but also quite powerful – by adding metadata to the asset, one is able to navigate related information from the asset.  Strongly attached metadata allows me to begin my information discovery from the asset itself because it has carried it’s context with it.

How many times have you found a photo or presentation and then wanted to find the email thread that discussed the content of the asset?  Or just simply wanted to know, where did this asset come from? And can I use it?

Well, a metadata savvy email client, or web client would be able to capture some of that context by inserting a related link, relevent URLs, even people or topics into the metadata of the asset you downloaded.  It would enable that asset to be contextually linked to where it came from, allowing you to more easily navigate from the asset to the context.

That is one simple example, but imagine establishing a core schema of critical business properties that can be embedded into all your media.  As the media flowed through your systems, it would populate the schema with values and links to authoritative information source within your company.  Ultimately allowing the end user to quickly jump from the asset to those sources.  The media user would immediately understand who has been associated with the asset, what projects it has been involved with, how much it has or will cost, what the current status is.

You may ask, isn’t that what an asset management system does?  Well, yes but… The difference is one of putting all your informational eggs in one DAM basket versus an organic web of information that can be strongly attached to your asset.  A DAM is still required for caching and indexing information but the media is really at the center of capturing and linking to related information.

A Media Centric approach compliments other search and discovery processes to make it ultimately easier for the end user to navigate to the desired information from the context that they started from.

The barcode analogy is what I use to describe the opportunities for OpenSAMSN. The theme of “identification and linking data” is growing stronger as there is increasing pressure on the production and distribution (eco)systems to become more streamline.  The handoff of assets between systems need to become more integrated – this can be done by traditionally connecting the systems via APIs.  The API approach is quite fragile since it relies on connect 2 specific systems, negotiating APIs functions and versions. What happens if one company wants to upgrade and the new system doesn’t support all the required APIs?

An alternative is to use the metadata in the assets as the integration pathway in conjunction with registries to connect the information flow.  The asset itself could contain all the data need for integration or it could contain a reference to a registry that would provide the info.  The question between embedded and referenced data is a strategic one and can get complex.  Embedded metadata could also be encrypted and reference data could be delivered based on an access control list.

In general, this is all fine if the namespaces are well known and understood – like Dublin Core or IPTC.  But what if each company has their own custom namespaces?  There needs to be another feature of the registry to enable a ‘mapping’ or semantic understanding between related properties.  This metadata interchange enables the information to flow more easily between the systems.

A Utopian dream that this can get done? Well, we never thought that we would be scanning our own products in the self checkout line one day.
 

Technorati Tags: metadata, xmp, SAMSN, barcode

In general, the entropy of systems tend to increase overtime – just look at all the stuff in your garage or all the files on your desktop.  Life on Earth is an interesting case of entropy decreasing in a localized way, primarily because of the energy from the Sun helps fuel the chemical processes that power living organisms.  The most successful organism over the centuries has been the bacteria – primarily because it is simple and can quickly form symbiotic relationships with other bacteria or hosts.

The web today is a mass of growing information that is following the laws of physics and increasing in entropy – tending to disorganization.  There are a few pockets of “organisms” such as Google that are investing a lot of energy to fight this loss of entropy.  In fact the evolution of these search organisms started with the human powered indexes of Yahoo! and eventually led to more centralized, automated Google indexes. 

Consider that the energy and effort to keep systems organized is decreasing and becoming more democratized – primarily because the pieces of data themselves are each fighting entropy by containing a bit of structure such as metadata or related links. High energy systems such as a central index (aka Google, aka humans) may succumb to more distributed, yet coordinated systems (aka Linked Data, aka bacteria).  Or the central index might mutate and build a symbiotic relationship with it’s bacterial metadata. 

As with all symbiotic relationships, a key element required is trust. The more metadata is applied and linked, the more important trust, authoritativeness and identity become.

Technorati Tags: xmp, google, metadata, linked data

Google is once again leveraging it’s massive data set to provide new services. Clearly this is not the open data approach discussed in my last post. It raises a number questions about trust and that I mentioned which goes to the heart of that creepy feeling.  I don’t want to trust Google to recognize everything in my world – I want to be able to trust the authoritative sources themselves.

That where having a mechanism to directly link to the authoritative information is critical – just like the barcode can directly resolve to the product owner.  The distinction between Goggles and Google online search is that the user expectation is all about recognition and identification of a point piece of information rather than exploration of related information about a vague topic.

So as a vendor, how do I ensure that my product is properly identified and communicated to the end user? 

Well, you’ll need to have authoritative reference images and related information that Google can reference – you might as well make that information open so that others can link to it as well.  This becomes your new ‘website’ for Linked Data processes – a reference website for machines only.  Perhaps it is woven into your existing website for humans using RDFa, or it could be a public extension of your internal marketing DAM – or both.

That’s why it will become increasingly important to be able to connect your rich media to authoritative metadata by using the SAMSN principles. Enabling this will be a SAMSN registry that will connect the media to authoritative information and distribute the information as needed.

Getting your rich media and related information out there in an authoritative manner will become increasingly important for SEO.