SIOC/ArchitecturalDecisions
Architectural Decisions
This page documents architectural decisions made to develop SIOC (Semantically Interlinked Online Communities). Architectural decisions are those that need to be made from an overall system perspective. Essentially, these decisions identify the key structural elements of the system and relationships.
Conformance Terms
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Foreword
SIOC's intention is to define classes and properties which may be used to document the structure of communication within communities. To archive this, SIOC contributes to the Semantic Web be using RDF and related technologies. SIOC introduces terms like Community, Forum, Post and User (and some more) to describe the structure of communication on different platforms like Weblogs, Mailing-lists or Newsgroups. SIOC development is mainly coordinated via a Mailinglist and IRC. SIOC development is an evolutionary process and this document tries to transport the main ideas behind SIOC, its concepts and the process of development itself.
Class and Property naming schema
Buy or Build
Reusing well known other Ontologies
Subclassing Classes and Properties
Best Practices
Change Management
Changes to the SIOC Specification MUST be made formally with a change request to the SIOC Mailinglist. Preparing discussion MAY take place on the Mailinglist itself or on IRC.
A change request MUST include the following information:
- Name and E-Mail of the requester
- Type of change: "addition", "change", "deletion"
- Description of change
A change request SHOULD include:
- a statement of the positive and negative impact of change
- include a subject line which starts with "CHANGE: "
A change request MAY include:
- examples
- additional information
After receiving a change request on the Mailinglist the core development team will consider wether to include the change, reject for further modification of the change request or reject permanently. Each decision how to handle the change request MUST include statements why the decision has been made. Change requests SHOULD be handled by the core development team within four weeks.
Core development team
CaptSolo: please fill in!!