A complete "social kernel" database and back-end, to be implemented with with relational-JSON persistence (with PostgreSQL 9.6+) and some "Agile Framework" (as Django, Spring, CakePHP, etc.); based on socKer-simple.
It is a model to be used as core at any CRM-like system... With precise information and a RDF semantic. The basic entities are defined in SchemaOrg:
-
Agent: a generalization of sc:Person, sc:Organization, foaf:Group, and others, as foaf:Agent definition.
The specializations (eg. Person) can be implicit in a attribute, or explicit when implementing some relevant relation in the system. PS: avoid confusion with sc:agent. -
ContactThing: a generic sc:Thing that can be a sc:Place (its sc:PostalAddress), a wd:telecommunication device (its eletronic address like telephone number or e-mail string), or other. All ContactThing have an standard address (an wd:URI) and (optional to informe) an wd:owner.
-
ContactPoint: a sc:ContactPoint, linking Agent with ContactThing.
-
AgentsRelation: an Agent-Agent relationship, to hold stable and usual metadata about any kind of relations (Person-Organization, Person-Person, etc.).
The main enhances about previous didactic socKer-simple are:
- generalization of ContactPoint, for postal adress and others.
- add agent-agent relationships (AgentsRelation) that enhance the informations of the catalogue.
- add secondary relations: AgentsRelation's ContanctPoint for special cases (eg. foaf:workplaceHomepage as a TelecomPoint of a Person-Organization relation); Place-ContactPoint relations as ch:areaServed (or sc:validIn, sc:geographicArea, etc.), extended for Place-Place relations (eg. sc:containedInPlace).
LEGEND: isa and ispart in class-inheritances denotes "is a" and "is part of" forms. A digit after it, as "isa2", is a label for group the children. The indications "dj" and "ov" in a group, as "isa1dj", indicates that children are disjoint and overlaped sets, respectively. Similarly "of" in cardinality is a label for "participation group", and can be "of1", "of2", "of1dj", "of1ov", etc.
See build3-main.sql
With the flexible approach used in the project, the class/subclass relations can be modeled by structure or simply by a enumerated type choice (ENUM). The structure and validation of JSON can be performed in runtime, only indicating the ENUM type.
Some examples will be described as illustration. The complete list of definitions are in this spreadsheet, relesead as enum.csv, and transformed automatically into a table (enum_item), in the SQL initialization.
| Agent (agtype) | Agent (legaltype) | thype/Telecom | thype/Places |
|---|
- Organization is a wd:Organization
2. Person is a sc:Person
3. Group is a foaf:Group
4. Robot is a wd:SoftwareAgent | 1. sc:Corporation,
2. sc:GovernmentOrganization
3. sc:NGO
4. ... | 100. sc:telephone
102. sc:email
104. wd:HomePage
... | 10. sc:Country
12. sc:City
14. sc:PostalAddress
...
Note: the sc:Organization is equivalent to wd:SocialGroup, not wd:Organization. So take care wih it and all its chieldren (see thematic variants), that have semantic intersections with Group variants.
Modeled as AgentsRelation class:
| Relation type | rule examples (of SchemaOrg) |
|---|---|
| Organization-Organization | subOrganization, LocalBusiness, sponsor, ... some OrganizationRoleTypes, ... |
| Organization-Person | founder, employee, sponsor, affiliation, , ... some OrganizationRoleTypes, ... |
| Person-Person | children, ... |
| Agent-Agent | follows, ... |
To develop a simple framework for
-
Use and expand the scope of the VCard standard, to manage contacts and its relationships in a database, with SQL and SPARQL queries.
-
Store stable and curated data: digital preservation of original data (like LOCKSS) and subsequent data processing (like git commit or Mediawiki's page history).
-
Complete map: adequate object-relational mapping and complete semantic mapping.
-
A framework for back-end and "data in bulk", not for end users.
Incrementally: both, implementing this project and adopting this model.
See SQL prepare at src/README.md.