mamund
commented
8 years ago my first question -- what ALPS document metadata do we want to maintain that SHOULD NOT be kept in the ALPS document itself? i suspect it has to do w/ metadata that applies ONLY to the registry's document management and build process.
i think i see that in your lists above, but want to make sure of that.
let's first split out these two types of data --
- meta data that should be shared about the ALPS document and
- meta data that is only needed for the registry in order to do it's job of internal doc mgmt.
make sense?
(from @fosrias email of Nov-21)
Currently the ALPS spec does not include any metadata about the profile itself other than the version of the ALPS spec. Depending on various options discussed below, having a master profile record that is accessible for searching and managing profiles, authentication, drafts, published versions, etc., could be useful and would provide or use some or all of this information.
Ideally the amount of this information would be minimized in a master record and as much of it stored in the profile itself. This then begs the question about what is the minimal amount of information that makes sense to have in the profile and what information would make sense to have in a master record.
Absent the simplest of static UUID based file folder systems to locate profile files that anyone can generate and overwrite, I think a master/ownership record is going to be necessary to maintain UUID mapping to profiles practically. I suspect we want to have one. The question is whether it is just used internally as a local data model or contains information generally accessible as a separate resource related to a profile.
At the very least one would like to use OAuth or some other authentication mechanism for creating and updating profiles vs. anyone with the URI can push a document into the registry and change it. Also, I think master record would be useful in the future to allow the registry to listen to version control callbacks.
Discussed adding to ALPS spec support for (ala Dublin Core): · Author information · Tags · Overall profile description of domain, etc. · Other?
Further, would propose a master record that contained: · Authentication info (preferably just Github Oauth for now) · UUID (draft variants) · Version Control Repository (for discussion and collaboration, albeit this could be handled in the links section of the overall profile likely as a ‘help’ rel). · Other?