include PCDM semantics

[ghukill]

Though Fedora uses the rules and interactions of LDP, the Portland Common Data Model (PCDM) is increasingly becoming the abstract, opinionated model of choice for objects in a digital repository. Would it be possible to include?

Might be a good candidate for some kind of plugin (#33 ). Thought of another way, perhaps blueprints or a series of patterns that would guide users into creating resources that were PCDM inspired and compliant.

[ghukill]

Making some headway, but might require changing how determining resource type with methods like repo.get_resource.

Originally, relied on values from Link header in a HEAD request for the resource in question. This would return results like:

'Link': '<http://www.w3.org/ns/ldp#Resource>;rel="type", <http://www.w3.org/ns/ldp#Container>;rel="type", <http://www.w3.org/ns/ldp#BasicContainer>;rel="type"'

But if envisioned plugins.pcdm.models.Collection or plugins.pcdm.models.Object were to extend models.DirectContainer, or other, this approach will not work: we cannot infer from HEAD request headers what possible extensions to the base NonRDFSource, BasicContainer, IndirectContainer, or DirectContainer it might better be retrieved as.

[ghukill]

One option: if HEAD request indicates it exists, we know we're going to issue a GET request for the resource metadata. In that case, could parse the resource's graph and get a more complete picture, parsing all rdf:type and looking for the most appropriate class to instantiate as.

However, this still would require "plugins" to somehow register their models for this parser that is currently attached to an API object, which also contains an instance of Repository.

It's conceivable that the Repository instance could import plugins? Or maybe going about this all wrong?

[ghukill]

Okay, taking a different tact for now.

Keeping the detection of LDP resource type under repo.get_resource(), as this will be useful in a variety of instances:

• resource type is not known, it will retrieve as a compatible one
• even if retrieving a PCDM-like resource, but do not explicitly pass that resource, will open as the appropriate LDP type that that PCDM resource type extends (e.g. PCDMObject extends BasicContainer), and basic functionality will still work

Difference is adding the ability to pass a known resource class when retrieving a resource if it's known in advance (which it often will be). For example:

# retrieve PCDMObject, explicitly retreiving as PCDMCollection resource type
pcdm_col = repo.get_resource('pcdm_col', resource_type=PCDMCollection)

In [5]: type(pcdm_col)
Out[5]: pyfc4.plugins.pcdm.models.PCDMCollection

Work now on automatic creation of child resources for PCDM objects per PCDM spec and PCDM-in-LDP notes.

[ghukill]

Working example in pcdm branch: https://github.com/ghukill/pyfc4/blob/pcdm/pyfc4/plugins/pcdm/__init__.py#L11-L81

Creates a poe collection, and an intellectual raven object as part of it. Then, adds two page objects, with binary files. Demonstrates the automatic creation of structures /files, /members, /related/ and /associated. Also demonstrates adding resources to /files and /related, DirectContainer and IndirectContainer resources respectively, resulting in pcdm relationships being written and automatically tethering these resources.

TODO:

• Feel out what kind of convenience methods make sense for making related resources. Imagining something along the lines of adding files, relating, adding members, etc. Would want to find a balance between convenience and not being too prescriptive (e.g. methods that allow for parameters, or building out the resource more step-by-step and explicitly).
• add method .delete() to PCDMCollection and PCDMObject that will delete all associated resources.
  • see this really interesting API-X extension from Amherst: https://github.com/birkland/repository-extension-services/tree/apix-demo/acrepo-exts-pcdm

[ghukill]

This approach is feeling like it might work. Closing this larger question of an issue, opening new ones as needed.