I reviewed the case statements and P2 reports of the current WGs and what I know of the IGs to come up with the following list. I'm sure this is not exhaustive and could be reclassified, but it gives a sense of the range.
- Documents
- Herman and Peter's proposal considers two types: "Discussion Documents" and "Recomendations on Data"
- Might include specifications for APIs and other things
- reference documents or reference models
- data models in UML, image, or other forms
- Use cases of varying degrees of formality
- "policies" i.e. machine actionable rules, perhaps workflows
- recommendations to standards bodies (e.g., ISO)
- reports
- variable registries or directories of standards, policies, vocabs
- vocabularies and ontologies (sre these documents?)
- prototype systems and APIs
- system specifications
- testbeds for "policies"
- code. None of the QWGs have specifically said they will deliver code, but it is implicit in some of the other deliverables.
- general content on the RDA group Web site (see current terms of use, which restrict commercial use. Not sure where this comes from. It may be standard for Trust-IT )
Ancillary outputs--a paper on the process, reports to sponsors, slides, figures, etc.
Larry's assessment of DTR outputs:
I think the DTR outputs could be categorized as:
1. A set of shall we say background documents, including use cases and requirements.
2. A more formal set of documents including a metadata schema and a federation specification. As the group envisions multiple federated Registries these will have to be defined closely, such that others could build to the spec.
3. A functioning prototype built by CNRI -- this is the Sloan-funded activity that was underway when RDA showed up.
I see no problem with RDA holding on to the outputs under #1 indefinitely. These are static documents and over time become of historical interest only.
The outputs categorized as #2 are a bit more of a burden. Should the DTR effort prove to be a success (and if it does not then the problem goes away) these specifications have to be reliably available and probably would be updated or improved over time under a process similar to the one used to create them. If RDA is responsible for them, then RDA must remain in existence. The difference between #1 and #2 is that #1 could go to a library or archive without any loss of functionality, but for #2 to remain vital a process has to remain in place and RDA has to manage that process. This to me is where the rubber meets the road. If RDA is the home for these sorts of specs and recs then it has to have a long-term business model that doesn't depend primarily on national funding bodies. This is more-or-less where IETF lives and I think that it would be useful to get someone deep in the IETF process to discuss these issues with this group. We had such a person at Plenary 1. I think he would be more helpful now.
#3 seems easy to me -- to the extent that specifications and recommendations are adopted and implemented, those actions are the responsibilities of the groups that undertake them. I don't see RDA running Type Registries. The danger, to me, would be getting into the accreditation business, which I would also try to avoid. Other bodies can come together to do that, or even compete to do that, and they should be welcomed as RDA participants.
Raphael's assessment of DFT outputs:
Looking at
you see a test site for the DFT group that might help in
the term collection and definition effort (the decision on
how exactly to proceed is still pending).
Q1: who should "own" and operate such a site - assuming the group goes
down that route?
Possible answer: no need for RDA to take on responsibility here - at least
as long as there is a volunteer effort driving this that people are OK
with.
But RDA could "endorse" such an effort thereby signalling that it
considers
this relevant in the context of RDA's goals.
Q2: who should "own" the content of such a site? Can we impose a statement
like "all content added to this site is made available under <insert
our favorite
license here>"?
Possible answer: as long as this is a volunteer-driven effort the group
should
be free to decide for themselves - maybe according to some guidelines
provided by RDA like "allow for most widespread adoption and reuse"
Foreseeing that at some point the group reaches a rough consensus on
what to propose or recommend it might publish a formal definition of
(part of) the content, i.e., some terms including their definition and
relations,
e.g. like this:
aka as an RDF/OWL file. Obviously this now would be
a concrete output. It would need to be versioned and
maintained in order to be useful.
Q3: Who should "own" this kind of formal output?
Possible answer: RDA
If so: what rights should RDA impose in such a case?
Q4: Who is responsible for managing the process by which
this formal output evolves?
Possible answer: RDA
If so, this possibly implies a long-term commitment.
That's at least how I try to illustrate for myself where I see
the "outputs and IP" group's current discussion heading.
- 3055 reads