faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: why not html?
by Richard Dale on Tuesday 15/May/2007, @08:52
|
OK, I see - obviously RDF is a well known file format and using it for something like a vocabulary is what it is intended to be used for.
Saving stuff like that on a local hard disc seems a bit limiting, as the data much more useful if combined with other people's scores on the web. Then you can ask questions about what foreign language features are hardest to learn by a particular group of native speakers.
If you want to save the user data on the web, I think it would make sense to use something RDF based like rss or atom rather than a document format like ODF. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: why not html?
by Aaron Seigo on Tuesday 15/May/2007, @16:48
|
the most interesting aspect to this plan is to use a common file format for storing data that all applications can use. odf seems to be a set of formats that are well described via an openly crafted specification and which can handle the needs of all these apps.
encapsulating data unnecessarily in file formats specific to a handful of use cases means that we can't easily move data around between applications and instead have to have filters and other conversion mechanisms.
taking your suggestion for RDF (or a derivative), we'd lose this data portability. and for what benefit? perhaps one might wish to export to RDF, and if there is one odt->rdf or ods->rdf filter written then all apps can use it, not just the one app that is specially coded to save its data in RDF. replace 'RDF' with any other file format and think of all the apps that save data.
what will people use this for? honestly, i don't think we can fortell every possible use. that's one of the neat things about technology: once created, others can and usually do find interesting and creative uses for it. but this is only possible if the technology is an enabler rather than a straight-jacket.
i think it is time we moved beyond the data balkanization that happens due to the rather unnecessary proliferation of file formats.
the other aspect of this is that it makes data storage a simpler problem for people writing applications. instead of creating a file format, which is usually just a means to an end rather than a key function of the application, or coding up support for an existing file format, having a common library will make it easy to deal with saving and loading data programmatically. by sharing that library amongst apps, when it comes to data storage it will make it easier for developer of application 'a' to work on application 'b' since the code for saving and loading files will be minimal and near identical in both apps. instead of having to worry both about the internal data structures that are being saved out and the format to which it is being saved, one need only care about the former.
having looked at and worked on a number of kde applications that deal with files and have their own home brew document classes, i am pretty happy about that possibility.
|
[
Reply To This | View ]
|
Re: why not html?
by Richard Dale on Wednesday 16/May/2007, @05:50
|
"taking your suggestion for RDF (or a derivative), we'd lose this data portability. and for what benefit?"
No, quite the opposite. RDF allows you to combine semantic data (such as test scores from using edu apps), with other semantic data that can be found on the web. This would allow you to combine the kde edu app test scores with other data, such as school sports results perhaps, as long as both were RDF and used common vocabularies such as Dublin Core and FOAF.
I agree it isn't always obvious when data should be held as an ODF document and when it is better stored in, say in an RDF format. And you might describe ODF docs with RDF meta-data to combine both.
|
[
Reply To This | View ]
|
Re: why not html?
by Aaron Seigo on Wednesday 16/May/2007, @12:36
|
yes, you can associate RDF metadata with a document. on the other hand, i don't see RDF being able to cover all the data needs of applications. in the case of test scores, afaik RDF doensn't give access to "sum this column, divide by the count" like a spreadsheet does.
so given that RDF doesn't cover all the needs of applications, it can never become the "native" file format for many applications. ODF can be. and that means, quite obviously, that ODF grants greater data portability.
as you note, it comes down to both apps using the same formats and vocabularies. well, that's what ODF is: an agreed upon format that has broader reach. you're talking about theoretically having apps store things in RDF, the koffice people are talking about a practical way of having many apps store things in a common (set of) format(s): ODF.
that doesn't mean RDF is bad, it means that ODF is simply a more general purpose solution and therefore a better selection for primary data storage.
nepomuk/strigi bring RDF to the desktop, but i don't think that is an appropriate primary storage system. awesome possibilities for augmenting the primary storage, yes =)
|
[
Reply To This | View ]
|
Re: why not html?
by Cornelius Schumacher on Wednesday 16/May/2007, @16:26
|
I love the idea of having a commonly available library to operate on ODF formats, using them as storage format or interacting with applications using ODF or whatever else. There are countless exciting use case. I would for example like to be able to edit a template document for something like an invoice in KWord/OpenOfficeWriter/... and then fill in the actual data from a specialized application knowing about the business logic behind the specific invoice (maybe a combination of say KMyMoney, KAddressBook and Kraft).
On the other hand I can only support Richard's suggestion to use RDF. This goes beyond the notion of a file format for storage of data. It includes relating data, interacting with web resources, sharing of information and much more of the things user want to do in the Web 2.0 times. We shouldn't miss out on this opportunity just because we usually think in the traditional lines of storage file formats.
|
[
Reply To This | View ]
|
|
Re: why not html?
by Thomas Zander on Wednesday 16/May/2007, @00:57
|
I agree with you that using an existing fileformat is good; the choice you state is RDF. I don't have a lot of experience with it.
I guess what I am saying is that we should aim for integration of one fileformat in as many different applications and usages as possible for a couple of reasons. FIrst is obviously code reuse, which Aaron touched on and what makes it easier for the programmers. The developer might like to load the file in a spreadsheet for debugging purposes.
A bigger reason is that when ODF becomes omnipresent the tools for handling and debugging them get more focus and developers and users alike will see these documents as more than simple blobs of incomprehensible data.
I guess its similar to the concept of 'everything is a file' under unix. Using one interface to as many different things as possible might not give you the best solution for each individual case, but on the whole the network of possibilities increases magnitudes.
So, while you may be right that RDF is better (I honestly don't know) for this individual use case, it does not invalidate the idea of a separate library for all apps to use and grow upon. The example elsewhere in this thread that an OCR scanning app saves its text as well as its pixmap data into an ODF container seems like a really good idea to me.
And if we start to have a lot of ODF support all through the industry, then kvoctrain will benefit more from ODF in the long run than from using RDF which will ultimately be less well supported.
|
[
Reply To This | View ]
|
Re: why not html?
by Bruce on Saturday 15/Sep/2007, @08:20
|
Just for the record, ODF 1.2 will allow you to use RDF within ODF; layering addtional semantics on top of existing document content. So no need to choose between them; they can be quite complementary.
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
