Short answer: You have the sense though with a few additions.
Even RELS-EXT as a datasteam is "hidden". However, its information is accessible as a durable, public, essential characteristic of an intellectual entity persisted using Fedora. (More words may everything more clear don't they). But you have it right, we need services (aka disseminators) as an abstraction layer in the long run. We need other stuff to make them easy to use. --- Long answer: For "public" meaning durable URIs and durable semantics, everything about objects and their content objects (including RELS-EXT) is best accessed through disseminators (now called services/methods) via the getDissemination API calls or something replacement call like it. This enables access to objects which can be very stable and evolve gracefully. Unfortunately, the implementation and tools in Fedora to make this easy to use and to work well is incomplete. It is harder work to implement an architecture which is designed to evolve---it is much easier to make simplifying assumptions. Having the right abstraction layers is a key part of the design. Sometimes we need to work with concrete object instances and their innards as containers plus we sometimes have to work with the stuff in the containers because we need to "manipulate" the object. One of the most important containers inside a Fedora object is the datastream (I am talking about the XML wrapper not the content). So we need APIs which can see past the abstraction layers and work with the object and content as currently implemented. The APIs for manipulating the object must be allowed to evolve much faster than aspects of the architecture optimized to provide durable access. You can write access applications which use interfaces that are designed for manipulating the objects but don't be surprised if durable access to your content gets broken in the future. You will see another thread about datastreams and datastream disseminations. These are kind of "in-between" durable and implementation-dependent parts of the architecture which makes discussion about them tough. I think Fedora has the best potential out there for balancing the tradeoffs needed for durability with practical application development but it is incomplete. Some debate in this thread is to flesh out these tradeoffs because we will have to compromise to get from where we are now to where we need to go. Daniel W. Davis http://fedora-commons.org [email protected] Scott Prater wrote: > I've been following this thread with considerable interest... (and > catching up with it after a few weeks vacation): > > So, to summarize what I think Daniel Davis is recommending, as it > applies to developers writing disseminators: > > * datastreams should only be exposed via a disseminator (not accessed > directly, although the capability is there to do it) > > * RELS-INT info should be "hidden", i.e., the disseminator, not the end > user, will access that datatstream, if needed to gather information > about the object's other datastreams as needed to create a public view > for the entire object. > > * RELS-EXT, conversely, is the public face of the object: the > relations expressed in RELS-EXT should not change, or change > infrequently; those relations should not be broken if a RELS-INT > relation changes or disappears, or the datastreams change. > > * RELS-INT should not point to RELS-INTs or datastreams in other > objects; they should only point to RELS-EXTs or disseminators in other > objects. > > Does that sound correct? > > as an aside, Asger commented: > > > I have a general problem with the Fedora API, which is perhaps > > understandably, given that I am the guy with the > > EnhancedContentModels. The API is object centric, not class centric. > > You can get the list of methods/services on an object, but there is no > > easy or even hard way to get the list of services implied by a content > > model. > > As such, you have individual objects, decorated with services, not > > classes of objects. > > So, the one method that I would really like to see would, on a content > > model, give me the list of services that the subscribing data objects > > would have. > > I don't have such a problem with the the API being object-centric; it's > more of a technical problem than a philosophical one, I think. A class > is simply a another kind of object (in this case, a content model). It > is possible, though not easy, to determine what methods (disseminators) > are available for a given content model by tracking via RDF queries the > service deployments that are contractors of that model and are also > deployments of its service definitions. I would also like to see that > hunting and scavenging encapsulated in a nice standard API call, though. > > -- Scott > > ------------------------------------------------------------------------------ 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
