Attendees
General
- Indicates who took minutes -
- Call-in: Google-hangout at:
Agenda
- Define issue
- Need for flexible content-modeling
- Need for repository resource validation
- What proposals are on the table?
- Short-term resolution? Long-term resolution?
Minutes
Content Modeling
Stefano
- Use cases
- Assigning content model
- Defining children and properties
- This is provided (to some degree) by cnd
- Use a type to define behavior
- Access policies
- Assigning content model
- Desire to not allow mixins to be removed
- This is offered by primaryTypes
- 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
- Wary of use case that making a primaryTypes and mixin immutable
- F3 model, everything is effectively a mixin
- Introducing concept of primaryType has significant implications
- Could be constructive to put together use cases in functional terms
- Use cases should avoid having implied implementation
Stefano
- Other proposal is to start with more strict default primaryType
Frank
- Need to ensure the ability to port F3 content models to F4
Andrew
- What would the implications be if a primaryType could be user-configurable?
Mike
- It would need significant experimentation
Stefano
- Noted wiki use case: https://wiki.duraspace.org/pages/viewpage.action?pageId=34666309
Mike
- Adding another mixin does not prevent users from creating more properties
- We could immediately create a more restrictive cnd, changing default mixin
Frank
- We do not want to make it difficult for new users to add content
Ben
- Concern about impacts, for example, on WebDAV or sequencers
Frank
- 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
- Stefano Cossu to review/create use cases
- Stefano Cossu to create example CND
- Andrew Woods to explore implementation options to meet use cases
Sample CND file:
Some commonly used mixins (like dc:describable) can be added to this file.
4 Comments
Stefano Cossu
See use case page: Use Case: content modeling & validation through CND
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)
Andrew Woods
Thanks for the CND, Stefano Cossu.
What would you expect the default node-type to be when calling:
And does this CND assume the ability to specify the "primaryType" in the above request?
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.