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 -- Scott Prater Library, Instructional, and Research Applications (LIRA) Division of Information Technology (DoIT) University of Wisconsin - Madison [email protected] ------------------------------------------------------------------------------ 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
