Hi Matt,
Thanks for the usual speedy response. I'm really excited to hear that 509 and 501 are in the works. And while I agree that support for disseminator "creation" is probably not necessary in the near future (there usually aren't that many to create anyway, you can create them using the Fedora client fairly easily, etc), there are a couple of features that we -do- have usecases for today that are not explicitly referred to in 509. I don't know if you want to call these features "read support" for disseminators or "extended read support", but they all involve how ruby-fedora/active-fedora read data out of Fedora.
For instance... So, having ruby-fedora provide an accessor to a disseminator is a terrific and necessary bit of plumbing. But I think ideally, if you create an object in active-fedora, you should be able to assert in the RELS-EXT that it subscribes to a (pre-existing) contentModel (fedora-model:hasModel), that the content model has a service definition (fedora-model:hasService), that the content model has a service deployment contractor (fedora-model:isContractorOf), and that the serviceDeployment is a deployment of the service definition (fedora-model:isDeploymentOf). (Among other issues blocking us from doing this in AF currently, none of these Fedora system level relations are available in the pre-defined list of RELS-EXT relations in ActiveFedora's "semantic_node.rb" - probably because they don't appear to be in the RELS-EXT rdf ontology either.)
When you define these "special relationships", ideally ActiveFedora would check to make sure the CMs and sdef/sdeps with the PIDS/names you described actually exist in Fedora. And if they DO exist, generate a whole new set of Ruby accessors for the ActiveFedora objects that would effectively insure that you were getting at the object via the disseminator.
Why, you ask, might you want to do this? Well, the general argument is that I think this would more or less bring ActiveFedora into "full" compliance with the Fedora content model architecture. But if you want a specific usecase, imagine that you want to use a particular content model/dissemination as a site of secure control over your data, as you will soon be able to do with FESL, if I understand that work correctly. So, in that instance, you're going to probably want to lock down -direct- access to your objects' datastreams and make available only certain fields, through a dissemination. In that instance, the ActiveFedora code is going to throw errors because its basic way of getting at the data is being blocked by Fedora. If a developer wants to write robust code, using the "low level" ActiveFedora access to the raw datastreams is a bad way to go.
-Nathan
--
//////////////////////////////////////////////
Nathan F. Piazza
nathan...@gmail.commobile:
404.713.1829\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\