Re: [xml-dev] XML-DEV list - prior art

[sterling <sstouden@thelinks.com>]

I find the value in academic papers to be in bringing 
current one's knowledge about the current state of the
art.  Start with a few of the lastest papers and dig 
through the reference supported rules, assumptions, 
and prior findings to discover the gambit of facts 
and data known and concepts still in flux on the topic. 

It also helps to identify the people in the field.

Except for the few active in the field at the time 
of the publication, new information is really useful 
only after it has simmered for a while in the light 
of its ability to sustain itself as justified to be
a truth of its own findings. 

Peer review is a political process as much as it is a 
technical review depending fairly much on the source 
and the publication. 

I am not talking about peer review, I am talking a 
referencing the source of the technical aspects of 
one's own works so others can identify the source 
of the technology and trace the history of the 
technology used back to the original creator if 
cause exist for that effort.

I do not find peer review necessary or desirable
in referencing technologies of others used in 
one's own work.  The proposal does not suggest 
passing judgement on the current work. It simply 
suggests documenting the technologies the current
work used that were developed by others and 
laying first publication claim to the novel 
parts of the current work.

On Sat, 30 Sep 2006, Ian Graham wrote:

> This is a fine idea, but I don't see how it could work.
> 
> The 'value' of a scientific (or any academic) paper is in the paper's 
> new ideas -- and tin he references / footnotes giving it context.
> 
> Peer review determines if a paper is 'good enough' to have potential 
> value, or not.
> 
> Insufficient references (or badly formed ideas) means you don't make it 
> past the gate.
> 
> The whole culture of academic writing is built around this model and 
> this notion of value.
> 
> But the value for code is entirely different - value is functionality, 
> cost, time to market, etc ...
> 
> So unless you change the measure of value, this idea won't fly.
> 
> My 2 cents, anyway.
> 
> Ian
> 
> sterling wrote:
> > I want to make clear that I am not arguing with you, 
> > but I do think the following might provide some food 
> > for thought?
> >
> > I think you might find that "concepts and techniques
> > used" follow a hierarchy of papers or prior works, 
> > such that the few most recent papers on a given 
> > "implimentation of a prior art" would be all that 
> > is needed to provide the references to footnote 
> > the prior art used in the various lines of code.  
> >
> > What would be interesting is to pick a product 
> > or even a portion of a product and to do the 
> > prior art research on that product to find good 
> > references to the prior art that was used to 
> > produce the current code and to develop a 
> > system to footnote the embedded prior art used 
> > in the code to the references. 
> >
> > I think after the first few big projects are 
> > footnoted to locally appended references, that 
> > the appended reference length will become very 
> > manageable. 
> >
> > Lets develop a senario! 
> > Our developer has 200 prior arts appearing in
> > his 6000 lines of code that need to be footnoted
> > and indexed to a reference, and those footnotes
> > would, of course, appear through out the 6000 
> > lines of code maybe something like the following:
> >
> >     breakdown of prior arts   unique prior art
> >     used in the 6000 lines    occurences of
> >      of code                  in need of a 
> >      n times.                 appended ref
> >          
> >  A.  19 appear only once           19
> >  b. 120 appear twice               60
> >  c.  21 appear in triplicate        7
> >  d.  40 appear 4x                  10
> >
> >    Max appended references needed =     96
> >   ( for current paper to Footnote to)
> >
> >
> > This means the number of references needed 
> > to footnote and index 200 prior arts used 
> > in the body of the 6000 lines of code would 
> > not be greater than 96, but it does not mean 
> > that 96 separate appended references would 
> > be needed to footnote the 6000 lines of code.
> >
> > Unique              only 9 REFERENCES NEEDED 
> > references          to FN all prior art
> > needed             A, B, C, D, E, F, G, H, I
> >  19(1)=19          -, 3, 1, 6, 2, 1, 1, 1, 5
> > 120(2)=60         40, 1, 2, 2, 2, -, -, 3, 1
> >  21(3)= 7          0, 2, 1, 1, -, -, 3, -, -
> >  40(4)= 4          1, -, 2, -, -, -, 1, -, -
> >                       
> > After the developer looks at his references 
> > he or she might discover that references 
> > already cite many of his prior art occurences, 
> > so in the above senario only 9 references might 
> > actually be needed to footnote all of the prior
> > art used in the 6000 line program. 
> >
> > The unique number of different prior arts used
> > in a project many not be that great, since many 
> > of the arts used, whether novel to the current 
> > project or adopted from the prior art will be 
> > used over and over and over.  
> >
> > sterling
> >
> > On Fri, 29 Sep 2006, Michael Kay wrote:
> >
> >   
> >>> In short every software project would carry a cumulative 
> >>> history of known prior art.  
> >>>       
> >> I'm wondering what such a list would look like for Saxon. If anyone had time
> >> to produce it, I'm sure it would be bigger than the code itself.
> >>
> >> Michael Kay
> >> http://www.saxonica.com/
> >>
> >>
> >> _______________________________________________________________________
> >>
> >> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> >> to support XML implementation and development. To minimize
> >> spam in the archives, you must subscribe before posting.
> >>
> >> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> >> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> >> subscribe: xml-dev-subscribe@lists.xml.org
> >> List archive: http://lists.xml.org/archives/xml-dev/
> >> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> >>
> >>     
>