Re: [Gzz-commits] manuscripts/storm article_structure.txt

[Benja Fallenstein]

Toni Alatalo wrote:
> another way would be e.g.: 
> 1. intro
> + method: constructive research
> 2. rel work
> 3. design (partly current chapters 3-6, 7)
>    3.1. the data model(?): block storage
>    3.2. the (hyper)media model(?): xanalogical storage
>    3.3. indexing
>    3.4. versioning
>    3.5. networking / publishing: interfacing with p2p
> 4. implementation (partly current chapters 3-7. combined with 5. or 3.?)
> 5. evaluation (partly from current 3-8 and else?)
> 6. discussion / experience and future directions
> 7. conclusions
> 8. acknowledgements
> 9. references
>
> how much work would this change cause and would it be an improvement?
> i do think that we generally need to able to work on structure.

I don't think we have enough to say about implementation to warrant an 
own major section. Therefore, I'd prefer to stick with our current 
structure here...

> i've been taught that in *research* papers, not mere technical ones, a
> research method must be made explicit. in this case it's obviously(?)
> constructive research, right? (there may be different schools to this etc.)
> also research question(s) should be stated clearly, which i think is already
> done (the two issues identified in intro). if you're interested, i can
> provide references. if considered irrelevant, we can skip this now too.

Can you try to fit it into the intro? (Also, do you have references to 
papers actually following this?)

> an important part of constructive research is evaluation, which is often
> separated as an own chapter, after the design and implementation have been
> presented. design and implementation don't have to be separated (as they
> have not been in the current section structure, which is quite ok). in my
> opinion, the areas/parts of Storm could be as subsections of that/those
> sections, with the generalizations of their functions in (sub)section titles
> as well.

I wouldn't know what to say except what we say in our experiences and 
future directions section? Can you give an example of what we could say?

> whether blocks, xu, index, versioning, p2p etc. are their own sections or
> 'hidden' in subsctions and with more general names, is not a big issue i
> think. just thought that it might improve approachability for the readers,
> as they'd be quickly be able to see -- from familiar words/concepts -- what
> the different parts are about.

I think 'xu' is descriptive, as I said in my other mail. 'Block storage' 
may not be a good word, but 'data model' is misleading: the other 
sections describe part of the data model, too. If we find a good generic 
for the first section, that would be good.

-b.