[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-edu-devel
Subject: Re: Re: The next file format
From: Andreas Xavier <andxav () zoho ! com>
Date: 2014-08-26 19:51:44
Message-ID: 14813dfc108.f36be73e46437.7508737106547419084 () zoho ! com
[Download RAW message or body]
---- On Tue, 26 Aug 2014 02:42:21 -0700 Inge Wallin wrote ----
> On Tuesday, August 26, 2014 00:46:04 Bruno Coudoin wrote:
> > Le 24/08/2014 14:56, Inge Wallin a écrit :
> > > On Wednesday, August 20, 2014 11:23:02 Bruno Coudoin wrote:
>
> > > Yes, confidence level is not the ideal term but so far we haven't
> > > found anything better. What it is is the level of confidence that the
> > > student has for a particular word. This tries to capture how strongly
> > > the word is put into the memory of the student, or loosely put how
> > > long it can be expected to be before they forget it. If you are not
> > > familiar with the term 'spaced repetition training', I urge you to
> > > look it up on Wikipedia, they have an excellent article about it.
> > >
> > > This used to be known as 'grade' in Parley but we are providing a tool
> > > for learning and training, not for testing so grade is not applicable.
> > > Besides, grades also have a negative connotation in that you are a bad
> > > person if you have a bad grade. Since any low confidence level is a
> > > necessary step to the higher confidence levels we wanted to get rid of
> > > the grade connotations and that was the best we could come up with. I
> > > guess 'mark' is vaguely similar to grade in this case.
> >
> > This is clear now and it is what I understood. Then I don't think it is
> > appropriate to put this data in the container for several reasons:
> > - may be on a read only storage
> > - may be hard to centralize the student data to let a teacher review it
> > - an update of the file would overwrite the student data.
>
> These are very good points. Originally we didn't think about centrally stored data \
> files or files that need to be updated, nor about files on read-only media.
> But after this round of gathering requirements we do. So our new file format will \
> support separation of student training data (statistics and confidence levels) and \
> the original word and multimedia data. This should satisfy your requirements that \
> you list above.
> It will also support keeping them together inside the same file, like you would use \
> on a personal computer when you create your own word lists. This is a common but \
> much simpler usecase.
> > > Would you be interested in sharing the container format with us if we
> > > can agree on how we store the internal data?
> >
> > Sure, we have to continue the discussion and hopefully find the path
> > that will satisfy all the needs.
>
> I think we have most requirements now. I will write a first overview suggestion and \
> put on the wiki. Since most people seem to be preferring JSON over XML I will \
> propose that.
I would like to add my voice to Todd and make a case for YAML.
YAML is more human-readable than JSON. To a non-programmer balancing braces {} is as \
non-obvious as balancing tags.
From reading the Dataset_handling page it looks like gcompris plans on passing the \
payload opaquely to the applications as JSON. YAML supports embedding JSON.
The only caveat is availability of a library. I have looked through the CMake files \
of yaml-cpp and they have options covering a range of compilers (gcc,Clang andMSVC) \
and platforms (unix, win32, and iphone). The only required package is Boost, which \
is already required in some KDE packages. I think yaml-cpp is probably acceptable to \
KDE but I don't know where or who to check with.
> Regarding the ease of use of qrc files, I am fairly certain that we will be able to \
> do a more or less in-place replacement API using the library that Andreas Xavier is \
> working on.
I have checked into qrc files. I think we will be able to provide a url for them \
using the same mechanism that we are using for media files. There are 2 drawbacks: \
1. The library will not be able to verify the availability of the internal qrc \
resources because they are compiled into the application. 2. All applications that \
do not have the internal qrc compiled into them will receive a broken url, decreasing \
the usefulness of that resource to applications other than the specific one that \
saved the file. I think including qrc files in the specification is possible. We \
should encourage applications to save the data in the zip file or using the external \
qrc format if that will be available to all of the applications using the new library \
data format.
Cheers Andreas.
>
> -Inge
>
>
> > Bruno.
> _______________________________________________
> kde-edu mailing list
> kde-edu@mail.kde.org
> https://mail.kde.org/mailman/listinfo/kde-edu
>
>
_______________________________________________
kde-edu mailing list
kde-edu@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-edu
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic