[Zope-CMF] Future CMF
sean.upton@uniontrib.com
sean.upton@uniontrib.com
Mon, 07 Oct 2002 10:08:35 -0700
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
-----Original Message-----
From: Erik Lange [mailto:erik@mmmanager.org]
Sent: Saturday, October 05, 2002 7:05 AM
To: Paul Everitt
Cc: zope-cmf@zope.org
Subject: Re: [Zope-CMF] Future CMF
At 10:21 AM 10/5/02, Paul Everitt wrote:
>Speaking of "Future CMF" (and thanks, Erik, for relabeling the subject
>line), Jim's announcement of proposal on this topic has received no
>comments:
>
>
>http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/
>ContentManagementProjectsForZope3
>
>Zero, zippo, nada.
Here's my personal comment:
Once again the visions of the pope brought tears into my eyes :-)
>Here's what we'd really like to see: people who care deeply about one
>of the topics (workflow, metadata, etc.) become the champion for that
>topic.
We're pretty focused on metadata here at mmm, and we would love to
contribute in any way we can.
First step would be a complete implementation of Dublin Core elements, but
I belive we should have some sort of plug-in structure for metadata sets,
that can be assigned to the objects in the framework.. I.e. the Dublin Core
metadata set even in it's complete form, doesn't deliver all the metadata
elements needed when working with media. The "time" data is missing, so you
can't describe a resource that is defined by time in a specific mediafiles
internal timeline, i.e. a clip in the masterfile. (Example; Car-chase: in
01:12:35:12 - out 01:15:54:03 - "Car-chase" is ofcourse DC.Title, but what
is in/out?)
MPEG7[1] and MPEG21[2] are metadata sets that operates with timebased
resources, and a structure that allows to plugin various metadata sets into
the framework has been on our wishlist for some time.. presently we just
adds the extra metadata we needs as properties on our objects, and it works
okay - but it's not the ideal way of doing it.
I imagine that other special areas has their own sets of specialised
metadata as well, so I think going for such a structure will be usefull in
a lot of scenarios.
For us, the posibillity of using MPEG7- and MPEG21-implentations together
with Dublin Core metadata would, as I see it, in reality make the semantic
web [3] of multimedia come to life ! :-)
>For those that don't want to be champions...at least read the section
>under "Background". I tried to capture some of the spirit and intent
>of what has gone on up to now. This latest discussion has illustrated
>that we have more work to do in getting this nailed down!
Well... we're on ! :-)
What do we do next.. ?
Regards,
Erik
[1 ]MPEG-7, formally named "Multimedia Content Description Interface", is a
standard for describing the multimedia content data that supports some
degree of interpretation of the information's meaning, which can be passed
onto, or accessed by, a device or a computer code. MPEG-7 is not aimed at
any one application in particular; rather, the elements that MPEG-7
standardizes support as broad a range of applications as possible.
http://mpeg.telecomitalialab.com/standards/mpeg-7/mpeg-7.htm
[2] The vision for MPEG-21 is to define a multimedia framework to enable
transparent and augmented use of multimedia resources across a wide range
of networks and devices used by different communities.
http://mpeg.telecomitalialab.com/standards/mpeg-21/mpeg-21.htm
[3]: The semantic web: "A road map for the future, an architectural plan
untested by anything except thought experiments." - by Tim Berners-Lee
http://www.w3.org/DesignIssues/Semantic.html
_______________________________________________
Zope-CMF maillist - Zope-CMF@zope.org
http://lists.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests