portal_relationships (was Re: [Zope-CMF] Future CMF)
Ausum Studio
ausum_studio@hotmail.com
Tue, 8 Oct 2002 14:43:21 -0500
----- Original Message -----
From: <sean.upton@uniontrib.com>
To: <ausum_studio@hotmail.com>; <zope-cmf@zope.org>
Sent: Monday, October 07, 2002 6:54 PM
Subject: RE: [Zope-CMF] Future CMF
> After reading your old posts, if I understand your problems correctly, I
> think we really have similar needs (need for dynamic criteria, ability to
> rely on explicity stored relations as well as ones resulting from a
query).
Looks like that. I'll comment your ideas and please, add an IMHO before each
sentence. :)
> I agree that there is a need for a tool; in the ideal picture in my head
at
> this point, such a tool might:
>
> + Provide a place to store relationships, for both:
> - Relationship-aware content objects types
> that don't store or only partially
> store their own relationship information
I'd like all the content objects within the CMF to be relationship-aware
(in the same sense that all of them have and id and a path). All previous
objects not containing this attribute might be considered as having a None
value there, at least until portal_relationships is acquaintance with it.
> - Existing content object types that know
> nothing of managing any sort of
> relationships; the methods to manage these
> relationships are provided by skins that
> use this tool directly.
When objetct A don't know anything about who it's related with, it might be
able to automatically receive that information in response to a user request
regarding object B, for example, which might have determined "I'm related to
A" (all through portal_relationships by the way). Skins here might perform
portal_relationship's methods to override values or eventually trigger some
tasks, but esentially that "relationship awareness propagation" might work
in the background, integrated to the workflow when possible.
> - This means that such a tool could play friendly
> with existing content types, such as the ones
> in CMFDefault, CMFTopic, etc. as well as
> content items that know how to store their
> own relationships (becuase they have reason to)
> + Provide a simple API for relating and unrelating objects
> + Provide a means of looking up all relationships
> for any given object.
I agree.
> - Or, look up relationships using a filter concerning
> ==> relationship type / model
> e.g. "Has Part" / "Is part of" /
> "References" / "Is referenced by"
> - "Has Part" and "References" are stored,
> one-way relationships (static), and:
> - Perhaps a source/derived model to implement
> DCMES Source:
> "Is version of" (stored) and,
> "Has version" (queried)
> - "Is part of" results are the result of
> Catalog queries for items that
> have a part (results of above, dynamic)
> ==> relationship label/keyword
> - arbitary, custom, and unique
> e.g. "related photos"
> "related by subject"
> "yesterday's coverage"
> ... or simple defaults like:
> "related content"
> "associated media"
Please take a look at this other post:
http://lists.zope.org/pipermail/zope-cmf/2002-September/015437.html
I think it's in the scope of the portal_membership tasks.
I agree that the tool should provide a means to get to know all the
relationships behind, but most of them would come from the objects
themselves, and therefore those (relationships) may be catalogable. In my
concept portal_memberships does all the job to process the relations but the
objects in its turn do provide to the tool the information that it is not
aware of. Takes this as an example: If object N is created as a comment to
object M, both would know that they are, respectively son and father, right?
If you want to know which objects - among many others - are related to
object M, it would answer to you "I know some of all those that claim to be
related to me - and I'm not sure whether they're saying the truth - but at
least I know these are my children and relatives. Is that enough for you?".
:)
Ok, I know I'm entering portal_discussion fields, but then take this as
another example: If you have a breaking-image that suddenly gets the world
attention, rest assured that everything after that image might be considered
children, including all subsequent written and audiovisual stories, right?
In my plan, if you want to know everything about that image, you just need
to ask it to itself.
> ==> object content type
> - Value of Type() for related objects
> ==> path of content
> - Path hierarchy, to restrict where to
> look for related items.
> ==> hold info: Is related object a dependency?
> - Used for workflow guard conditions?
> - Such functionality should return both a
> reference to the related object or (preferably),
> the objects path, and also return some bare
> metadata about the relationship (its model, label,
> content_type of the object, dependency(Y/N))
Coud duplicate ZCatalog's functions. Maybe we use a special index (or index
type) for the objects's stored relationship info.
> - For performance, it may be wise to cache metadata
> about objects??? For example, creating a list of
> related headlines requires a Title to link to; if
> we have to traverse to the object to get this, it
> could get expensive, so caching the Title might be
> nice?
I'm not invalidating you metadata caching idea, but maybe most of the data
could be provided by portal_catalog.
> + Provide method to determine if two objects are related
> - And, if so, what is the nature of the relationship
> + Provide a method, when passed both a single reference object
> and a list of other objects, determine which of those objects
> is related to the reference object, and in what way. This
> is similar to the smart list functionality of Max M's
> relation product.
Yes, that's portal_membership's job. If object X has an attribute that says
'My father is object Y' , and another one that says 'My father is object Y'
too, then is portal_relationships the one who tells, 'ok, they're brothers
and then stamp that information back into each of those objects. The ugly
part is that each object update would requiere a search to the catalog ( and
so it contributes to your idea of a relationships repository), but in the
practice there may be more opportunities for relating the content, not just
the update of my objects. For example, when "another" object is created.
Portal_relationships should have a policiy about this.
> + To query for all objects consituting a dependency
> - Utility for workflow guard conditions, to make
> sure that if object X is depending on object Y, that
> Y be in a published state.
> - Is this flexible enough for varying workflows???
The most difficult part but it's quitaessential to the whole proposal.
> - How to deal with cyclical dependencies???
There may be more than a single type of dependencies. A cyclical one would
come up when two objects could be considered father and child in both
directions, right?. Well, that would not be a problem if tied to the
relationship information is the referral subject/object. Normal searches
would ignore this information, but those aware of the subject in scope would
retrieve the right dependencies.
> + To somehow provide the ability to lookup related content
> objects from the following sources:
> - Based upon explict stored relationships, either
> stored within the content object or the
> relationship tool's internal registry
> - Based upon Catalog queries for content with similar
> data in a particular field in content data or
> metadata. (i.e. Items with same keyword in subject,
> or items with same byline or dateline, etc)
If an author wants to relate things by picking up objects selectively, he
can store that list in the tool. That's a good idea, although in my concept
that special kind of relationship would be spread over all the objects
involved, at a portal_membership command, and therefore they could be
retrieved by a regular query to the catalog. Portal_membership should have
the permission to reindex objects, according to the workflow and with
respect to its own internal policies.
> ==> Use query templates (slightly more dynamic
> than canned-queries like Topic)
> ==> Must provide the ability to drop in these
> query templates for storage.
> - Inverse relationships inferred from relationships.
> ==> if X "has part" Y, then logically, Y
> "is part of" X, but we shouldn't have
> to store this relationship twice. It
> would be stored in the first case, but
> could be queried dynamically in the
> second.
Already treated above.
> ==> Perhaps the catalog could be leveraged to
> provide an underlying implementation.
> + Allow skins to provide Source() and Relation() methods
> for content types that do not understand such things,
> leveraging queries to this tool to provide the data
> to populate the return values of such methods.
Yes. One of the most difficult things to conceptualize is at which level
anyone or anything is able or authorized to process my objects, right?. If
we solve that, then sooner or later all the objects will be related to
everyone. If portal_membership is allowed to store new information within
one of those not-relationships-aware objects then that object would become a
relationship-info generator too. It may sound anti-secure but that's how
things happen in real life. I'd like to say there are easier ways to do
this, but appart from some of those third-party tools that calculate
relationships between different unstructured objetcs (just aproximately and
based on complex mathematical algorithms), there aren't many other
alternatives to handle the problem in a reliable way.
>
>
> Sean
>
Just my two cents. :)
Ausum
> -----Original Message-----
> From: Ausum Studio [mailto:ausum_studio@hotmail.com]
> Sent: Monday, October 07, 2002 3:17 PM
> To: zope-cmf@zope.org
> Subject: Re: [Zope-CMF] Future CMF
>
>
> 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
> >
>
> _______________________________________________
> 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
>