Rank14

Idea#5

This idea is active.
Functionality / design requirements »

Solution Design

From my perspective the four problems areas that were partly elaborated on the blog and also fed into the discussion topics below are all interrelated. I don't believe you can arrive at independent solutions and expect them to work as a whole (not suggesting that is what you are actually trying to do but has an impact on the discussion). Normally in solution design there needs to be clarification of the "business" requirements, objectives, related activities, end-user requirements etc to clarify the role of the project and the interrelationships between the parts before you can get into the detail, flexibility requirements and technical requirements. I am worried to see an early suggestion of any technology, standard or specification in advance of clarifying the sorts of requirements that should drive the design and then the development. Perhaps that is just my solution architecture bent, but I often see problems arise when the technology drives the agenda instead of serving the agenda.

The clarification of the end-user requirements and project scope and responsibilities, etc will tell you a lot about scale, community of practice engagement, "plugins" to the NLR, augmentation practices of target communities (and therefore crosswalking/harmonization requirements) etc.

You are all smart people, there is no doubt about that or the kinds of issues raised here would not have been raised already, so I am sure that you will be thinking a lot about the issues I've mentioned. It would certainly help if we had some further insight because it will help us to provide more focused information into your activities.

Comment

Submitted by allynr 3 years ago

Vote Activity

  1. Agreed
    3 years ago

Comments (2)

  1. Moderator

    Thanks. We're trying to iterate back and forth between requirements and what's technically possible today. If we have to build a lot of functionality we not sure it will be feasible to get something out the door quickly, which we want to do.

    So we're taking a look at various solutions that others have developed, from LODE, Jess & co, DiscoverEd (Creative Commons), xtf and others. Then we're mapping the gaps in function against our desired functionality to see who does what well. Ideally we'll build some functional tests and sandbox a few of these solutions to see how they do in real life.

    But requirements drive everything and we plan to publish our requirements as we go. Another agency is currently standing up a website where we can put all this information. More as we get it.

    3 years ago
  2. allynr Idea Submitter

    Hi Steve

    I completely understand the approach. One has to use existing standards/protocols/technology etc because the alternative is a very long process that takes years to produce anything useful. No problems there. My main concern is in relation to the approach to the solution and requirements. At the same time, doing the requirements iteratively seems the only plausible option for the NLR.

    From what I can tell there are going to be some issues concerned with how you reach out to satisfy the needs of the different communities. I don't think this is an easy problem and I also think it is much more complex if the registry is supposed to be *logically* the same for the disparate groups. This is a bit hard to explain, but whether this is done as a single, centralized service, or with satellite services or just separate interfaces, it is going to be necessary to segment your user communities in sensible ways to satisfy them. Astronomers and not going to want to use the same terms or consider information with the same taxonomies as primary school students; nor university students in one discipline as practitioners in another, etc etc.

    The picture that emerges is more like the subject gateways that were used in the 90's in different countries. That type of differentiation, irrespective of how it is implemented, is going to be useful in providing a solution - or so I would argue, anyway.

    If that strikes a chord, then several implications flow from it: (a)metadata and taxonomies will be different, (b) existing knowledge and the reasons to engage with the NLR will be different, (c) interface presentation in terms of language, symbols, jargon etc and usability for the different groups will have different dimensions.

    The problem with trying to handle the metadata and somewhat limitless cross walking is that its just too hard. It is better to restrict the problem set to the different communities and find a way to segment this more easily that trying to force the system to be too smart in the background. When thinking about some of the issues of metadata across communities in DITA it seemed clear that if you tried to keep everything in one place (in that case, inside the content) that would quickly end up with more metadata than actual content and increasing loss of meaning and function as a result (like too many keywords - everything gets returned all the time, if you exaggerate the effect).

    The real point of this is that if you think about community based segmentation then it has an implication not only metadata but on standards and protocols that are used in those communities and also on the approach to cross walking, harmonization etc.

    I guess it was these sorts of things that were really driving my thinking on the solution first then iterative requirements because they have a major impact on how progress quickly while still meeting user needs.

    3 years ago