This is terrific, Richard. I look forward to hearing more.
Thanks much,
- Bill
On Jan 28, 2009, at 3:59 AM, Richard Green wrote:
Bill (and others)
I like the idea of a BOF at OR09. Some of you may recall that we
floated the idea of a registry of BDefs and BMechs at OR07 but this
effort stalled, not least because of the news of the CMA in the
coming Fedora 3.
I think I mentioned in a previous mail that the Hydra Project (Hull,
Stanford and Virginia with Fedora Commons) is developing some
generic materials and these include content models for ‘common’
objects and the SDef/SDeps to go with them. We have a number under
test at the moment. I’m pretty certain that we shall share these
with the community as soon as we have done some serious testing with
them – OR09 would probably be just about the right timing. (Note
these are my opinions, I haven’t consulted the others
specifically.) Our intention would be that these would then be
available from somewhere in the Fedora Commons web sites’ structure.
The Fedora wiki has recently been given a placeholder for the Hydra
Project (bottom left of the dashboard). I will make a commitment to
get the space populated with public details of the project and
something about its potential outputs to the community in the next
fortnight. I’d do it sooner but (a) I’m snowed under with work at
the moment and (b) several key Hydra people are unavailable this
week and I’d want to check the essence of the proposed text with
them first.
Richard
___________________________________________________________________
Richard Green
Manager, RepoMMan, RIDIR and REMAP Projects
e-Services Integration Group
www.hull.ac.uk/esig/repomman
www.hull.ac.uk/ridir
www.hull.ac.uk/remap
http://edocs.hull.ac.uk
From: Bill Parod [mailto:[email protected]]
Sent: 27 January 2009 23:27
To: Gramsbergen, Egbert
Cc: Fedora Commons
Subject: Re: [Fedora-commons-users] Content Model question
These all seem like good reasons to float some 'out of band'
agreements on cmodels - towards the registry idea. We could probably
get a BOF or other event scheduled (if not already on the agenda)
for the OR09 / Fedora Days meeting. We can also share / develop some
models and work in that direction in the mean time. Is there a forum
or natural place to collect such things on the wiki or elsewhere?
- Bill
On Jan 27, 2009, at 4:38 PM, Gramsbergen, Egbert wrote:
Hi,
I found out by experiment that if more Service Deployments apply for a
given data object plus Service Definition (this might be because the
data object subscribes to more Content Models but not necisarily so),
you will receive an error message because the system cannot decide
which
one to use.
Maybe(?) future versions will have inheritance in Content Models, so
the
system would be able to choose the most "specific" SDep in some of
these
cases.
Egbert
________________________________
Egbert F. Gramsbergen
TU Delft (Library) - Digital Product Development
[email protected] +31(0) 15 27 82922
________________________________
-----Original Message-----
From: Scott Prater [mailto:[email protected]]
Sent: Tue 1/27/2009 4:09 PM
To: Bill Parod; Fedora Commons
Subject: Re: [Fedora-commons-users] Content Model question
From the horse's mouth...
"A Data object may assert a hasModel relationship to multiple CModel
objects. Such a Data object should conform to all of its Content
Models,
containing an aggregation of all the Datastreams defined by the
Content
Models. If two or more Content Models define Datastreams which have
the
same name but different characteristics, no well-formed Data object
can
be constructed and likely the repository will be unable to deliver its
content or services."
http://fedora-commons.org/confluence/display/FCR30/Fedora+Digital+Object+Model#FedoraDigitalObjectModel-ContentModelObject
I haven't found anything that mentions how Fedora handles digital
objects that belong to Content Models with the same or similar SDefs
but
different deployments, however.
-- Scott
Scott Prater wrote:
> Hi, Bill --
>
> Yes, my sense reading the Fedora docs and wiki is that the CDMA is
> designed primarily to enable Content Model reuse and sharing, by
making
> them as modular as possible. This, I think, is the whole point of
the
> mix-in idea, the ability to subscribe a digital object model to as
many
> Content Models as is necessary to adequately describe the object
and its
> behaviors, but no more. One of the great things about this mix-in
> approach is that someone else (such as you) could take my objects,
> import them, and add/override more Content Models to them to
refine them
> even further.
>
> One danger we've discussed here, though, is what happens when
Content
> Models begin to step on each other. We haven't tested this out
yet, but
> what happens if Content Model A implements foo(), and Content
Model B
> also implements foo(), and digital object Bar is a member of both
A and
> B? Which implementation of foo() gets executed? Or, in the case of
> datastreams, what happens if Content Model A says the object must
> contain a datastream FOO of mime type text/xml, and Content Model
B says
> the object must contain a datastream FOO of mime type text/html?
Which
> (if any) constraint is applied to digital object Bar?
>
> A wide, rich plethora of atomistic Content Models can open
yourself up
> to that kind of confusion. That would be something that would
need to
> be taken into account also when designing a shareable Content Model
> registry -- anyone who implements your Content Models will need to
know,
> preferably up front, if your Content Models are going to overlap
with
> theirs.
>
> -- Scott
>
> Bill Parod wrote:
>> This has been a real interesting discussion. It brings up a design
>> principle I've wondered about with CMDA: Does one view cmodels for
>> data integrity or service readiness? That is, if you're using
cmodels to
>> enforce object completeness (data integrity), you might be
inclined to
>> express rich cmodels that thoroughly describe complex objects.
However,
>> if your goal is to maximize your objects' reusability (service
>> readiness), you might be inclined to express multiple cmodels
that are
>> simpler with minimum datastream requirements so that a given
object is
>> more likely to match requirements for more services. I've been
tending
>> toward the latter approach since CMDA. I think this is in the
spirit of
>> what Scott suggested, (is that right, Scott?) but with premium on
>> satisfying likely service opportunities.
>>
>> Of course, one can go both ways, declaring complex cmodels for
>> integrity, profiling, or more demanding service requirements. And
also
>> break those out simply to enable contractual promiscuity. So
maybe this
>> is a non-issue.:) But if there's community potential for cmodel and
>> service registries, it might be good to map this out a bit and
see where
>> there are natural cmodel/service agreements/opportunities. Are
there
>> other trade-offs to consider? How are others approaching this?
>
--
Scott Prater
Library, Instructional, and Research Applications (LIRA)
Division of Information Technology (DoIT)
University of Wisconsin - Madison
[email protected]
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Fedora-commons-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword_______________________________________________
Fedora-commons-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
*****************************************************************************************
To view the terms under which this email is distributed, please go
to http://www.hull.ac.uk/legal/email_disclaimer.html
*****************************************************************************************
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Fedora-commons-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
