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

[Ian Graham <ian.graham@utoronto.ca>]

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
>>
>>