create the following directory structure in Hydra::PCDM

\lib\hydra\pcdm\services
     \collection
     \object
     \file

Hydra::PCDM::Interfaces::Object (this is a module)
Should be able to contains pcdm:File using the pcdm:hasFile (eg Hydra::PCDM::GenericFile)

• The files should live at a sub uri of the pcdm:Object (This is AF::Base contains)
• There should be a pcdm:has_file assertion on the object that points at the file (This is AF::Base:has_and_belongs_to_many)
• This task should figure out how to combine the behaviors above
• There can be zero to many files
• the path to the file subnode can be auto generated

Related objects are ore:aggregates.

It should allow us to query the hasMembers aggregate relationship to only include one object type, Meat or Cheese, not both

I saw this code in the collection:

# configure :type => RDFVocabularies::PCDMTerms.Collection  # FIX: This is how ActiveTriples sets type, but doesn't work in ActiveFedora

It can now be written as:

  type RDFVocabularies::PCDMTerms.Collection 

Update https://github.com/projecthydra-labs/hydra-pcdm/blob/master/lib/hydra/pcdm/vocab/pcdm_terms.rb to use a generated vocabulary.

Review the PCDM domain model page and confirm that all RDF properties are correct

Create modules
Hydra::PCDM::Interfaces::CollectionInterface (this is a module)
Should be able to aggregate pcdm:Objects using the pcdm:hasMember (eg Hydra::PCDM::GenericWork)
Should be able to aggregate pcdm:Collection using the pcdm:hasMember (eg Hydra::PCDM::Collection)

• Should not be able to contain files
• There can be zero to many Objects
• There can be zero to many Collections

The aggregates method signature should handle classnames, predicates, etc in ways that conform to the ActiveModel Associations options and defaults and (where applicable) ActiveFedora::Associations options and defaults

Examples

aggregates :objects, :class_name => Hydra::PCDM::Object, :predicate => “hasMember”

• objects = the generated method that will be used like… collection1.objects = [pcdm_object1, pcdm_object2]
• pcdm_object1 and pcdm_object2 are expected to be of type Hydra::PCDM::Object or a subclass

In Fedora, the predicate hasMember will be used to connect collection1 with pcdm_object1 and pcdm_object2

For Hydra::PCDM::Collection, this will allow the following statements

aggregates :collections, :class_name => Hydra::PCDM::Collection, :predicate => "hasMember"
aggregates :objects, :class_name => Hydra::PCDM::Object, :predicate => "hasMember"

For Hydra::Works::Collection, this will allow the following statements

aggregates :collections, :class_name => Hydra::Works::Collection, :predicate => "hasMember"
aggregates :generic_works, :class_name => Hydra::Works::GenericWork, :predicate => "hasMember"

Background (from lynette):

Currently, activefedora-aggregation's aggregates method takes a symbol representation of a classname. Ex. From association_spec, in the statement aggregates :generic_files, :generic_files is the symbol for the GenericFile class. This creates a new method on the class called generic_files so that you can do the following: image.generic_files = [generic_file1, generic_file2] where generic_file1 and generic_file2 are instances of GenericFile.

BUG: I was not aware the parameter to aggregates was a class symbol when I began writing the code, so you will see in my code the use of the symbol as the relationship :members. Obviously, this doesn’t work because there is not a Member class.

Challenge: I was not able to find a way in Ruby to convert a classname with modules to a simple symbol. For ex., what is the symbol for Hydra::PCDM::Object?

Include the Hydra::PCDM::Interfaces::Object

Should be able to aggregate Meat & Cheese
Should not be able to contain Condiments
Should not be able to aggregate Bread
(future) Should be able to aggregate Bread

Need: ability to validate a collection or object from services and tests

Recommendation:

• change Collection's collection? method to a class method
• move Collection's object? method to PCDM::Object and make it a class method
• have all validations call the class methods

from hydra-access-controls

create the following directory structure in Hydra::Works

\lib\hydra\works\services
     \collection
     \generic_work
     \generic_file
     \file

https://travis-ci.org/projecthydra-labs/hydra-pcdm/jobs/62103870#L232

 RegexpError:
       premature end of char-class: /\A[\x20-\x21\x23-\x5B\x5D-\x7E]*\z/m

Create Hydra::PCDM::Interfaces::ObjectInterface

Should be able to aggregate pcdm:Objects using the pcdm:hasMember (eg Hydra::PCDM::GenericWork)

Should not be able to aggregate pcdm:Collection (eg Hydra::PCDM::Collection)

# Upload a file to a generic file, optionally running auto-generation services to create variants.
#
# @param [Hydra::Works::GenericFile] :generic_file into which to upload the file
# @param [String] :path_to_file path to the file being uploaded
# @param [Hash] :auto_gen_services info for auto-generating files from the uploaded content file
#
# @return [Hydra::Works::GenericFile] the updated generic file

Questions:

• A generic_file is defined as one content file + variants that are auto-generated. Do others agree?
• If the generic_file already has files, is the new file considered a new version of the existing content file?
• What predicate should be used for identifying the purpose of the uploaded content file and each auto-gen file? (e.g. use - what is the full URI?)
• What values should be used for the 'purpose' predicate? (e.g. file.use = "content" | "thumbnail" | "extracted_text")

This adds an additional restriction to #23 and prevents such as:

collectionA includes collectionB,
collectionB includes collectionC,
collectionC includes collectionA (no!)

Get member_ids of each collection and object, which doesn't instantiate the objects, and classify them (Object vs. Collection) by querying solr for their types.

Include the Hydra::PCDM::Interfaces::Collection

Should be able to aggregate Bread
Should not be able to contain Condiments
Should not be able to aggregate Meat & Cheese
(future) Should be able to aggregate Sandwich

ie. How do you indicate which File is the thumbnail, which is the "Content", etc.?

Depends on: #44

Add service:

\lib\hydra\pcdm\services\collection\create.rb

See pcdm:File spec

Note: Enforcement of Behavior Rules is handled in #23. Talk to @awead about what you need to do in your implementation to support that.

Existing Code: https://github.com/projecthydra-labs/hydra-pcdm/tree/feature_initial_model/lib/hydra/pcdm/models Currently on the feature_initial_model branch, but soon to be merged into master.

Depends on: #44

Add service:

\lib\hydra\pcdm\services\collection\add_collection.rb

In https://github.com/projecthydra-labs/hydra-works/blob/gen_work_has_gen_files/spec/models/hydra/works/generic_file_spec.rb calling contains= raises

 Failure/Error: generic_file.contains = [file1, file2]
     NoMethodError:
       super: no superclass method `contains=' for #<Hydra::Works::GenericFile:0x007ff0d70dba68>

See samvera/hydra-works#58

Include the Hydra::PCDM::Interfaces::Object

Should be able to contain Condiments
Should not be able to aggregate Sandwich
Should not be able to aggregate Bread

<< works at active fedora level and is implemented correctly in pcdm. The tests do not test it correctly.

coll1.collections << coll2 # not supported
coll1.objects << obj1 # not supported
coll1 << coll2 # is supported
coll1 << obj1 # is supported

This may not be as clear to the end user. But it is operational now. Tests are being updated to reflect what is supported.

Sufia wants to have a file that extends FileContentDatastream. Primarily it needs to version the content (see https://github.com/projecthydra/sufia/blob/pcdm/sufia-models/lib/sufia/models/file_content/versions.rb) Can we make that optional?

run bundle gem hydra-pcdm
change license to Apahce2
Add contributor document

Create the following Model Classes:
Hydra::PCDM::Condiment (will be an Non RDF source)
Hydra::PCDM::Cheese (will include PCDM::Object)
Hydra::PCDM::Meat (will include PCDM::Object)
Hydra::PCDM::Bread (will include PCDM::Object)
Hydra::PCDM::Sandwich (will include PCDM::Collection)

They should inherit from active fedora base

In Hydra::PCDM::CollectionBehavior, with aggregates :members produces a URI like:

/fedora/rest/test/09/27/90/91/09279091-559f-4505-89af-93ae9216949c/files

Shouldn't this be:
http://localhost:8983/fedora/rest/test/09/27/90/91/09279091-559f-4505-89af-93ae9216949c/members ?

Modify type specific setters to return AssociationProxy which reponds to #=, #==, #<<, etc

Example change for Collection...

AssociationProxy.new(self, :collections)

Also remove the companion setter methods.

This is dependent on duraspace/pcdm#7, but once merged, these definitions can be added to RDFVocabularies and have additional validators such as Hydra::PCDM.thumbnail?.

See https://github.com/projecthydra/active_fedora/blob/master/lib/active_fedora/file.rb#L119-L121
https://github.com/projecthydra/active_fedora/blob/master/lib/active_fedora/with_metadata/metadata_node.rb

This will be similar to Meat, but should allow us to test just getting the Meat, or just getting the Cheese that is between the bread on a sandwich.

It should include Hydra::PCDM::Interfaces::ObjectInterface

You likely want Objects to solrize their members.

Create Hydra::PCDM::Interfaces::CollectionInterface

Should be able to aggregate pcdm:Collections using the pcdm:hasMember
Should be able to aggregate pcdm:Objects using the pcdm:hasMember

Should not be able to contain pcdm:File

That way current hydra-access-controls could continue to use what they have and hydra-pcdm users would get that functionality too.

See specifications for PCDM::Object and PCDM::Collection

Note: Enforcement of Behavior Rules is handled in #23. Talk to @awead about what you need to do in your implementation to support that.

Existing Code, which includes some notes about implementation: https://github.com/projecthydra-labs/hydra-pcdm/tree/feature_initial_model/lib/hydra/pcdm/models Currently on the feature_initial_model branch, but soon to be merged into master.

See test hydra/pcdm/services/collection/add_related_object_spec.rb test: it 'should solrize member ids'
See test hydra/pcdm/services/object/add_related_object_spec.rb test: it 'should solrize member ids'

Those tests currently check that the objects and collections were solrized, and that related objects are not part of the objects and collections index. Should there be a related_objects index?

Files don't appear to have ids and therefore are not tested for inclusion in an index. Is that correct?

Note: If it's not possible to enforce these rules on Files for some reason, call it out on the scrum.

Object Behavior Rules

• Hydra::PCDM::Object can aggregate (pcdm:hasMember) Hydra::PCDM::Object
• Hydra::PCDM::Object can aggregate (ore:aggregates) Hydra::PCDM::Object (Object related to the Object)
• Hydra::PCDM::Object can contain (pcdm:hasFile) Hydra::PCDM::File
• Hydra::PCDM::Object can contain (pcdm:hasRelatedFile) Hydra::PCDM::File
• Hydra::PCDM::Object can NOT aggregate Hydra::PCDM::Collection
• Hydra::PCDM::Object can NOT aggregate non-PCDM object
• Hydra::PCDM::Object can have descriptive metadata
• Hydra::PCDM::Object can have access metadata

File Behavior Rules

• N/A - PCDM::File can NOT aggregate anything (no aggregation, so nothing to test)
• N/A - PCDM::File can NOT contain PCDM::File (no contains association defined, so nothing to test)
• PCDM::File can have technical metadata about one uploaded binary file

Collection Behavior Rules

• Hydra::PCDM::Collection can aggregate (pcdm:hasMember) Hydra::PCDM::Collection
• Hydra::PCDM::Collection can aggregate (pcdm:hasMember) Hydra::PCDM::Object
• Hydra::PCDM::Collection can aggregate (ore:aggregates) Hydra::PCDM::Object (Object related to the Collection)
• Hydra::PCDM::Collection can NOT aggregate non-PCDM object
• Hydra::PCDM::Collection can NOT contain Hydra::PCDM::File
• Hydra::PCDM::Collection can have descriptive metadata
• Hydra::PCDM::Collection can have access metadata

At present, Travis is testing multiple Ruby versions 1.9 through 2.1, as well as jruby. Are all those needed? Perhaps we can just to 2.1 and 2.2? @jcoyne @elrayle ?

Add validation to prevent...

coll1.collections = [coll2]
coll2.collections = [coll3]
coll3.collections = [coll1]   # don't allow because already part of the collection path

When including Hydra::PCDM::File in another class, it won't set the rdf type because metadata isn't in an included block.

Depends on: #44

Add service:

\lib\hydra\pcdm\services\collection\add_object.rb

activefedora-aggregation's aggregates method can be used only once in an activefedora base class/sub-class. If using aggregates multiple times should work, then there is a bug.

Add links to PCDM documentation
Why this exists
And how to use it

ideally the << operator would work like...

coll1.collections << coll2
coll1.objects << obj1

But collections is a method and not a ruby object. A method cannot have the << operator.

Alternative is...

coll1 << coll2
coll1 << obj1