Content stamping/lang-ko

환영합니다 | Portal | XO Korea | Deployment | Content | Hardware | Software | Mesh Network | Ethics | LOS | XO City | Accreditation | Consortium

'스탬핑'은 자신이 속한 그룹 구성원들이 자신의 컨텐트를 심사하는 시스템입니다. 명료성을 위해 "스탬프"라는 용어대신 "리뷰"라는 말을 사용할 것입니다. 일반적 논의는 annotation을 참조해 주십시오.

개괄적 개념은 어느 한 주어진 시점에, 컨텐트 또는 작업에 대해 다양한 리뷰가 제공되는 것입니다. 하나의 리뷰 그룹 내에서, 우리는 소통을 가정하며, 해당 그룹의 한 멤버에 의한 가장 최신의 리뷰가 해당 그룹의 오피니언을 대표합니다. 다양한 관점에서, 상이한 그룹들의 리뷰에 대해 상이한 가중치를 부여함으로써 라이버러리가 만들어질 수 있습니다.

문제

다양한 컨텐트가 나올 것이므로, 그 품질을 평가할 잣대가 필요합니다.

컨텐트와 품질을 평가하는 다양한 척도가 있으며, 종종 중첩되기도 합니다. 가령, 단순성, 압축성, 문법, 정보성, 오락성, 연령 적합성, 시각적 미, 전기적 깊이 등이 각기 평가항목으로 적용될 수 있습니다. 상이한 사람들은 각기 상이한 측면에 관심과 평가 능력을 가질 것입니다.

품질의 상이한 측면들에 대한 공평하고 유효한 우선순위를 정하는 것은 여전히 어려운 일입니다.

바람직한 특성들:

• 비 공격적 -- 리뷰 과정은 컨텐트 제공자에게 부담되지 않아야 합니다.
• 낮은 진입장벽 -- 새로운 그룹이 자격 증명 과정없이 리뷰를 시작하고, 그들의 내부 시스템을 개선할 수 있어야 합니다.
• 표준의 다양성 -- 원칙에 강하게 반대하는 그룹들도 동일한 작업을 갈등없이 리뷰할 수 있어야 합니다.
• 관점의 다양성 -- 가용한 스탬프와 리뷰에 기반하여, 누구라도 자신의 의견을 제시할 수 있어야 합니다.
• 리뷰와 관점의 분리 -- 그룹을 설정하고, 리뷰하는 것이 그러한 리뷰들을 이용하는 것과 분리되어야 합니다. 이로써, 새로운 그룹의 탄생이 기존의 관점을 방해하지 않게 됩니다.

제안

우리는 컨텐트 품질에 대한 정부를 수집, 배포 및 이용하기 위한 매우 개괄적인 프레임워크를 설명합니다 (리뷰). 정보의 예상되는 용도는 해당 컨텐트의 관점을 생성하는 데 있지만, 우리는 아직 그 부분을 깊이있게 파악하지 못했습니다.

이 스킴은 원래 위키피디아를 염두에 두었지만, 보다 폭넓게 적용될 수 있습니다. 특히, 이것의 보다 단순화된 버전은 서버와 노트북 상에 배포할 컨텐트를 선정하는데 유용하게 쓰일 수 있습니다.

개념

• 그룹 -- 검토자 단체.
• 리뷰 -- 특정 그룹에 속한 이용자의 작업을 평가
• 리뷰 데포 -- 리뷰와 관련 그룹의 데이터베이스
• 평가 기능 -- 어느 한 작업의 리뷰들을 바탕으로 수치적인 등급을 메기는 기능 (위키피디아와 같은 경우, 해당 아티클의 카테고리를 고려해야 하지만, 이는 복잡한 일입니다.)
• view -- The application of a valuation function to determine what to display. (For example, we might specify that an article is visible iff it has a positive valuation.)
• stale review -- a review that applies to an older version of a work

Architecture

• Reviews are meta-data that can be stored in a repository completely independent of the content repository.

• Groups must register; this process should be fairly automatic and not arduous, but in place to prevent gaming particular views.

• Valuation functions can be created and maintained independently of both content and review repositories.

• Review depots can be created without any authorization, but a valuator will only consider groups that it knows about, and it may demand some credentials or process. A review depot can set its own policy for group registration.

• Reviews could be made specific to article revisions (i.e. automatically voided by unauthorized changes), but life is much simpler (and likely better) if we make them sticky (requiring explicit revocation in the wake of changes).

• Articles can be identified by URI.

• A review repository might have the following set of database tables:
  • reviews: (article-id, group-id, user-id, rating, comment, timestamp)
  • groups: (group-id, user-id)
  • users: (user-id, authentication info)

• It should be easy to add and remove (or deactivate) records and to retrieve the set of reviews associated with a given article. Naturally, mutative operations require some authentication.

Operational notes

Groups must be administered, but the mechanism for this need not be mandated. If a group is poorly administered, its reviews can be devalued.

Review depots need to know about groups, and valuators need to know about review depots. Since each group is administered by a single review depot, any valuator that knows about that review depot can automatically discover new reviews.

Implementation

• Authentication might use OpenId.

• The database needn't be relational, but it might as well be.

Interface

• A user (somehow) selects a view, which (somehow) determines what he sees.

• If the view presents a non-current revision of an article, then an attempt to edit it is treated more or less like any attempt to edit a non-current revision.

• If you edit an article already reviewed by a group to which you belong, that review is automatically refreshed (i.e. its timestamp is updated). That is, you're presumed to be doing no harm in your areas of authority.

• It should be easy for members of a group to get notification of extra-group changes to an article reviewed by that group so that they can either refresh or alter that review.

• If you visit or edit an article with a stale review (i.e. which is older than the current version) that you are authorized to change, then the page should note this and encourage you to check the change and update the review.

Starting Simply

• Use URIs for article-ids.
• Use a single review depot.
• Let reviews be sticky (i.e. not version-specific).
• Have a browser extension (or frame?) that, for each group to which you belong, shows the current review of the article being viewed and lets you change it.
• Skip valuation functions for now; instead, just have another extension that shows what reviews the current article (page) has.
• The extensions might also indicate whether a review is stale.