|
|
 |
|
 |
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 & 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?
- Organisational affiliation.
- State or country from where this Service Genre is being submitted.
- A document stating your intention (seeking advice or submitting proposal).
- Project or proposal commencement date.
- Details of approving body or grant that has been released towards the successful completion of the project.
- Stages that have been completed or yet to complete.
- Details of the purpose of the project/proposal that has relevance to ICT and education and the domain in which it is applicable.
- 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.
- 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
|
|
|
|
|
Service Expression -
A core e-Framework term referring to a specific set of functionality and behaviours described in terms on interfaces, messages, standards and technologies; a specialisation of a single service genre by specification of exact interfaces and standards used.
For more information, see the Service Expressions page.
|
|