The following section should answer your most Frequently Asked Questions about accessing e-Framework documents.If your questions are not answered, please contact editor@e-framework.org directly.

1. General information
2. Participation
3. About the website
4. How to submit content to the e-Framework
5. What happens after submissions are received
6. Policies
7. Core Service Components: SUMs, Service Genres and Service Expressions
8. Contact details

Q. 1.1 What is the primary goal of the e-Framework?

The primary goal of the e-Framework is to facilitate technical interoperability within and across higher education and research through improved strategic planning and implementation processes. Your participation in this endeavor is strongly encouraged; only with the input of a wide range of participants can the breadth of interoperability issues be addressed.

Q. 1.2 What is interoperability?

In the context of the e-Framework interoperability is a term used to indicate that technical components can work together within an IT application or system. More broadly, it simply describes the ability of IT systems to perform tasks required by other IT systems through the exchange of data and information between systems.

Q. 1.3 Will the e-Framework provide information on best practices, standards used by other projects, and updates on such standards?

The aim is to do this. However, it is not yet clear until sufficient shared practice has occurred. It is hoped that best practice will emerge from the SUMs that are contributed and /or generated.

Q. 1.4 Doesn't the classification of services into non-overlapping categories, or genres, stifle innovation?

To the contrary. In the service oriented approach underlying services are documented utilising open standards and utilising open standards enables innovation.

Q. 1.5 How can the e-Framework scale?

Although content is contributed by Partner organisations, it can be contributed by others as well. Scalability depends on how many interested stakeholders contribute information and how many make use of the information and then contribute their findings back to the Website.

Q. 1.6 Can the e-Framework's direction be influenced?

The various committees within the e-Framework initiative rely upon the experiences and expertise of many people. Trends and emerging consensus in the wider community are considered very important by the Partners. If you wish to influence direction or make a suggestion then please join the Community Wiki and/or email the Editor.

Q. 2.1 Who can participate?

Anyone with an interest in the e-Framework can. You can do this through joining in the public discussion on the e-Framework Forum or you can suggest or submit an addition to the e-Framework’s knowledge base.

Q. 2.2 What are the benefits of sharing documented processes and services with others?

Your input will contribute to the ongoing development of the e-Framework initiative. Shared access to the growing knowledge-base of service components (Service Genres, Service Expressions, CORE SUMs and Service Usage Models) and the possibility of collaborating with others can shorten the development time for the particular services your organization needs.
Through sharing documentation "reinvention of the wheel" can be avoided while also providing new opportunities for cost effectivness, interoperability and flexibility of the deployed systems throughout your organization.

Q. 2.3 Who can submit a Service component?

Anyone can submit a proposal!

A proposal for a Service Genre might emerge from a technical project that is either completed successfully or a project going through various stages in development process. There are many people with different skills connected to a project such as vendors, developers, technical people, IT Managers, project leaders from organisations, institutions, hardware and software specialist and the like.

Please be aware that your submission is done in the interest of others involved in the project. Acknowledgement of contributors needs to be supplied where appropriate.

Q. 2.4 Why should I submit information to the e-Framework when I can benefit in exposing it to Google search under an open source project?

You should put it into both! The e-Framework is the only initiative of its kind which has been created by the Higher Education sector for the Higher Education sector. Furthermore, there is a level of quality assurance which the e-Framework provides that Google doesn't.

Q. 2.5 Why should I divulge anything about my project/info/code to the e-Framework?

Including your project in the e-Framework does not mean that you cannot still sell your source code to a third party (although your funding body may have something to say). The drivers behind the e-Framework are commitments to open standards and to open source where appropriate.

Q. 2.6 The type of information I am looking for is really technical and this website does not yet provide sufficient detail. Where can I find further technical information?

You'll find that the e-Framework links to a number of known implementations of the standards and services that are documented. The e-Framework aims to promote interoperability and re-use of service components and is not intended to serve as a "one-stop shop" for all technical information related to service oriented approaches.

Q. 2.7 I prefer to talk to technical people. Can you give me a list of contacts and the type of projects that they have worked on? I may benefit from talking to them directly.

The submitters and their institutions can be found within the individual documented components.

Q. 3.1 What is the purpose of the website?

The website is intended to serve two main purposes.

Principally, it is to develop a broad picture of the benefits in adopting of a “service oriented approach” to the development of ICT infrastructure in Higher Education. Secondly, it provides a collaborative platform for the development of documentation of technical service components or interfaces that are part of this service oriented approach.

Q. 3.2 How will the published components such as Service Genres be used?

Service Genre information will be gathered from a variety of projects and shared with the community. After undergoing a review and modification process, the information will be published and maintained on the e-Framework website.

By analyzing the accumulated knowledge base, the e-Framework partners will identify commonalities and patterns from the examples that will:

• Provide guidance to other interested parties
• Inform standards development
• Provide benchmarks for best practices

Q. 3.3 Who is the website for?

The website is being developed by the Partners primarily for those stakeholders actively engaged in developing ICT infrastructure within Higher Education.

Q. 3.4 Is this website for technical people or is it for non technical people?

Technical people should be able to understand the entire site. Non-technical people should be able to work with the descriptions of the Service Genres, and SUMs. Non-technical people are advised to stay out of the detail particularly when it comes to Service Expressions.

Q. 3.5 Is the e-Framework website aiming to document all relevant information about different projects from Partner countries?

No. The site is intended to showcase the use of services within projects, and act as a guide for future work by reducing the number of times the wheel is re-invented.

Q. 4.1 What types of documents can be submitted?

The e-Framework is currently collating documentation on Service Genres, Service Expressions, Service Usage Models; CORE SUMs will be solicited in the future.

Q. 4.2 How do I submit a proposal?

Ensure that you have read the necessary policy and procedures related to the submission. If you have any questions, please contact our e-Framework editor.

Needs Revision

Q. 4.3 What documents do I need?

Refer to the submission procedures section.

Q. 4.4 What information will I be asked for?

1. Organisational affiliation.
2. State or country from where this Service Genre is being submitted.
3. A document stating your intention (seeking advice or submitting proposal).
4. Project or proposal commencement date.
5. Details of approving body or grant that has been released towards the successful completion of the project.
6. Stages that have been completed or yet to complete.
7. Details of the purpose of the project/proposal that has relevance to ICT and education and the domain in which it is applicable.
8. Details of partners and all members involved in the project, information about which aspect of the project belongs to individual members. Please read our Creative Common licence under which we would like to protect your intellectual property rights.
9. Please be aware we would also like you to agree /sign our privacy policy in order to enable us to provide your service genre information to interested developers as a process of guidance or advice.

Q. 4.5 Can the e-Framework assist me in documenting my project by using the templates?

The e-Framework Editor can provide you with guidance if required.

Q. 4.6 When preparing a submission to the e-Framework, what sort of information should I provide? Should I include information about the process or the code itself, or should it be generic?

Primarily, your document needs to detail “what the service does”, “what its interface is” and “how someone uses the service”. It is not necessary to include actual code but pointing to code libraries and programs is OK. If you need to represent the business process requirements either pictorially or narratively that is also OK.

Q. 4.7 I still don't understand the technical differences between genres, expressions, and SUMs. How can I document my project correctly?

Most projects tend to produce SUMs.

First identify what problem the project solved. If more than one service was used to solve the problem, then the project most likely developed a SUM. However, if only one service was used, then the project probably describes a new service expression.

If someone could use the new service to solve a different problem (for example, the syndication expression "RSS" can be used to syndicate almost any type of content), then it could be a service genre.

If the project addresses something completely new, it might be a new genre, or possibly an existing genre that exists in a domain in a different community or space.

In any event, the e-Framework Editor can provide assistance with the submission process and ensure that projects are showcased appropriately.

Q. 5.1 What happens after I submit the completed template and other information?

Once you have submitted your information, the website system will generate an automated acknowledgement. The e-Framework Editor will ensure that all relevant documents and required information have been received. Should there be any clarification to be sought from you at this stage, this may add some extra time or delay in our response time.

The Editor will then forward your documentation to the e-Framework Integrity Group (eFIG) for further review and approval. This may take anywhere between 2-4 weeks depending on the volume of submissions received and as well as based on members ability to convene and provide a consensus. Intermediate communication may arise should the eFIG require any specific information about the Service Genre submitted.

You may be advised that the information provided requires modification, or that it duplicates existing information in the e-Framework registry. Once your submission is approved, the e-Framework Editor will send an acknowledgement to you. Where necessary, a form may be sent for signatures to protect your privacy and IP. Once the signed form is received, your details will be added to the knowledge base.

Q. 5.2 Can I make a submission that might be related to an existing service component?

Yes, but please identify clearly what is distinct about your submission.

Q. 5.3 Is there a time frame within which I should submit documentation for a service component after it has been proposed?

Not necessarily. But earlier the better as there always other projects / people who may have potentially submitted similar information and we may not be able to accept your information due to keeping duplicates.

Q. 5.4. Can I change the documentation of a service component after I have submitted it?

It is possible but to avoid this situation it is best to review your submission carefully first.

Q. 6.1 Does a Committee decide everything that goes into the website?

Quality Assurance (QA) of content on the website is an ongoing concern and priority for the e-Framework Partners. Much of the QA function rests with the Editorial team but QA of some technical content (Service Genres and Expressions) is also provided by the e-Framework Integrity Group (eFIG). This is needed by tertiary education institutions wanting to build their ICT infrastructures using the information on this Website.

Q. 6.2 Doesn't the e-Framework Integrity Group act as a bottleneck?

It is not the intention that the e-framework Integrity Group (eFIG) will become a bottleneck. However, acceptance by the eFIG of contributed content provides a certain 'confidence' status in terms of its use in the tertiary education sector. This will be based on experience in projects, trials and implementation experience.

Q. 6.3 I have project information which could be useful to the e-Framework community, but it is funded by a government agency external to the e-Framework Partners. What are the IP implications of submitting information for publication on the e-Framework website?

Please check our statements on IP policy. If you need further clarification please send an email with further details required to: editor@e-framework.org.

Q. 7.1 Do I have to assign a name to a service component?

It is essential to provide an appropriate name as this will help identify how it is used in a specific domain and will assist in classification.

Q. 7.2 What are SUMs?

SUMs are Service Usage Models. They describe needs, requirements, workflows, management policies and processes within a domain and the mapping of these to a design of a structured collection of Service Genres and Service Expressions, resources, associated standards, specifications, data formats, protocols, bindings, etc., that can be used to implement software applications within the domain.

Q. 7.3 Which approach is best suited to documenting a service component, bottom-up or top-down?

The aim is to capture both the problem that your service solves, and how it goes about solving that problem.
So, either approach is valid - top-down or bottom-up. If you can document the problem that you worked on and how you solved it using services, then the e-Framework can publish the description on this website. The editors are also available to help you through the submission process and to help with the templates.

Q. 7.4 Can the same Service Genre be found in more than one domain or field of use?

Yes, it is quite probable that a Service Genre will be applicable in more than one domain or field of use.

Q. 7.5 What are Service Expressions?

Service Expressions represent specific cases of the related but abstract and generalized Service Genre. The detailed description of the Service Expression can be used to design an actual implementation of the behaviours associated with the Service Genre. (Ultimately, Service Expressions are 'derivatives' of a Service Genre, but the process by which Service Expressions are created is not always 'derivation' – Service Expressions could be developed before or simultaneously with establishing their related Service Genre.)

Q. 8.1 Who can I contact for further clarification?

You can contact:

e-Framework Editor
e-Framework for Education and Research

Email: editor@e-framework.org

Last updated 30 January 2008