Hi,

Very interesting discussion indeed. I was wandering - when talking on 
inheritance of CModels would you actually inherit information of both 
the structure of digital objects or this would refer only to service 
definitions?

Cheers,
Natasa


-- 
Natasa Bulatovic
Max Planck Digital Library (MPDL)
Amalienstrasse 33
80799 Munich, Germany
http://www.mpdl.mpg.de

e-Mail: [email protected]
phone: +49-89-38602-223
fax: +49-89-38602-280



[email protected] wrote:
> Send Fedora-commons-developers mailing list submissions to
>       [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>       https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>
> or, via email, send a message with subject or body 'help' to
>       [email protected]
>
> You can reach the person managing the list at
>       [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Fedora-commons-developers digest..."
>
>
> Today's Topics:
>
>    1. Re: Content Model Inheritance (Asger Blekinge-Rasmussen)
>    2. Re: Content Model Inheritance (Chris Wilper)
>    3. Re: Content Model Inheritance (Bill Branan)
>    4. Re: Content Model Inheritance (Daniel Davis)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 9 Jul 2009 09:57:45 +0200
> From: Asger Blekinge-Rasmussen <[email protected]>
> Subject: Re: [Fedora-commons-developers] Content Model Inheritance
> To: Daniel Davis <[email protected]>
> Cc: "[email protected]"
>       <[email protected]>
> Message-ID: <1247126265.3837.17.ca...@abr-laptop>
> Content-Type: text/plain
>
> Hi
>
> First up, my initial proposal was just the factor out the way find the
> content models for a object into a method, rather than directly querying
> the relations. This should not in any way change the behaivour of
> Fedora. This would make ANY approach much simpler to implement later. 
>
> After that, yes, I would like some sort of inheritance system to be
> added. The exact form of this is still unclear.
>
> On Wed, 2009-07-08 at 17:41 +0200, Daniel Davis wrote:
>   
>> I must have mis-spoken in that I do believe the the "mix-in / trait" 
>> model is the most practical for the Fedora pattern. By static, I only 
>> meant the creation of the contents of a given model expression 
>> datastream.  In use by services, the mix-in (aggregation) and service 
>> binding needs to be fully dynamic.  I am wondering if Asger is asking 
>> the question of whether permitting having the "mixed-in" content models 
>> be derivations/extensions of other content models using some approach 
>> (like inheritance)?  Are the model expressions assembled at the moment 
>> of use?
>>     
> To be very clear, what I would like is a way, in the content models, to
> say
> "If you have me as a content model, it implies that you also have this
> other Content model"
> This statement is really the basis on which inheritance is built.
>
> I did expect the models to be assembled at the moment of use, but that
> was because I did not consider the static approach. 
>
>   
>> For simplicity and performance reasons, I am concerned with trying 
>> dynamically follow a chain of objects to assemble a model expression 
>> along a given inheritance path.  There would be a lot of latency caused 
>> by the object traversal.  Could the tranversal be done ahead of time and 
>> the combined model expression be stored in a datastream in a CModel 
>> object adjacent to a Data Object with asserting the "hasModel" 
>> relationship?  In Asger's proposal, are the models from different chains 
>> subsequently "mixed-in" (aggregated) at the last step before the Fedora 
>> Repo uses them particularly for service delivery?
>>     
>
> In the current system, the content models are mixed in before service
> delivery. I did not expect to change anything about this. I just
> expected to change the way Fedora determines which content models apply
> to a object. The mixing approach could actually remain as is.
>
> My initial idea was that inheritance could not work without the resource
> index, as the performance hit would be huge in traversing the graph.
> The static approach you mention could work. Fedora has a database
> server, wherein the inheritance graph could be stored. Any change to
> RELS-EXT in a content model updates this graph, but otherwise it is
> static.
> This would allow fast queries for the content models of a object.
>
> Regards
>
>
>
>   
>> Content models need information to use in object composition, 
>> validation, and service binding (does anyone have ideas for other stuff 
>> that should be in the model).  One question is whether the information 
>> is contained in one conceptually comprehensive model or divided up in 
>> pieces.  If divided up where should the model pieces reside (different 
>> DOs)?  And what are the rules for combining them in a distributed, 
>> Web-like architecture?  Pre-ingest composition and off-line validation 
>> are  not so sensitive to performance.   However, dynamic service 
>> delivery and on-line validation is very sensitive.
>>
>> I don't think inheritance and "mix-in" approaches are mutually exclusive 
>> approaches for Fedora but we need a good debate to see how they play 
>> out.  And using static creation of a model expression by gathering 
>> pieces in an inheritance chain, storing the result in a CModel, then 
>> using a "mix-in" of one or more model expressions from adjacent CModels 
>> in the last dynamic aggregration may be a way to combine both approaches.
>>
>> This note is already too long so I would like to start a separate thread 
>> on validation services if it is OK with you folks.
>>
>> Daniel W. Davis
>> Fedora Commons
>> http://fedora-commons.org
>> [email protected]
>>
>>
>>
>>
>> Benjamin Armintor wrote:
>>     
>>> The Fedora 3 CMA, as it stands, seems far closer to a mix-in or trait
>>> model of inheritance than a static, superclass-based one.  But it is
>>> incomplete here, as well, since there is no conflict resolution (that
>>> I know of) for conflicting service deployments.  Incorporating an
>>> actual inheritance structure into the content models would increase
>>> the potential for collisions, a la multiple static inheritance in
>>> other languages.
>>>
>>> I think the three-pronged summary of content models Daniel offers is
>>> useful.  It also makes me wary that a static approach to inheritance
>>> moves the focus of content models towards object composition, and I'm
>>> not sure that should be prioritized over service binding.
>>>
>>> I suppose my view of objects tends to be service-oriented, since my
>>> reaction to Daniel's comments about plug-ins was first to think object
>>> validation is a good plug-in candidate, and the second was to think
>>> that perhaps the validation should be bundled into services exposed by
>>> another object in the repository...
>>>
>>> - Ben
>>>
>>> On Wed, Jul 8, 2009 at 9:20 AM, Daniel Davis<[email protected]> 
>>> wrote:
>>>   
>>>       
>>>> I think an approach which is static should be considered.  In this
>>>> approach, the content models of superclasses are incorporated into the
>>>> content models which are stored in objects immediately adjacent to the
>>>> data object prior to use (a priori).  In some ways this is ORE inspired
>>>> where we confine ourselves to aggregations and avoid having to solve
>>>> graph closure problems in real time.  Using this approach, only one
>>>> operation is needed to obtain each adjacent content models which
>>>> contains all the inherited information from their superclasses (which
>>>> can be combined into one general operation to grab all the models as
>>>> suggested by Asger).  Using this approach dramatically reduces latency
>>>> for getting inheritance information especially if we begin to consider
>>>> federation where content model objects (and service definitions) may not
>>>> be co-located within the same Fedora repo instance.  Update of the
>>>> adjacent content models happens only when a change occurs to the
>>>> superclasses.  This approach would facilitate operation of Fedora
>>>> without requiring the use of a triple-store.
>>>>
>>>> To make the services (disseminations) fast an internal cacheing
>>>> mechanism is currently used.  Its operation needs to be considered in
>>>> the design.  Also, content models (with service definitions) serve (or
>>>> should serve) several purposes.  The first is service binding (most
>>>> latency sensitive), second validation (care needs to exercised here
>>>> regarding what operations are appropriate within the repository and what
>>>> can be done externally), and third object construction (which can
>>>> substantially be done outside the repository).  When and where these
>>>> functions happen need to be considered.
>>>>
>>>> If possible, adding additional methods can be done by extending system
>>>> content models and service definitions putting the operation on the
>>>> object rather than extending the APIs.
>>>>
>>>> This note is just discussion, I am not sure which is the best way to
>>>> support inheritance---a static or dynamic approach, with or without
>>>> triple-store assistance, and where to put the related methods.  But I
>>>> certainly support figuring out how to do inheritance.  Please consider
>>>> when the inheritance occurs, performance impact and how to mitigate
>>>> latency concerns, and how to minimize code changes.  In particular, I
>>>> think the Fedora Repo needs to move to a microkernel architecture where
>>>> as many functions as possible are pushed into plug-ins or loosely
>>>> coupled service bindings.  I hope this helps provoke additional discussion.
>>>>
>>>> Daniel W. Davis
>>>> http://fedora-commons.org
>>>> [email protected]
>>>>
>>>>
>>>>
>>>>
>>>> Asger Blekinge-Rasmussen wrote:
>>>>     
>>>>         
>>>>> Hi
>>>>>
>>>>> We, with the Enhanced Content Models, want to support content model
>>>>> inheritance. Due to the freedom for Fedora Content Models we can easily
>>>>> define a inheritance relation between content models, and inheritance is
>>>>> thus supported. No problem there.
>>>>>
>>>>> But only applications that understand this inheritance relation, can use
>>>>> this inheritance system. And, more importantly, disseminator bindings do
>>>>> not understand any sort of inheritance.
>>>>>
>>>>> I have checked the Fedora code. There are 32 usages of the reference
>>>>> Constants.MODEL.HAS_MODEL, to get the content models of a object. To me,
>>>>> this feels like something that should be collected in a general method,
>>>>> like getContentModels(pid) or the like.
>>>>>
>>>>> I would like to collect these usages, and make this general method, but
>>>>> only if work like this would be interesting to Fedora. This is not
>>>>> something that I would like to maintain myself, rather it should be
>>>>> integrated into the Trunk when the code have been approved.
>>>>>
>>>>> If this is a feature the Fedora Developers would like, I will start work
>>>>> on it soon.
>>>>>
>>>>> Regards
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Enter the BlackBerry Developer Challenge
>>>>> This is your chance to win up to $100,000 in prizes! For a limited time,
>>>>> vendors submitting new applications to BlackBerry App World(TM) will have
>>>>> the opportunity to enter the BlackBerry Developer Challenge. See full 
>>>>> prize
>>>>> details at: http://p.sf.net/sfu/Challenge
>>>>> _______________________________________________
>>>>> Fedora-commons-developers mailing list
>>>>> [email protected]
>>>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>>>>>
>>>>>       
>>>>>           
>>>> ------------------------------------------------------------------------------
>>>> Enter the BlackBerry Developer Challenge
>>>> This is your chance to win up to $100,000 in prizes! For a limited time,
>>>> vendors submitting new applications to BlackBerry App World(TM) will have
>>>> the opportunity to enter the BlackBerry Developer Challenge. See full prize
>>>> details at: http://p.sf.net/sfu/Challenge
>>>> _______________________________________________
>>>> Fedora-commons-developers mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>>>>
>>>>     
>>>>         
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 9 Jul 2009 11:39:21 -0400
> From: Chris Wilper <[email protected]>
> Subject: Re: [Fedora-commons-developers] Content Model Inheritance
> To: Asger Blekinge-Rasmussen <[email protected]>
> Cc: "[email protected]"
>       <[email protected]>
> Message-ID:
>       <[email protected]>
> Content-Type: text/plain; charset=UTF-8
>
> Hi Asger,
>
> On Wed, Jul 8, 2009 at 8:07 AM, Asger
> Blekinge-Rasmussen<[email protected]> wrote:
>   
>> I have checked the Fedora code. There are 32 usages of the reference
>> Constants.MODEL.HAS_MODEL, to get the content models of a object. To me,
>> this feels like something that should be collected in a general method,
>> like getContentModels(pid) or the like.
>>
>> I would like to collect these usages, and make this general method, but
>> only if work like this would be interesting to Fedora. This is not
>> something that I would like to maintain myself, rather it should be
>> integrated into the Trunk when the code have been approved.
>>
>> If this is a feature the Fedora Developers would like, I will start work
>> on it soon.
>>     
>
> Speaking for myself, I think having this as a formal method would be
> useful in terms of simplifying the code.  I like having the generic
> method whereby any (e.g. extensible) relationship can be found, but if
> it's something that Fedora is aware of anyway, it seems fair to have a
> specific method for it.  I suspect you were thinking of extending the
> DigitalObject and DOReader interfaces?
>
> - Chris
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 9 Jul 2009 12:22:11 -0400
> From: Bill Branan <[email protected]>
> Subject: Re: [Fedora-commons-developers] Content Model Inheritance
> To: Chris Wilper <[email protected]>
> Cc: "[email protected]"
>       <[email protected]>
> Message-ID:
>       <[email protected]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> This sounds like a perfectly reasonable refactoring to me, and all of the
> other discussion on this topic has shown that there are several options for
> building on top of this down the road. I say go for it.
>
> Bill
>
>
>   
>> First up, my initial proposal was just the factor out the way find the
>> content models for a object into a method, rather than directly querying
>> the relations. This should not in any way change the behaivour of
>> Fedora. This would make ANY approach much simpler to implement later.
>>     
> On Thu, Jul 9, 2009 at 11:39 AM, Chris Wilper <[email protected]> wrote:
>
>   
>> Hi Asger,
>>
>> On Wed, Jul 8, 2009 at 8:07 AM, Asger
>> Blekinge-Rasmussen<[email protected]> wrote:
>>     
>>> I have checked the Fedora code. There are 32 usages of the reference
>>> Constants.MODEL.HAS_MODEL, to get the content models of a object. To me,
>>> this feels like something that should be collected in a general method,
>>> like getContentModels(pid) or the like.
>>>
>>> I would like to collect these usages, and make this general method, but
>>> only if work like this would be interesting to Fedora. This is not
>>> something that I would like to maintain myself, rather it should be
>>> integrated into the Trunk when the code have been approved.
>>>
>>> If this is a feature the Fedora Developers would like, I will start work
>>> on it soon.
>>>       
>> Speaking for myself, I think having this as a formal method would be
>> useful in terms of simplifying the code.  I like having the generic
>> method whereby any (e.g. extensible) relationship can be found, but if
>> it's something that Fedora is aware of anyway, it seems fair to have a
>> specific method for it.  I suspect you were thinking of extending the
>> DigitalObject and DOReader interfaces?
>>
>> - Chris
>>
>>
>> ------------------------------------------------------------------------------
>> Enter the BlackBerry Developer Challenge
>> This is your chance to win up to $100,000 in prizes! For a limited time,
>> vendors submitting new applications to BlackBerry App World(TM) will have
>> the opportunity to enter the BlackBerry Developer Challenge. See full prize
>> details at: http://p.sf.net/sfu/Challenge
>> _______________________________________________
>> Fedora-commons-developers mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>>
>>     
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 4
> Date: Thu, 09 Jul 2009 14:49:23 -0400
> From: Daniel Davis <[email protected]>
> Subject: Re: [Fedora-commons-developers] Content Model Inheritance
> To: Chris Wilper <[email protected]>
> Cc: "[email protected]"
>       <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> This seems like an appropriate simplification to me.  I was thinking too 
> much about inheritance and this part of the discussion got lost in the 
> weeds in my head.
>
> Daniel W. Davis
> http://fedora-commons.org
> [email protected]
>
>
> Chris Wilper wrote:
>   
>> Hi Asger,
>>
>> On Wed, Jul 8, 2009 at 8:07 AM, Asger
>> Blekinge-Rasmussen<[email protected]> wrote:
>>   
>>     
>>> I have checked the Fedora code. There are 32 usages of the reference
>>> Constants.MODEL.HAS_MODEL, to get the content models of a object. To me,
>>> this feels like something that should be collected in a general method,
>>> like getContentModels(pid) or the like.
>>>
>>> I would like to collect these usages, and make this general method, but
>>> only if work like this would be interesting to Fedora. This is not
>>> something that I would like to maintain myself, rather it should be
>>> integrated into the Trunk when the code have been approved.
>>>
>>> If this is a feature the Fedora Developers would like, I will start work
>>> on it soon.
>>>     
>>>       
>> Speaking for myself, I think having this as a formal method would be
>> useful in terms of simplifying the code.  I like having the generic
>> method whereby any (e.g. extensible) relationship can be found, but if
>> it's something that Fedora is aware of anyway, it seems fair to have a
>> specific method for it.  I suspect you were thinking of extending the
>> DigitalObject and DOReader interfaces?
>>
>> - Chris
>>
>> ------------------------------------------------------------------------------
>> Enter the BlackBerry Developer Challenge  
>> This is your chance to win up to $100,000 in prizes! For a limited time, 
>> vendors submitting new applications to BlackBerry App World(TM) will have
>> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
>> details at: http://p.sf.net/sfu/Challenge
>> _______________________________________________
>> Fedora-commons-developers mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>>   
>>     
>
>
>
> ------------------------------
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
>
> ------------------------------
>
> _______________________________________________
> Fedora-commons-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>
>
> End of Fedora-commons-developers Digest, Vol 29, Issue 6
> ********************************************************
>   


------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Fedora-commons-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers

Reply via email to