Complete the Hydra::PCDM::Sandwich about hydra-pcdm HOT 10 CLOSED

Based on #7 and #8, is this really Hydra::PCDM::Collection? Or something else?

from hydra-pcdm.

@jpstroop This is the interface that allows you to define a collection of your own. This is a module so we can create our objects with only one inheritance (AF:Base) and compose or relation behaviors.

from hydra-pcdm.

Gotcha, thanks. But then

Should be able to aggregate GenericWorks

Shouldn't that be PCDM::Objects?

from hydra-pcdm.

Should be able to aggregate PCDM::Objects. Please keep a clear separation of concerns between PCDM and Sufia's use of it.

from hydra-pcdm.

@azaroth42 The implementations should be allowed to apply restrictions to the model. The model interface should do nothing that would prevent the user from doing that. Why not create an instantiation example that tests some of the features people may have. If we only test the ideal case, we may make it hard to make edge cases.

@azaroth42 @jpstroop Now that we are using the Sandwich model for testing instead on the Sufia model to test the concept maybe that will allow us to focus on the technology and not the naming.

from hydra-pcdm.

Let's try to keep this constructive, please.

I regret not being able to attend the session with you yesterday; this could all just be a lack of understanding of intentions on my part based on the tickets that have been created. To me this looks like a scope issue, not a naming issue. Is the intention that GWork and GFile or Meat, Bread, and Cheese be defined as RSpec subjects only?

I do think separate interfaces that reflect the PCDM document are a great idea. However, in the 'hydra-pcdm' repository I'd ultimately expect to find a concrete base implementation of the PCDM classes, i.e. as subclasses of AF:Base that include the associations defined in the PCDM model, so that one can do what @mjgiarlo suggests in #7, here, and mix in custom behaviors that are appropriate to the local subclass or context. And why wouldn't those base models be called Collection, Object and File?

Does that make sense?

from hydra-pcdm.

@jpstroop I am trying to be constructive and not just about naming. Our intent was obviously not clear. Making it a model no one would use allows us to think in the abstract.

There is no intent to make concrete classes that people would inherit from as those classes would already inherit from ActiveFedora Base. That would then make any additional implementing classes such as a Sufia::PCDM::Work have a two deep inheritance chain, which break the single deep inheritance rule that we were trying to follow per @jeremyf advice.

That said you need to test in the concrete, not in the abstract to having concrete classes for example and testing purposes seemed like a good idea. It is possible that those could live in spec support, but we thought it would be nicer to have them out in the open.

I really an not sure how to avoid the confusion between the model and concrete examples if they are named the same thing, ergo the sandwich model that no one could possible mistake.

We did try to use a real life example but that cause a fire storm of indignation.

from hydra-pcdm.

Ok, thanks, that helps a lot.

I agree with @jeremyf in principal, but I do wonder if it makes sense in this case.

Faced with principals (i.e. no two-deep inheritance) vs code that is still very general, simple, l useful, and reusable, I think I'd prefer the latter, though I'd be happy to discuss it more.

-Js

Sent via mobile. Please excuse typos, brevity, etc.

from hydra-pcdm.

Now that I'm not typing on my phone...I think going two-deep below any one of Object, File, or Collection could be a mistake. However, if the goal is to create a base model that allows us to share core functionality across applications, we shouldn't each have to implement the core models separately.

from hydra-pcdm.

+1 to having useful, reusable code that breaks arbitrary principles, over sticking dogmatically to questionable and overly constraining ideals.

from hydra-pcdm.