[Zope-CMF] Future CMF

Mon, 7 Oct 2002 17:16:36 -0500

I decided to stick around Zope the moment I understood how suitable its
architecture was for the full-blown
personalized-web-portal/CMS/MAM/editorial-system monster I had in mind,
which happened when I was commited to advise a client about technology
adoptions for his company's portal. (After doing my homework I had this
small breed of  companies saying to me "not sure about what you're talking
about but at least our software can do a part of what you need", while local
developers opted for saying me "yeah, we can do that, just need to wait for
MSWhatever to come up". )   :)

One of my 'silly' feature requests used to be the handling of the
relationship info between all the content units of a portal. Last year after
asking to this same list
http://lists.zope.org/pipermail/zope-cmf/2001-July/008352.html
about a sort of derivative problem, I was told about Ken Manheimer's
OrganizationObjects proposal,
http://cmf.zope.org/rqmts/proposals/OrganizationObjects
and I also started to think of a suitable model for all the cases I had in
mind. Here are some of those ideas:
http://lists.zope.org/pipermail/zope-cmf/2001-July/008465.html

The problem is way complex and fascinating, and also a necessity shared by
all types of content, not just the multimedia stuff. A video story about the
recent WorldCup would be made of dozens of small clips and even still
photographs. All those clips and photos could have a relation with the
written stories about the event of the day they were shot at; another one
with the people being shot; another one with other video stories where they
were used at,... etcetera. If a user was to know the complete set of
relations between all the elements in the scope of a story (in example), he
would be a better informed person, either he was an end-user or any member
of the company you're developing for.

For some people this belongs to the Knowedge Management arena. I don't
agree. I think is a problem that a new portal tool - let's name it
'portal_relationships' -  could solve, alongside with an extension to the
portal object model, regarding its metadata sets (in the sense of Erik's
posts), and regarding the ability to store some other objects' relationships
inside them.

Ausum

----- Original Message -----
From: <sean.upton@uniontrib.com>
To: <zope-cmf@zope.org>
Sent: Monday, October 07, 2002 12:08 PM
Subject: RE: [Zope-CMF] Future CMF

> 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
>
> _______________________________________________
> 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
>