21

お気づきかもしれませんが、コミュニティ Wiki の投稿に編集の概要が表示されるようになりました。

コミュニティ wiki
220 リビジョン、48 ユーザー

また、ページに表示される最終的なコンテンツを「最も所有している」ユーザーを、残りのテキストのパーセンテージとして表示したいと思います。

コミュニティ wiki
220 リビジョン、48 ユーザー
kronoz 87%

はい、上位 (n) 人の「所有者」がいる可能性がありますが、今のところ、上位 1 人が必要です。

このデータ構造があると仮定します。これは、投稿の時点で時系列に並べられたユーザー/テキストのペアのリストです。

ユーザーIDポストテキスト
---------- ---------
12 素早い茶色のキツネが怠け者の犬を飛び越えます。
27 速い茶色のキツネは時々ジャンプします。
30 私はいつも、足の速い茶色のキツネが怠け者の犬を飛び越えているのを見ます。

これらのユーザーのうち、最終的なテキストを最も「所有」しているのは誰ですか?

所有者を決定するための合理的なアルゴリズムを探しています。近似値である可能性があり、完全である必要はありません。パーセンテージ スコアで表すのが理想的です。

編集、削除、および挿入を考慮に入れる必要があることに注意してください。そうすれば、最終結果は合理的で正しいと感じられます。適切なリビジョン履歴 (再タグ付けだけでなく、頻繁な投稿本文の変更) を持つスタックオーバーフロー投稿をテスト コーパスとして使用できます。これは良いもので、14 人の異なる著者による 15 のリビジョンがあります。「所有者」は誰ですか?

https://stackoverflow.com/revisions/327973/list

「ソースを表示」をクリックして、各リビジョンの生のテキストを取得します。

純粋なアルゴリズムによる解決策が、最終的には最長共通部分文字列問題の形式になる可能性があることを警告しておく必要があります。しかし、前述したように、近似値と推定値も、うまく機能する場合は問題ありません。

どの言語での解決策も歓迎しますが、私は次のような解決策を好みます

  1. C# に変換するのはかなり簡単です。
  2. 依存関係がありません。
  3. 効率よりもシンプルさを優先してください。

SO に関する投稿に 25 回以上のリビジョンがあることは非常にまれです。ただし、正確に「感じられる」必要があるため、編集内容を目で見て確認した場合は、最終決定に同意することになります. リビジョン履歴を含むスタック オーバーフローの投稿でアルゴリズムをテストし、最終的な出力に同意するかどうかを確認することをお勧めします。


私は現在、次の概算を展開しています。これは、コミュニティ Wiki の投稿で新しく保存されたすべてのリビジョンの動作を確認できます。

  • 本文が変更されたすべてのリビジョンの行ベースの差分を実行します
  • 各リビジョンの挿入行と削除行を「editcount」として合計します
  • 各ユーザー ID は、貢献した「editcount」の合計を取得します
  • 最初のリビジョンの著者は、一次著者ボーナスとして、初期スコアとして 2x * "editcount" を取得します
  • 最終的な所有権のパーセンテージを決定する: 各ユーザーの編集された行数の合計を、すべてのリビジョンの編集された行の合計数で割った値

(リビジョンが 1 つ、作成者が 1 人のみなど、一般的な単純な条件に対するいくつかのガード句もあります。行ベースの diff により、すべてのリビジョンの再計算がかなり高速になります。たとえば、10 リビジョンの典型的なケースでは、約 50 ミリ秒です。)

これは、私のテストではかなりうまく機能します。数人が編集する 1 ~ 2 行の小さな投稿の場合は少し崩れますが、それは仕方のないことだと思います。ジョエル・ニーリーの答えを、私が行ったものに精神的に最も近いものとして受け入れ、実行可能と思われる他のすべてを支持しました。

4

15 に答える 15

25

アイデアは根本的に欠陥があると思います。

誰かがひどいつづりと不明瞭な例で素晴らしい分析を書き、私がそれを広範囲にコピー編集した場合、私は作品の60%を作成しましたか?明らかにそうではありません。結果は、値の大部分が最初のポスターから得られる派生物です。文字数や単語数に基づいて有用な測定を行うことはできませんが、強力なAIレベルのセマンティック分析が必要です。

それとは別に、記事の「所有権」に基づいてクレジットを求めることは、まったく役に立たず、反ウィキになる可能性があります。たとえば、ウィキペディアでは、記事を所有しているように振る舞う人々が最も有害な影響の1つです。

于 2009-01-08T14:41:22.577 に答える
20

先にツイートを見ました。327973リンクの表示から、すでにシングルステップの差分が設定されているように見えます。これに基づいて、マルチエディット構成に焦点を当てます。

  1. A、元の投稿者が投稿の100%を所有しています。

  2. 2番目の投稿者であるBが、たとえばテキストの90%が変更されないように編集する場合、所有権はA:90%、B:10%になります。

  3. 現在、サードパーティのCがテキストの50%を変更しています。(A:45%、B:5%、C:50%)

    つまり、投稿者がx%を変更し、y =(100-x)%を変更しないように編集すると、その投稿者はテキストのx%を所有し、以前のすべての所有権にy%が掛けられます。

    それを面白くするために、今仮定します...

  4. Aは20%編集します。次に、Aは「新しい」20%を所有し、残りの所有権は80%で乗算され、残り(A:36%、B:4%、C:40%)になります。したがって、「ネット」所有権は(A:56%、B:4%、C:40%)です。

これを標本(327973)に適用し、すべてを最も近いパーセントに丸めます。

バージョン0:元の投稿。

  • ポールオイスター:100%

バージョン1:現在のdiffツールはテキストの純粋な追加を示しているため、これらの文字はすべて2番目のポスターに属します。

  • ポールオイスター:91%
  • ワンバイワン:9%

バージョン2:diffは単語の置換を示します。新しい単語は3番目のポスターに属し、残りのテキストは前のポスターに属します。

  • ポールオイスター:90%
  • ワンバイワン:9%
  • Blogbeard:1%

バージョン3:タグのみの編集。あなたの質問はテキストに関するものだったので、私はタグを無視しています。

  • ポールオイスター:90%
  • ワンバイワン:9%
  • Blogbeard:1%

バージョン4:テキストの追加。

  • ポールオイスター:45%
  • ワンバイワン:4%
  • Blogbeard:1%
  • マークハリソン:50%

それがこの提案の意味を与えるのに十分であることを願っています。いくつかの制限がありますが、概算は許容できるというあなたの声明の下にこれらをスライドさせています。;-)

  1. 変更の影響を以前のすべての所有者にブルートフォースで分散します。Aが投稿し、Bが純粋な追加を行い、CがBが追加したものの半分を編集する場合、この単純なアプローチは、どの以前の所有権が最も変更されたかを解析しようとせずに、投稿全体にCの所有権を適用します。

  2. 追加または変更を考慮しますが、削除者が残りのテキストに0%を追加するため、削除の所有権は付与されません。これはバグまたは機能と見なすことができます。ドア番号2を選びました。

更新:上記の問題#1についてもう少し。編集された投稿の一部の所有権を完全に追跡するには、次の2つのいずれかが必要になると思います(Webページのマージンは正式な証明には十分な大きさではありません;-):

  • テキストの個々の部分の所有権を反映するようにテキストの保存方法を変更し(たとえば、Aは単語1-47を所有し、Bは単語48-59を所有し、Aは単語60-94を所有します...)、「残りの量」を適用します。各部分への私の提案のアプローチ、および部分所有権データの更新。

  • 最初から現在までのすべてのバージョンを検討します(実際には、部分所有権データをその場で再計算します)。

したがって、これは、(精度を犠牲にして)迅速で汚い近似、(スペースを犠牲にして)データベース全体への変更、または全体を調べる必要があるすべての計算の間のトレードオフの良い例です。履歴(時間を犠牲にして)。

于 2009-01-08T13:47:07.040 に答える
5

投稿例の所有権を確認する方法を次に示します (注: テキストにタグを追加するのをまったく忘れたため、この例では単純なタグの変更はカウントされませんが、簡単に追加できます)。

を平手打ち: おい、ユーザー番号の代わりにリビジョン番号を使った。結果は以下に書き直されました:

User 38193 owns 42% (922 / 2171) of the final post
User 2635 owns 28% (625 / 2171) of the final post
User 116 owns 24% (529 / 2171) of the final post
User 745 owns 3% (76 / 2171) of the final post
User 13005 owns 0% (11 / 2171) of the final post
User 18941 owns 0% (5 / 2171) of the final post
User 8562 owns 0% (3 / 2171) of the final post

53 ms

したがって、私のアルゴリズムによると、ユーザー 38193 (@ Paul Oyster ) は投稿の 42% を所有していますが、投稿 2635 (@ Simucal ) は 28%、ユーザー 116 (@ Mark Harrison ) は 24% を所有しており、残りは無視できます。

改訂版から、元の著者である Paul がまだ問題のほとんどを所有しており、Simucal と Mark が適切な nr. に参加していることがわかります。2 および 3。これらはリビジョン番号に対応します。1 (元の投稿)、番号。14、これは Simucal による大規模な編集であり、私のアルゴリズムの欠陥を非常によく示しているように見えます (以下を参照)。5 マークが bash スクリプトを追加した場所。

では、どうやってこの答えにたどり着いたのでしょうか。アルゴリズムには欠陥がありますが、それについては後で説明しますが、その方法は次のとおりです。

基本的に、元の投稿の各バイトには、それを書いたユーザーのユーザー ID が割り当てられます。次に、順不同でコピーを処理できる diff アルゴリズムを使用します。これにより、新しい作成者によってコピーされたバイトのユーザー ID が取得されます。新しい作成者によって追加されたものにはすべて、新しい作成者のユーザー ID が割り当てられます。

たとえば、元の著者が 2 つの文を書いた場合、これらは彼のユーザー ID でタグ付けされます。その後、別の著者がそれを修正し、元の 2 つの文の間に 3 番目の文を追加します。diff アルゴリズムにとって、これは新しい作成者が最初の文をコピーし、新しいデータを追加し、2 番目の文をコピーしたように見えます。したがって、文はその作成者に正しく帰属します。

diff アルゴリズムはバイト単位で機能するため、句読点の欠落や文字の追加などの小さなテキストの変更は所有権にほとんど影響を与えず、ほとんどすべての元のテキストは元の作成者に帰属するはずです。ただし、内部の最適化により、1 バイトだけ追加された場合でも、「追加データ」操作を使用する場合があります。アルゴリズムとその実装は、ファイルの差分を処理し、ファイル バージョン間で可能な限り最小のパッチを生成するために最初に作成されました。

アルゴリズムの欠陥は、ロールバックに起因します。Jeff がロールバックは考慮されないというコメントを書いていることに注意してください。ただし、ユーザーが投稿をロールバックする代わりに編集し、古いものを貼り付けるだけの場合、事実上、前の作成者による変更が元に戻されます。テキストは、情報を思いついた元の作成者ではなく、「ロールバック」した人に起因します。

この実装のソース コードは、Visual Studio 2008 の場合、ここにあります。このソリューションでは、スクリーンスクレイプなどの処理は行われず、投稿の内容は TestData クラスのソースにハードコードされ、引用符などで適切にエスケープされることに注意してください。テキストを置き換えるには、そのファイルを変更するか、プログラムの外部からコンテンツを読み取る方法を実装する必要があります。

とにかく、アルゴリズムをもう少し詳しく説明します。


  1. 元のリビジョンと同じ長さの整数の配列を作成します (実際には、UTF8 を使用してバイトにエンコードしました。これが使用した長さです)。この配列に元の作成者のユーザー ID を入力し、元の作成者が現在リビジョンの 100% を所有しています。すべての文字/バイトは彼のものです。
  2. 最初のリビジョンと次のリビジョンを比較します。この比較により、操作のリストが生成されます。これらの操作を使用して元のリビジョンを取得し、それに操作を適用すると、次のリビジョンを取得できます (詳細は後述)。
  3. 元の投稿が、準備したユーザー ID の配列 (現在、最初の作成者の ID に等しい値の束のみを含むもの) であると仮定し、これに操作を適用します。これにより、ID の新しいリストが生成されます。そのうちのいくつかは最初の作成者であり、いくつかは 2 番目の作成者になります。
  4. 2 番目のリビジョンとユーザー ID のこの新しいリストを保持し、このデータ、次のリビジョン、次のリビジョンなどの間でステップ 2 + 3 を最後まで実行します。

この時点で、どのユーザーが各文字を追加したかを示すユーザー ID のリストが表示されます。

比較による操作は、次の 2 つのいずれかです。

  • 新しいバイトを挿入
  • いくつかのバイトをコピーします

比較結果の使い方は、古いコンテンツ(最初の投稿)に操作を適用して、次のリビジョンを作成するというものです。基本的に差分です。

操作をユーザー ID のリストに適用する場合、コピーする場合は単純にコピーし、挿入する場合は常に、操作に格納されている長さと同じ数の ID を挿入します。

例を挙げましょう:

元の投稿:

This is the first post

次の投稿:

This is the next post, it is based on the first post.

したがって、操作のリストは次のようになります。

  1. コピー 12 文字 'This is the '
  2. 「次」を挿入
  3. 5文字「投稿」をコピー
  4. 17文字を挿入「、に基づいています」
  5. 14文字をコピー 「最初の投稿」
  6. 1 文字「.」を挿入します。

代わりにユーザー ID を使用する場合、最初に次の配列が必要になります。

0000000000000000000000
This is the first post

次に、操作を適用し、挿入ごとに代わりに 1 を挿入します。

00000000000011110000011111111111111111000000000000001
This is the next post, it is based on the first post.

これで、0 と 1 の数を単純に数えることができます。

  1. 0: 31
  2. 1の:22

ユーザー 0 は投稿の 31/(31+22) を所有し、ユーザー 1 は投稿の 22/(31+22) を所有しています。

パーセンテージに変換すると、ユーザー 0 は 58%、ユーザー 1 は 42% を所有しています。

さて、このアルゴリズムの問​​題は、ロールバックの問題と、失われた/削除されたコンテンツの追加です。

たとえば、ユーザー A、B、C がいて、ユーザー A がユーザー B を本当に怒らせる何かを投稿した場合、ユーザー B は入ってすべてを削除し、「THIS IS CRAP」だけを追加します。ユーザー C はこれを見て、投稿を編集し、A が投稿したものすべてを追加して、場合によっては修正します。ユーザー C は現在、投稿の 100% を所有しています。

しかし、上記の問題を解決する方法がわかりません。

興味深い場合は、今夜遅くにこれを行うコードを投稿します。


「クイック ブラウン フォックス」の例に適用して、ユーザーの番号を 1 ~ 3 に変更すると、次のようになります。

User 3 owns 75% (45 / 60) of the final post
User 1 owns 25% (15 / 60) of the final post

「ときどき」部分のみを追加したユーザー 2 は、後で削除されたので、リストから削除されていることに注意してください。

投稿のIDは次のとおりです。

The quick brown fox jumps over the lazy dog.
11111111111111111111111111111111111111111111 (44 = 100%)

The quick brown fox jumps, sometimes.
1111111111111111111111111222222222222 (25 / 12 ~ 68% / 32%)

I always see the speedy brown fox jumping over the lazy dog.
333333333333333333333331111111111111113333333333333333333333 (45 / 15 = 75% / 25%)

アルゴリズムが処理するもの:

新しい投稿を作成するときに何かをコピーすると、アルゴリズムはコピーされた要素を適切に属性付けします。例:

This is the first post, which is cool
1111111111111111111111111111111111111

This is the second post, which is the second post.
11111111111122222211111111111111112222222222111111
                               ^-- copied ------^

このアルゴリズムの唯一の問題、およびこの投稿全体の唯一の問題は、私が直感的に公正な結果と呼ぶものを生成するかどうか完全には確信が持てないことです。私はプログラムをハックしただけかもしれませんが、実際に人々が受け入れるものを実際に生成するかどうかを判断するために、非常に多くのエッジケースでさらに多くのテストを行う必要があります.

また、最初の投稿から単純に移動すると、数パーセントなどの小さな部分だけが私のものになります。アルゴリズムは本質的に差分アルゴリズムであるため、1 バイトまたは数バイトのコピー操作を出力するコストが、それをそのまま挿入するコストを上回ることがあります。それらは元の投稿からコピーされた可能性があります。

于 2009-01-08T15:48:20.087 に答える
4

以前のバージョンに対する各人の編集のレーベンシュタイン距離を単純に計算するのはどうですか。次に、各ユーザーの距離スコアを合計し、すべてのユーザーの距離スコアの合計に対するユーザーのパーセンテージを計算します。

距離を計算するためのC#コードを次に示します。

于 2009-01-08T14:47:30.257 に答える
4

私があなたの質問を正しく理解していれば、IBM がウィキペディアの研究プロジェクトでしばらく前に行ったことをやろうとしているように見えます。つまり、他のユーザーに最も受け入れられたテキストに対する誰のリビジョンと、時間の経過とともにテキスト全体がどのように変化したかを確認します。プロジェクトの名前はヒストリー フローヒストリーフローでした。そのしくみは、アルゴリズムがどのように機能したかの非常に優れた概要を示しています。

于 2009-01-08T14:39:37.777 に答える
3

頭のてっぺんから次のようなことをします。

  • 行や文字ではなく単語を数えるのは理にかなっていると思います
  • 元のリビジョンを単語にトークン化し、それぞれに作成者を添付します
  • 改訂履歴をステップスルーし、単語が追加されたら、作成者をそれらに添付します。
  • 単語が削除された場合は、忘れてください。
  • 単語が変更された場合は、それらを削除/挿入としてカウントするか、スペルの修正が新しい作成者に起因しないように、ある種の文字ベースのしきい値を設定できます。
  • あなたは最初にそれらを書いた人に対する単語のリストになってしまいます
于 2009-01-08T13:46:56.370 に答える
3

これは、Pythonのdiffアルゴリズムを実装/活用する場合に機能difflibします。いずれの場合も、おそらく何らかのdiffを実行する必要があります。このスニペットは、テキストチャーンが最も多いユーザーを勝者と呼びます。

ハードコーディングすみません。

#!/usr/bin/env python

import collections
import difflib
import logging
import pprint
import urllib2
import re

class OwnageDeterminer(object):

    add_coefficient = 1
    remove_coefficient = .5

    def __init__(self, edits):
        self.edits = edits
        self.counts_by_username = {}

    def __call__(self):
        edits, counts_by_username = self.edits, self.counts_by_username
        for i, edit in enumerate(edits):
            username = edit['username']
            unique_counts = {'added': 0, 'removed': 0}
            existing_text = edits[i-1]['text'] if i > 0 else ''
            new_text = edits[i]['text']
            for char_diff in difflib.ndiff(existing_text, new_text):
                if char_diff.startswith('+'):
                    unique_counts['added'] += 1
                elif char_diff.startswith('-'):
                    unique_counts['removed'] += 1
            user_counts = counts_by_username.get(username, collections.defaultdict(int))
            user_counts['removed'] += self.remove_coefficient * unique_counts['removed']
            user_counts['added'] += self.add_coefficient * unique_counts['added']
            counts_by_username[username] = user_counts
        winner = None
        winning_score = 0
        score_by_username = {}
        for username, counts in counts_by_username.iteritems():
            score = counts['removed'] + counts['added']
            if score > winning_score:
                winner = username
                winning_score = score
            score_by_username[username] = score
        logging.debug('Scores: %s', pprint.pformat(score_by_username))
        return winner


if __name__ == '__main__':
    logging.basicConfig(level=logging.DEBUG)
    site = urllib2.urlopen('http://stackoverflow.com/revisions/327973/list')
    contents = site.read()
    regex = re.compile(r'(/revisions/viewmarkup/\d+).*?/users/\d+/([\w-]+)',
                       re.MULTILINE|re.DOTALL)
    revisions = regex.findall(contents)
    print revisions
    edits = []
    for reluri, username in sorted(revisions, key=lambda t: t[0]):
        text = urllib2.urlopen('http://stackoverflow.com{0}'.format(reluri)).read()
        edit = {'username': username, 'text': text}
        edits.append(edit)
    od = OwnageDeterminer(edits)
    print od()

出力:

DEBUG:root:Scores: {'blorgbeard': 0.5,
 'dave-markle': 0.5,
 'dbr': 1172.0,
 'gatekiller': 69.5,
 'joseph-ferris': 0.0,
 'lkessler': 0.0,
 'mark-harrison': 592.0,
 'mdb': 3.0,
 'onebyone-livejournal-com': 0.0,
 'paul-oyster': 482.0,
 'rob-wells': 0.0,
 'simucal': 1070.5,
 'skiphoppy': 0.0,
 'thesoftwarejedi': 701.0}
dbr

複雑さに関するDifflibドキュメント

タイミング:基本的なRatcliff-Obershelpアルゴリズムは、最悪の場合は3次時間、予想される場合は2次時間です。SequenceMatcherは、最悪の場合の2次時間であり、予想される場合の動作は、シーケンスに共通する要素の数に複雑に依存します。最良の場合の時間は線形です。

もう1つの優れた点は、この勝者の計算が線形であるため、初期化の負荷が大きい場合でも、元の結果をキャッシュして、新しい編集に対して増分更新を実行できることです。

于 2009-01-08T13:49:23.807 に答える
3

誰もそれを所有していません。所有権の譲渡は「コミュニティ ウィキ」の精神に反し、非生産的な編集合戦につながる可能性があります。

于 2009-01-08T15:24:29.560 に答える
2

問題は、文字の削除が文字の追加と同じくらい有効かどうかです。Diff を使用するとうまくいくかもしれませんが、最も多く追加した人が最も有効な編集者であるとは限りません (ある人は、他の人がページを書くために必要とするものを 10 文字で書くことができます)。

したがって、ここには2つの要因があると思います。

  • 変化量
  • 変化の質

したがって、追加/削除された単語をポイントスコアに単純にマップするものを書きたくなるでしょう。これに何らかの品質係数 (これは外部パラメーターである必要があります) を追加すると、組み合わせた値を並べ替えに使用できます。

アイテムが編集されるまでの距離に基づいて、ある種のプリミティブな「品質係数」を生成することはほぼ間違いありません。したがって、私が書いたものが12回目の編集まで変更されなかった場合、それはそれほど間違っていなかったはずです(追加されるとすぐに変更された品質の低いものと比較して)。

于 2009-01-08T13:58:55.393 に答える
2

これは wiki です。なぜ各編集者に変更の重要性を選択させないのでしょうか? 次のようなドロップダウンを提供します...

編集内容を修飾してください:

  1. いくつかのマイナーな編集 (スペル、文法など)
    • 多くのマイナーな編集
    • いくつかの重要な編集 (特定の事実、数値などの変更)
    • 多くの重要な編集
    • いくつかの主要な編集 (論文、結論などの変更)
    • 多くの主要な編集

次に、組み合わせた回答を使用して所有権を推定します。

于 2009-01-09T06:03:45.523 に答える
2

このアイデアはどうですか?

  • 投稿が元のテキストから x% 以上変更されるまで、元の投稿者の名前が表示されます
  • このパーセンテージは、「x ユーザー、y 編集、オリジナルの z%」のように表示されます。
  • 現在存在する最後の編集内容にも差分量がある可能性があります。たとえば、質問への最初の編集がマイナーな追加であったことを明確にします。

要点は、ある程度変更した後は、所有者が誰であるかは問題ではないということです。wiki コンテンツに「所有者」を割り当てようとするのは非生産的であるというユーザーの意見に同意します。

于 2009-01-09T22:29:45.153 に答える
1

文字数は難しいと思います。

どうですか:

Break latest revision into a set of sentences. 
//Sentence is any text fragment surrounded by punctuation

For each Sentence
    Find which user created that sentence. 
    Add 1 to the user who created the sentence 
    Add 1 to the number of sentences

For Each user 
    % ownership = Count for that user / Number of sentences. 

その文を作成したユーザーを見つける。
完全一致が必要な場合は、センテンスとリビジョンを一致させるのは簡単ですが、部分一致のほうがよいでしょう。

この部分一致を行うには...

文の断片から一般的な単語を削除し、各リビジョンの削除されたバージョンでその削除された断片を検索します。一番最初にヒットしたのは、所有者が書いた文章です。

オプション: (一般的な単語の削除の代わりに)

  • 文中の各単語について、各単語を最初と最後の文字に要約します。これは、スペルミスなどを説明します。
  • 文の断片の最初と最後の 2 つの単語のみを使用します。
  • 単語の 80% が一致すれば、所有者を特定するにはおそらく十分でしょう。(これはコンピュータにとって難しいことであり、キャッシュすることはできません)

よくある単語の削除

あなたはすでに検索のためにこれを行っているので、ライブラリなどはすでにそこにあります。他の誰かの式を使用する場合でも、開始する前に各リビジョンで CommonWordStrip を実行する必要があります。

于 2009-01-08T13:59:20.697 に答える
1

この問題を適切に解決するための鍵は、編集で何が起こっているかについての追加情報を取得することです。このメディアで利用できる追加情報は、質問に対する投票率と回答率です。したがって、誰かが編集を行って質問に多くの賛成票、コメント、および応答が得られた場合、その編集は非常に価値がありました。非常に長い間サイトに掲載される前に編集された、まったく新しい未回答の質問には、おそらく特別なケースが存在します。

レーベンシュタイン距離アルゴリズムを使用して投稿がどの程度変更されたかを確認し、編集後に質問に寄せられた投票、コメント、および回答の数によって編集を重み付けする必要があります。

Let n = total revisions
Let m = the revision number of a poster
Let post[it] = array with text of post at revision 'it'
Let votes[it] = votes that revision 'it' received (also add bonus for comments/answers)
value = 0
for (it = m; it < n; ++it) {
  value += (Levenshtein(post[it-1], post[m]) / average_length_post) * (votes[it])
}

各投稿の値を計算すると、投稿の所有権は、そのユーザーによるすべての編集の合計値を、その投稿のすべての編集値の合計で割ったものになります。

于 2009-01-08T16:26:04.597 に答える
0

可能かどうかはわかりませんが、追加された文字数を数えることはできます。

例:

  • ユーザー 1 が 400 文字の質問を送信します (ユーザー 1 は 400 文字中 400 文字です)
  • ユーザー 2 が 40 を削除して 60 を追加 (ユーザー 1 は 360、ユーザー 2 は 60)

元に戻す場合は、以前のユーザー/文字数にも戻す必要があります。

でも...元のポスターに名前を付ける方が簡単で公平かもしれません...

よく考えてみると、私は多くの編集を行っていますが、プレゼンテーション (形式と文法) を変更するだけでコンテンツを変更していないため、自分自身を tekst の「所有者」とは考えていません。

于 2009-01-08T13:38:39.973 に答える
0

最初のコンセプトに重みを付ける必要があります。スペル修正には重みを付ける必要があります。文法/構造には重みを付ける必要があります。言葉遣いには重みを与える必要があります。簡潔さを重視する必要があります。等...

重み付けはそれを行うための唯一の公正な方法ですが、決定することも不可能です.

于 2009-01-08T15:44:38.333 に答える