[Date Prev] [Date Next] [Thread Prev] [Thread Next] Indexes: Main | Date | Thread | Author

Re: [ba-ohs-talk] backlink database data

> Here is my roadmap for further developing this feature:
> 1. People on ba-ohs-talk build useful front-ends to this data.  In the
> process of doing this, people make useful suggestions as to what other
> metadata need be stored in the file. 
> 2. Replace the text file with a real backlink database.  Hopefully, this
> backlink database can be used by other projects as well, including a2h
> (my Augment-to-(X)(HT)ML translator) and the Hyperscope.
> 3. Eventually bind the backlink database to a peer-to-peer infrastructure,
> so that multiple databases can be installed all over the Net, with all of
> them sharing data.
> -Eugene    (01)

When thinking about how to include/declude/categorize/process 
all these incoming information items, please recall that a big reason 
i need to do this is so i can identify some specific community 
information that i wish to contribute to in collaboration with others. 
The contribution could be a new topic, an interpretation of an existing 
topic, or a topic definition. This information is accessible in some 
structure that relates connections between items and allows 
the information to interact with me by informing me of activity 
concerning the specific community information to which i contribute. 
The model for maintenance of this information is a trusted agent 
who can always remove the redundancies and make the correct 
connections to original and evolved information, plus somone or 
group to monitor the agent.     (02)

> I would recommend against any programmatic changes in people's emails.
> There are legal issues to begin with. Some people have legal disclaimers
> in their signatures that are required of them in their jobs, etc.
> Murray    (03)

Which means that the community decides what to exclude from the 
message as it evolves to a finer and finer definition. for example, 
this series of messages about the .sig (mostly unrelated to the title) 
might evolve into a series of rules that disallow deletion of the sig in 
original input, but removes it (but not backlinks history is original input) 
as the rule is refined by several cycles of work and the rule finally 
appears in some guidelines for processing mail list inputs into the DKR.     (04)

So, if someone would take the responsibility for making sure that 
redundant backlinks are clipped and it gets the plinks right before 
it goes into a working info structure, then that's what is needed.      (05)

Thank You and Best Regards, 
http://www.hypermultimedia.com/DKR/model2.htm    (06)