Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
227 lines (166 sloc) 9.06 KB
Samizdat Concepts
Member is a registered user of a Samizdat site (synonyms: poster,
visitor, reader, author, creator). Members can:
- post and edit messages, create tags, relate messages to tags (see Tag
section), and vote on relations (see Proposition and Vote section);
- view messages, use and publish filters based on relations between
messages and tags.
Group of members called "moderators" with access to site moderation
interface can be defined. Moderation interface allows to hide, takeover,
replace and reparent messages and disable non-moderator member accounts.
A member can declare trust or distrust to another member by registering
a vote on a relation between another member and an appropriate tag,
which can range from overall frienship to a trust rating in some
specific area of endeavor. Filtering adjustments can be applied to
messages posted by trusted members.
Note that such trust relation is unidirectional, when member A marks
member B as his friend, site won't assume that A should be treated as
B's friend as well.
There is exlicit design decision behind absense of more strictly defined
member groups. Aside from sheer complexity that this feature would add
to the design, power relationships involved in decision making about
group membership and group responsibility are inappropriate for
cooperative open publishing system.
Message represents basic unit of information inside of Samizdat site
(synonyms: article, post). Messages can be used to represent other
classes of Samizdat resources, such as filters, tags, material items,
etc. Following MIME classes should be supported:
- none (default): sequence of paragraphs stored as is;
restricted to plain text, blank lines separate paragraphs, (HTTP) URLs
on a line by itself may be rendered as hyperlinks;
- text/plain: verbatim plain text;
- text/textile: hypertext in Textile format;
- text/html: hypertext in HTML format;
- application/x-squish: site filter in form of a user-defined Squish RDF
- image/*: jpeg, png, gif [, tiff, svg, jpeg2000];
when referenced from within text message, may be rendered as inline
image or thumbnail;
- audio/*: Ogg Vorbis, mp3 [, RealAudio];
- video/*: avi, Ogg Tarkin, wmv, [ mpeg, RealVideo, QuickTime].
Content types that belong to the supported MIME classes but are
classified under application/* MIME class (e.g. application/x-ogg), may
be aliased into more appropriate MIME class (audio/ogg-vorbis) for
cleaner classification.
Threads can be used to group messages into discussions: follow-up
messages should have "inReplyTo" property pointing to the original
message, with the first message in a thread determined by having no
value to the "inReplyTo" property.
RDF statements are used as a generic mechanism for structuring the
Samizdat site content. Any statement is a resource that represents a
triple of {subject, predicate, object}, where subject is a resource
being described, predicate is a property name, and object is a literal
value or reference to another resource (see for more
Samizdat bases its structure on the concept of a Tag. Tag is a kind of
resource that, when related by an RDF statement to other resources,
allows to group similar resources together and to evaluate resources
against different criteria. In other words, content classification
metadata concentrates around tags.
Any resource can become a tag, but it is recommended to use messages
that carry concise and informative textual content. Being a resource,
tag itself can be related to another tag in the same way as any message.
This allows to create complex structures of related tags, which can then
be used to categorize, filter, and sort large amounts of information
with arbitrary precision.
When presenting user with a list of available tags, site should order
them by usage (number of related resources) to encourage further use of
well-known, popular tags and to reduce role of less popular tags to more
specific resource classification. Site can also offer an option to
classify and filter tags by other criteria, e.g. by relation to some
other tags.
Following general tags may be available at the site setup time:
- Quality: overall quality of the resource;
- Priority: importance of the resource to site members;
- Relevance: how much content of the resource is related to the encasing
aggregate resource (negative Relevance marks off-topic resources).
Each site can create its own custom tags, representing different topics
of interest, site sections, or rating criteria. In addition to the
general tags, following optional rating criteria are suggested:
- Fairness: whether resource fairly represents all sides of the story;
- Representation: readability, quality of prose, cinematics, etc.;
- Factuality: extent of sources usage vs. speculation;
- Novelty: whether resource adds anything new to the body of
information (low Novelty highlights redundant resources);
- FrontPage: whether resource is worthy of adding to the site's default
front page.
Special tag "Friendship" can be used to establish relations of overall
friendship between site members (see Member section).
It is recommended that, instead of the suggested generic tags, resources
of high priority and relevance to the site membership are used as tags
that highlight topics that are of interest to site audience.
Proposition and Vote
Proposition is a subclass of RDF statements which can be approved or
disapproved by votes of site members. Vote is a record of vote cast for
particular proposition by particular site member.
Default rating system should let voter select from ratings "-2" (no),
"-1" (not likely), "0" (uncertain), "1" (likely), "2" (yes). Total
rating of proposition is equal to the average value of all votes cast
for the proposition; resources with rating below "-1" may be hidden from
site's default front page.
Exact mechanism of rating calculation and filtering thresholds can be
determined by each site at run time; following considerations should be
taken into account by alternative voting and filtering schemes:
- messages with lower rating but higher absolute number of votes are
probably more important and relevant than higher rated messages with
small absolute number of votes (e.g. quorum threshold);
- vote weight can be adjusted according to relative voting activity of
the voter, or other voter quality determination heuristics;
- default filtering threshold should be adjusted according to the site
activity level and average quality;
- reader should be presented with amount of information that can be
reasonably expected to be comprehensible in a given time scope.
In addition to filtering by community-approved propositions, site
content can be aggregated, versioned, or otherwise grouped using
following properties, available to the message author.
Next version of the message, written either by author or by any other
site member. Several new versions of the same message may represent fork
or alternative edit of a message, in that case message with several
"dct:isVersionOf" properties would represent merge of respective
For further clarification, following versioning-specific tags can be
related to a "dct:isVersionOf" statement by author:
- Correction: minor correction that doesn't change structure or meaning;
- Rewrite: full rewrite of the message;
- Summary: short digest or summary of this and possibly other messages;
- Translation: translation to a different language;
- Mirror: alternative location of the message.
Comment: Proper handling of alternative locations requires web of
trust and message signing to ensure that all alternatives point to
exact copies of the message.
dct:tableOfContents, dct:isPartOf
"dct:tableOfContents" property contains RDF sequence of next-level parts
of the message. Each resource in the sequence should have "isPartOf"
property pointing to the parent message.
Real-world Resource Sharing
Following resource classes can be used to facilitate sharing of
real-world resources between site members:
- Item: an instance of an item; all identical items share the same
"description" property, referring to the message with an item
description, such as table of contents, review, picture, etc.;
- Possession: record of transfer of item instance from one member to
another; "givenTo" property of the last Possession record in the
database constitutes "possessor" property of Item resource.
Comment: Possession record should be created by the item receiver;
care should be taken to avoid fraud in situations when acts of actual
transfer and its registration are separated in time and space.
Service can be registered as an item description too, with individual
items corresponding to points of service, and with no Possession
records. As a non-obvious but useful application of this mechanism,
service item "GnuPG Key Exchange" can be used to publish intent to and
arrange PGP/GnuPG public key exchange (key-signing parties).
todo: calendar and collaboration tools knowledge is needed.