[Zope-CMF] Future CMF

[Erik Lange]

Hi Sean,

You're absolutely right :-)

About "Double" metadata elements, allow me to quote Gitte W. (also mmm) 
from todays post "metadatatoolz" :

"I was thinking about doing something to the metadata tool so it could
use different metadata implementations (specify them through ZMI). In
that order you could say that your Images should use DublinCore metadata
but your media events should use MPEG-7 ... :-)
Sort of like with the workflow tool ... I think :-))"

Do you think such a tool is the right aproach ?

I think a "priority-model" would be usefull in such a tool, so if more than 
one metadata-set is used for an object-type, doubled elements are taken 
from the set with the highest priority (typical DC). When exporting objects 
via syndication, it should also be possible to set which metadata set or 
sets that the syndicated objects are represented by.

About compositted media presentations:

MPEG7 is for individual media-resources what dublin core is for textural 
content.

MPEG21 is a framework that besides the individual media clips metadata, 
also describes relations between resources and facilities in a 
media-production. So with a MPEG21-implementation, you can "send" a 
complete movie by poniting at the sourcetapes and describe in an EDL 
(edit-decision-list) where and how they are to be put together to form the 
final presentation. MPEG21 also describes with vision-mixer and visual 
effects are used, so the can be re-produced in the recieving end (you will 
ofcourse need to have the vision mixer in question for this to work).

I belive we should take this slow, and do MPEG7 before we do MPEG21, which 
will be truely mindblowing and sematic web'ish :-)

Number one should be a complete dublin core implementation, since this will 
have a broader use, and once the structure is in place, we should quite 
easy be able to add other metadata-sets...

Has-part / is-part-of is exactly what we're missing in the current 
DC-implementation ;-)

This would also be usefull for describing compound documents with static 
content only (images and text)...

I certainly don't find your post too long or irellevant in any way, but I'm 
also a freak for media metadata so maybe I'm not the right person to judge 
*S* - please feel free to join our community (and mailinglists), if you 
feel you're getting off-track for this list ;-)

Regards,
Erik

At 07:08 PM 10/7/02, sean.upton@uniontrib.com wrote:
>I'll add a few comments to the metadata discussion, since I find Erik's
>comments interesting.  This is really not that much about metadata, but
>dealing with relationship management (mainly from the perspective of a media
>company).
>
>1 - All the Dublin Core really should be implemented; for video, assets,
>esp., relationship management (DCMES Source and Relation elements - or at
>least that type of information) is crucial (see #3).
>
>2 - Multiple metadata sets/standards have some level of overlap; if you
>assume that not all objects - as different as video clips and tabular sports
>scores - will have the same metadata sets (i.e. global metadata sets), there
>will be a need to map certain elements from one set to another, so that
>metadata sets have a ways to reuse key elements across sets; perhaps some
>sort of mapping tool, or a way for one metadata set to subscribe to changes
>in another?  It is those element mappings that really matter for "semantic
>web"-ish ideas.
>
>3 - I've been reading stuff on MOS architecture lately (I know very little
>about video production, but media asset management and media production
>concepts in general fascinate me) - one thing that strikes me about content
>management as it relates to video and other complex assets: there will be a
>divide between source and derivative assets: for example, the whole of a TV
>news show will be composed of many clips, effects, other sorts of content
>and activity all related by timeline; like print and online publishing,
>production video/television, for example, has to make their CMS represent
>multiple content as a coherent whole via composition.  All this leads me to
>believe that you can't do metadata (or any complex CM organization) right
>without a good relationship management model.  One of the things that the
>CMF really, really, lacks is relationship management, which is an important
>for addressing the issues of media composition.
>
>For example: My video editors keep source assets archived on DV tapes kept
>on a shelf; our plans are to create a content type for multi-media assets
>that includes the ability to just be a catalog record for library/archival
>purposes.  Each tape, for example, could be labeled with a barcode or
>numeric ID that would allow it to be tracked in the system; derivative
>assets (stored streaming video clips in the CMS) could reference the source
>asset by pointing to the URI or Identifier of the Catalog entry.  No such
>machinery exists within the CMF at this point to do that relationship
>management.  In addition, when my news staff creates a news article that has
>a need for related video, ideally, a video assignment object was created in
>the CMS so that a video photographer could go shoot footage of the event in
>question.  This "assignment" object is related to the (at this point in
>time, eventual) source asset Catalog entry (or will be, based upon a
>"slug"), eventually, the derived streaming video clip, and the news story is
>related to both.   On top of that, I need to be able to relate different
>video clips derived from their source assets to each other, potentially.
>
>In this scenario, in order to even think about doing workflow, you need to
>have a solid relationship model in place to relate the various
>"compositional" pieces of related content into a coherent "compound" whole;
>if a relationship management model is in place, workflow can likely wrap
>around using ideas like guard conditions that check for dependencies ("Do
>not release news story X to published until image Y is published as well")**
>and email triggers ("upon a change to an item marked as a dependency, notify
>the related item's owner") to make sure that work for all the components in
>the whole are somehow in sync.  In my organization, we have to worry about
>these sorts of things, but are just barely beginning to scratch the surface
>of tackling such problems.  This whole story only takes into account the
>issues of managing "has part/is part of" relationships, but this is a big
>deal for a complex media production system, like that of an online news
>site.
>
>         ** Of course, there are scary issues if you have cyclical
>dependencies here!
>
>Obviously, relationship management has been on my mind lately. ;)  I think
>there are many ways to approach this:
>
>         + Assume relationships are just based
>           upon related subject keywords. (easy)
>         + Add keywords into subject that have nothing
>           to do with subject to forcefully unify explicit
>           relationships (hackish)
>         + Use a (simple) relationship mgmt. Zope product
>           like Max M's mxmRelation product, and code skin methods
>           that allow a UI to search for other objects, and
>           add/delete relationships; make skin method an action
>           for the types you want to have this functionality.
>           (better)
>         + Have a tool that can add functionality to content
>           types to manage complex relations. (best)  This means:
>                 - Able to specify type of relationship
>                         - "Has Part" (compositional relationships)
>                         - "References" (conceptual relationships)
>                 - Inverse of above can be inferred via catalog
>                   query:
>                         - "Is part of"
>                           (query for object that have this obj as
>                            'has part' relationship)
>                         - "Is referenced by"
>                 - Specify a unique label/keyword for each rel:
>                         - "Next/Previous Item"
>                         - "Related Events"
>                         - "Yesterday's Related Coverage"
>                         - "Related artwork"
>                         - "Related Template?"
>                 - Query for relationships based upon relationship
>                         type, content type, relationship label, or
>                 - Deal with related content that is both catalog
>                         query-driven, and explicitly defined relationships.
>                 - Be able to store relationships on behalf of content
>                         objects that know nothing of relationships.
>                 - Alternately, let content objects store their own
>                         relationships if appropriate.
>                 - The relationship type refinements steal language
>                         from a subset of the Dublin Core refinements.
>                 - Such relationships would require a common API, which
>                         would be used by applications as well as for
>                         implementing the DCMES Source and Relation methods
>
>Sorry to bother with such a long post, but this seems like an area for
>improvement that should be thought of for Zope 3's CM story, but likely not
>before something similar is done to try and solve some real problems for CMF
>sites first.
>
>Sean