Adding optional sidecar FileSet class and related predicates

[escowles]

Objects always link directly to Files, but can also link to FileSets that link to Files:

• Current PCDM:

  <object1> a pcdm:Object ;
  pcdm:hasFile <file1> .
  
  <file1> a pcdm:File .

• Optionally add a FileSet as a sidecar:

  <object1> a pcdm:Object ;
  pcdm:hasFile <file1> ;
  pcdm:hasFileSet <fileset1> .
  
  <file1> a pcdm:File .
  
  <fileset1> a pcdm:FileSet ;
  pcdm:managesFile <file1> .

See also #68

[ruebot]

Do we need to also update the domain and range of hasFile and isFileOf? https://github.com/duraspace/pcdm/blob/d7464e541484f68f2213ab6e676de837bc44fd71/models.rdf#L69-L86

[whikloj]

@ruebot I don't think so, they should (and do) refer to the relationship between a pcdm:Object and a pcdm:File

[ruebot]

@whikloj ah, yeah, you're right.

See also "sidecar".

facepalm

[azaroth42]

:meh: Just makes life difficult for interoperability. I don't see the point compared to an Object that takes this role if it's not required.

[escowles]

@azaroth42 I think the advantage to this approach is that it can be completely ignored if your application doesn't care about FileSets. @tpendtragon also suggested the possibility of omitting the FileSet completely and linking between Files to establish the derivation chain, which you could use to figure out the groupings as-needed.

[cmharlow]

FWIW, not being a voting member or anything, my thoughts on this and #68. Looking at PRs (+ needs re:optional FS) on the table, I prefer this one, with the following points:

• this avoid some of the possible conflation of Class definitions/usage by not having FileSet as a subclass of Object;
• I worry about the lack of community scoping on FileSets, and also when you'd use which (FS or no or both) in implementations, bc this opens up possible variance in query paths to get the same information (making my job harder).

On that last point, I'd like these questions answered or discussed really soon if this goes through, albeit I fully understand many are implementation-specific:

• How are we defining FileSet as a community? (Differences came up in the call)
• Based on above, updating profiling of FileSet / File to understand what metadata gets asserted where (technical metadata? access metadata?).
• Fileset membership expectations? (I know, best practices + impl. need but good to hash out)
• When do we recommend using FileSet versus not? (ditto)
• When we would see using both in the same instance data / application? (ditto)
• Discussed examples of proposed usage + diff impls graph sharing inputs/outputs
• Something on the table for easier graph sharing btwn FS use and non-use? i.e. logic or other that tells datastores this:

pcdm:Object pcdm:hasFileSet pcdm:FileSet pcdm:managesFile pcdm:File

depending on the implementation, has this shortcut or mapping:

pcdm:Object pcdm:hasFile pcdm:File

My notes on both PRs where I worked through examples and thoughts, in case of interest: https://gist.github.com/cmh2166/5e435300a246e3406d9ff0db04cecde2

[cmharlow]

Sorry to have stalled the communication. Ignore my comments / questions as needed!

[escowles]

My thoughts on @cmh2166 's questions:

• I agree that there's not a good definition, and I hope the FileSet group that @scossu is kicking off will help define what a FileSet is.
• For implementation, one option is to have the FileSet be completely separate from the Object/File and just link to the Files to indicate that it manages/groups them. This would allow a File to be in multiple FileSets, and FileSets to manage Files across multiple Objects, etc., etc.
  • The other option would be to have the FileSets be the DirectContainers containing the Files. So to have multiple FileSets, you would create multiple containers. This has the advantage of managing the Files using LDP direct containment, and also avoids creating any extra nodes (perhaps assuaging concerns about performance?). This would enforce a strict hierarchy of Objects to FileSets to Files and not allow the many-to-many mapping the previous option would allow.
• For metadata, I think the boundary between technical metadata and other sorts is always a little blurry. But I'd say that the FileSet should include only technical metadata, such as creation date, digitization/capture event, and possibly some kind of type to indicate which FileSet is preferred (something akin to the File Use Vocab to help differentiate multiple FileSets).
  • I'm not sure if access metadata would be helpful on a sidecar FileSet. If you can access the Files directly, then it seems like controlling access to the FileSet would just obscure some relationships and event info — do we have a use case for that?

[escowles]

Closing this old PR since there was never consensus on these issues.