Attendees

General

Agenda

  1. Define issue
    1. Need for flexible content-modeling
    2. Need for repository resource validation
  2. What proposals are on the table?
  3. Short-term resolution? Long-term resolution?

Minutes

Content Modeling

Stefano
  1. Use cases
    1. Assigning content model
      • Defining children and properties
      • This is provided (to some degree) by cnd
    2. Use a type to define behavior
      • Access policies
  2. Desire to not allow mixins to be removed
    • This is offered by primaryTypes
  3. There are limitations to cnd, as noted in the email thread
    • CND meets 90% of needs
    • Issue - wildcard properties
    • Issue - ranges of childern or properties are not supported
Ben
  1. Wary of use case that making a primaryTypes and mixin immutable
  2. F3 model, everything is effectively a mixin
  3. Introducing concept of primaryType has significant implications
  4. Could be constructive to put together use cases in functional terms
    • Use cases should avoid having implied implementation
Stefano
  1. Other proposal is to start with more strict default primaryType
Frank
  1. Need to ensure the ability to port F3 content models to F4
Andrew
  1. What would the implications be if a primaryType could be user-configurable?
Mike
  1. It would need significant experimentation
Stefano
  1. Noted wiki use case: https://wiki.duraspace.org/pages/viewpage.action?pageId=34666309
Mike
  1. Adding another mixin does not prevent users from creating more properties
  2. We could immediately create a more restrictive cnd, changing default mixin
Frank
  1. We do not want to make it difficult for new users to add content
Ben
  1. Concern about impacts, for example, on WebDAV or sequencers
Frank
  1. F4 currently creates nested folders for performance
    • Is there a risk if we change the default nodeType?

Test proposals

  • Change CND to be more restrictive
  • Sync/async validation of objects
    • Concern of the fact that invalid objects will already be ingested
  • F4 proprietary content modeling rules (independent of CND)
  • Change default primaryType from nt:folder
    • fedora:resource, leave it to the repo manager
  • Allow user to provide their own primaryType

Actions

 

Sample CND file:

fedora-node-types.cnd

Some commonly used mixins (like dc:describable) can be added to this file. 

  • No labels

4 Comments

  1. Stefano Cossu

    See use case page: Use Case: content modeling & validation through CND

  2. Stefano Cossu

    Added sample CND file. It validates but it makes the current Fedora version unable to add nodes until codebase is changed (fedora:resource is now an abstract primary type)

    1. Andrew Woods

      Thanks for the CND, Stefano Cossu.
      What would you expect the default node-type to be when calling: 

      curl -X POST "http://localhost:8080/rest/some/path/to/a/new/resource"

      And does this CND assume the ability to specify the "primaryType" in the above request?

      1. Stefano Cossu

        I mis-interpreted your question earlier. 

        Letting the user choose the primary type in the request would be the best option. 

        As for the default node type, I would personally opt for Fedora:bareObject. At best, this could be changed either by configuration, or having one default type with a more neutral name such as "fedora:defaultType" that can be redefined in the CND by the repo manager. 

        In order to prevent hack-like manipulations (such as some user creating a nt:unstructured node even if the repo manager didn't design a permissive type or mixin) we might want to constrain the choice among fedora:resource sub-types. 

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.