faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
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. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
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 ]
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
