On 27 May 2011 19:58, chung <chvng at mail.ntua.gr> wrote:

> On Fri, 2011-05-27 at 21:56 +0530, surajit ray wrote:
>
> > Is it possible to design an incremental RDF framework for such data ?
>
> I think not. RDF offers freedom... Let me give an example from the real
> life. Imagine of a natural language in which rules are so strict that
> there is only one way to form sentences and more you are not allowed to
> make interludes; your speech should be structured in a style consisting
> of Introduction, Main Body and Conclusion (read: having Header and
> Body). Imagine, in addition,  that you were supposed to talk only about
> one subject (read: only about datasets). No comments, no remarks (read:
> no DC properties) THERE WOULD BE NO LITERATURE!!! But... a robot would
> be more likely to understand you quite fast. So, RDF is more like
> literature... It offers you great syntactical freedom but it comes at a
> price. If you apply syntactical restrictions to RDF, then we're talking
> not only about a different representation but also about a different
> framework.
>
> > The main ingredients would be a starting "header" RDF block containing
> > feature declarations and metadata.
> > Followed by 1 incremental RDF "data block" at a time. Which would
> > essentially mean 1 row of the dataset at a time.
>



> > An optional end block could also be included to specify the stream end.
> >
>
>
> That's out of the logic of RDF (unfortunately). And it looks more like
> ARFF to me.
>
>
Googling for RDF and streaming reveals several efforts in this direction.

http://www.google.bg/search?hl=en&q=streaming+linked+data

http://www.google.bg/search?hl=en&q=RDF+streaming

http://events.linkeddata.org/ldow2010/papers/ldow2010_paper11.pdf


>
> > The "data blocks" could be very minimalist with just the uri
> > indentifier and the relevant data.
> >
>
> They are already like that (more or less)
>
> > Its simply a matter of a special protocol  (within the RDF domain)
> > designed for the purpose of such large datasets.
> >
> > RDF although large in their overall representation of objects provides
> > a lot of comprehension capabilities vs ARFF.
>
>
> true
>
> >  Also theres the simple
> > matter of having a single extra  comma in your data crashing the whole
> > algorithm ( in ARFF) ! Natively RDF is more in tune to "comprehend"
> > data rather than represent data in an efficient form.
>
>
> Also true!
>
> >  Also have to
> > keep in mind that occasionally the need arises for a human to
> > comprehend such data (in the native machine form) and in such cases
> > RDF is quite unsuitable.
> >
>
> Have you used tabulator on firefox? It's quite nice. Additionally, the
> scope of RDF is not to be human-readable. That's why we have HTML.
>
>
 N3 serialization is quite readable .


Good to have this discussion here!

Regards,
Nina


> > Another possibility could be to "compress" RDF using annotations. Of
> > course that would mean designing and standardizing the annotations for
> > all players who want to interact using the compressed form.
> >
>
> Just a note: The RDF document with which the experiments were carried
> out are quite optimized. Also RDF/XML in another study was shown to
> outperform TURTLE and other equivalent representations.
>
> Best Regards,
> Pantelis
>
> > Just my two cents ....
> >
> > Regds
> > Surajit
> >
> > On 27 May 2011 21:20, chung <chvng at mail.ntua.gr> wrote:
> > > Hi All,
> > >    Some criticism on RDF from the experience we've gained in OpenTox :
> > > http://is.gd/qLJG3h . The article is not complete yet and will be
> > > enriched with more facts and diagrams. We also started an interesting
> > > discussion with Martin here : http://is.gd/cUKaCE which we can
> continue
> > > on the mailing list.
> > >
> > > Best regards,
> > > Pantelis
> > >
> > >
> > > _______________________________________________
> > > Development mailing list
> > > Development at opentox.org
> > > http://www.opentox.org/mailman/listinfo/development
> > >
> >
> >
> >
>
>
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>