Skip to main content

European Client Register

Project Introduction

The European Client Register is a collaborative initiative between Open Register, Nextcloud, and government agencies from France and Germany. This project aims to transform European standards and definitions into a practical, interoperable register that can be used by governments throughout Europe to store and manage client data in a standardized way.

European Collaboration

This project represents a cross-border effort to address common challenges in public administration:

  • Nextcloud contributes expertise in secure, open-source data storage and collaboration
  • French government agencies provide insights from their "État Plateforme" (State as a Platform) initiative
  • German government agencies share experience from their "Digitale Verwaltung" (Digital Administration) program
  • Open Register offers the technical framework for implementing standardized registers

Together, we're working to create a reference implementation that demonstrates how European standards can be applied in practice to create interoperable, privacy-respecting client data management systems.

Common Ground Integration

This project aligns with the Common Ground principles developed in the Netherlands, which promote:

  1. Component-based architecture - Building modular, reusable components
  2. Data at the source - Storing data once and using it multiple times
  3. Standard APIs - Using standardized interfaces for data exchange
  4. Open standards - Adopting open standards for interoperability

The Client Register serves as a key building block in the Common Ground ecosystem, providing a standardized way to store and access client information across different government services and applications.

Connectivity through Standardization

By implementing European standards in a practical register, this project contributes to the broader goal of "connectivity through standardization" - enabling different systems to work together seamlessly through shared standards and interfaces.

Key standardization efforts we're building upon include:

  • European Interoperability Framework (EIF) - Providing guidelines for public administrations on how to improve interoperability
  • ISA² Programme - Developing digital solutions that enable public administrations to provide interoperable services
  • Single Digital Gateway Regulation - Establishing a single digital gateway to provide access to information and procedures across the EU
  • Once-Only Principle - Ensuring citizens and businesses provide data only once to public administrations

Purpose and Scope

This document presents research and implementation guidance for building client registers based on European standards. It aims to:

  1. Identify and analyze relevant standards for client data management
  2. Compare different approaches to implementing these standards
  3. Provide practical guidance for implementing a standards-compliant client register
  4. Demonstrate interoperability with existing systems and standards

The resulting client register design serves as a reference implementation that can be adapted by government agencies across Europe to meet their specific needs while maintaining interoperability with other systems.

References and Standards

This research and implementation guide draws upon the following standards and references:

Core Standards

Semantic Web Standards

Business Standards

EIDAS Regulation and Core Vocabularies

The eIDAS Regulation (Electronic Identification, Authentication and Trust Services) establishes a legal framework for electronic identification and trust services across EU member states. While the regulation itself doesn't mandate specific data models, implementations that support cross-border identification should align with the EU Core Vocabularies.

The European Commission officially recommends the Core Vocabularies for public administrations and entities that interact with them. In many EU-funded projects and cross-border services, these vocabularies are effectively mandatory.

Key references:

Mandatory Standards in European Context

Key references:

Commercial CRM Systems

Dutch standards and guidelines

The Nederlandse API Strategie (Dutch API Strategy) provides guidelines for REST APIs in the Dutch public sector. Our client register design aligns with these guidelines:

  • Use of JSON as the primary format
  • Consistent naming conventions
  • Support for filtering, sorting, and pagination
  • Proper error handling

Key references:

Regulatory and Standards Compliance

When implementing client registers in European contexts, it's important to understand that certain standards are not merely recommendations but regulatory requirements or officially endorsed standards that must be applied in specific scenarios.

Validation Resources

To ensure compliance with these standards, the following validation resources are available:

By using these validation tools during implementation, you can ensure that your client register meets all applicable standards and regulatory requirements.

API Specification

To complement our standards-based client register design, we've created a comprehensive OpenAPI Specification (OAS) document that defines the API endpoints, request/response formats, and data schemas for implementing the client register.

OpenAPI Specification

The complete API specification is available as an OpenAPI 3.0 document:

View API Documentation

This specification includes detailed definitions for:

  • Client entities (Person and Organization)
  • Task management
  • Message handling
  • Note management
  • Relationship modeling
  • Search and filtering capabilities

Overvieuw Relationships Between Entities

All these entities are interconnected in our client management system:

Entity Relationships

The diagram above shows how:

  1. Clients are the central entity
  2. Tasks are associated with clients (one client can have many tasks)
  3. Messages are linked to clients (communication history)
  4. Notes are attached to clients (observations and information)
  5. Tasks can be related to other tasks (for dependencies or subtasks)

European Semantic Interoperability Standards

In addition to the standards we've already discussed, the European Union has developed several semantic interoperability initiatives that provide relevant data models and vocabularies for our client management system.

Core Vocabularies

The EU Core Vocabularies are simplified, reusable, and extensible data models that capture the fundamental characteristics of entities in a context-neutral way. Several of these are directly applicable to our client register:

The Core Person Vocabulary defines a simplified, reusable data model for describing natural persons.

Our PropertyCore Person PropertyNotes
namefullNameFull name of a person
givenNamegivenNameFirst name
familyNamefamilyNameLast name
birthDatedateOfBirthDate of birth
addressregisteredAddressOfficial address
identifieridentifierUnique identifier

Client Object

For our client information, we'll use the European Core Vocabularies (Core Person and Core Business) as our primary foundation, while ensuring compatibility with other standards including vCard, Schema.org, Open Klant API, and commercial CRM systems.

Historical Context

The vCard standard (RFC 6350) represents one of the first industry-wide attempts to standardize person and organization information. Developed in the 1990s and still widely used today, vCard remains the dominant format for exchanging contact information between devices and applications, particularly in mobile phones, email clients, and contact management systems.

While vCard provides an excellent foundation for basic contact exchange, the European Core Vocabularies offer a more comprehensive approach specifically designed for government and business contexts, with stronger support for official identifiers, multilingual information, and regulatory compliance.

Standard Comparison

While using EU Core Vocabularies as our primary standard, we maintain compatibility with other major person/client/organization standards:

EU Standards

StrengthsLimitationsBest Used For
Official EU standardLess known outside EUGovernment systems
Strong identifier supportFewer implementationsCross-border exchange
Multilingual by designMore complex structureOfficial registrations
Public sector alignmentLimited consumer supportPublic procurement
Regulatory complianceRegulatory reporting

Core Person Properties

PropertyTypeDescription
identifierObjectOfficial identifiers with scheme information
fullNameStringComplete name of the person
givenNameStringFirst name
familyNameStringLast name
dateOfBirthDateBirth date
genderCodeGender code
citizenshipCodeCountry of citizenship
placeOfBirthObjectPlace of birth information
registeredAddressObjectOfficial address

Core Business Properties

PropertyTypeDescription
legalIdentifierObjectOfficial business identifier
legalNameStringOfficial registered name
alternativeNameStringTrading or alternative name
companyTypeCodeLegal form of the company
companyStatusCodeCurrent status (active, inactive)
companyActivityCodeBusiness activity classification
registeredAddressObjectOfficial registered address
foundingDateDateDate when company was established

Property Comparison

The following table compares properties across all relevant standards:

Our PropertyEU CorevCardSchema.orgUBLSalesforceDynamicsExactDescription
Person Properties
ididentifierUIDidentifierIDIdaccountidIDUnique identifier
namefullNameFNnameNameNamenameNameFull name
givenNamegivenNameN (part)givenNameFirstNameFirstNamefirstnameFirstNameFirst name
familyNamefamilyNameN (part)familyNameFamilyNameLastNamelastnameLastNameLast name
additionalName-N (part)additionalNameMiddleName-middlename-Middle name
honorificPrefix-N (part)honorificPrefixTitleSalutationsalutationTitleTitle prefix (Dr., Mr.)
honorificSuffix-N (part)honorificSuffixNameSuffixSuffixsuffix-Title suffix (Jr., PhD)
gendergenderGENDERgenderGenderCode-gendercodeGenderGender
birthDatedateOfBirthBDAYbirthDateBirthDateBirthdatebirthdateDateOfBirthBirth date
birthPlaceplaceOfBirth-birthPlaceBirthplaceName-birthdate_city-Place of birth
Organization Properties
ididentifierUIDidentifierIDIdaccountidIDUnique identifier
namelegalNameORGlegalNameRegistrationNameNamenameNameOfficial name
alternativeNamealternativeName-alternateNameTradingName--SearchCodeTrading name
companyActivitycompanyActivity--IndustryClassificationCodeIndustryindustrycodeSbiCodeIndustry classification
companyStatuscompanyStatus--CorporateRegistrationStatusStatusstatuscodeStatusCompany status
companyTypecompanyType--CompanyLegalFormCode-businesstypecodeLegalFormLegal form
foundingDatefoundingDate-foundingDateRegistrationDate--EstablishedDateFounding date
dissolutionDate--dissolutionDate----Dissolution date
Contact Properties
addressregisteredAddressADRaddressPostalAddressAddressaddress1_*AddressPhysical address
email-EMAILemailElectronicMailEmailemailaddress1EmailEmail address
telephone-TELtelephoneTelephonePhonetelephone1PhonePhone number
faxNumber--faxNumberTelefaxFaxfaxFaxFax number
website-URLurlWebsiteURIWebsitewebsiteurlWebsiteWebsite
Financial Properties
vatNumber--vatIDPartyTaxScheme--VATNumberVAT registration
taxReference--taxIDTaxReference--TaxReferenceNumberTax reference
bankAccount---FinancialAccount--BankAccountBank account
paymentTerms---PaymentTerms--PaymentTermsPayment terms
creditLimit-----creditlimitCreditLimitCredit limit
Relationship Properties
memberOf--memberOfPartyMember-parentaccountidParentParent organization
hasMember--memberParty---Child organizations
contactPerson-AGENTemployeeContactContactprimarycontactidContactPrimary contact
department-ORG (part)departmentDepartmentDepartment--Department
role-ROLEroleNameRoleCode---Role in organization
Metadata Properties
source-SOURCE--LeadSource--Information source
dateCreated--dateCreatedCreationDateCreatedDatecreatedonCreatedCreation timestamp
dateModified-REVdateModifiedLastModificationDateLastModifiedDatemodifiedonModifiedLast update timestamp
creator--creatorAuthorCreatedBycreatedbyCreatorRecord creator
lastModifier----LastModifiedBymodifiedbyModifierLast modifier

Our Hybrid Approach

Based on this analysis, our client register uses a hybrid approach that:

  1. Adopts the EU Core Vocabularies as the foundation

    • Ensures compliance with European standards
    • Supports official identifiers and multilingual information
    • Aligns with public sector requirements
  2. Incorporates Schema.org properties

    • Improves web discoverability
    • Uses widely recognized property names
    • Supports semantic web integration
  3. Maintains vCard compatibility

    • Enables contact exchange with mobile devices
    • Supports email integration
    • Leverages existing implementations
  4. Adds commercial CRM extensions

    • Supports business processes
    • Enables integration with existing systems
    • Provides practical functionality
  5. Aligns with Open Klant API

    • Ensures compatibility with Dutch government systems
    • Supports client interaction management
    • Enables integration with existing Dutch government services

This approach ensures that our client register is both standards-compliant and practically useful in real-world government and business environments.

Proposal

PropertyDescriptionExampleTypeOrigin
idUnique identifier for the client12345stringInternal system
@typeType of client recordOrganizationstringSchema.org
identifierExternal identifierBE0123456789stringEU Core
nameOfficial nameAcme CorporationstringEU Core
alternativeNameTrading or informal nameAcme CorpstringEU Core
givenNameFirst name for individualsJohnstringEU Core
familyNameLast name for individualsSmithstringEU Core
birthDateDate of birth for individuals1970-01-01dateEU Core
genderGender for individualsMalestringEU Core
addressPhysical location123 Main StobjectEU Core
contactPointContact informationphone, emailobjectEU Core
legalEntityLegal entity informationregistration detailsobjectEU Core
companyTypeType of companyLLCstringEU Core
companyStatusCurrent statusActivestringEU Core
companyActivityIndustry classificationManufacturingstringEU Core
dateCreatedRecord creation date2023-01-01T12:00:00ZdatetimeSystem
dateModifiedLast modification date2023-06-15T09:30:00ZdatetimeSystem
partyTypeType of partynatural_personstringInternal
isActiveWhether the client is activetruebooleanInternal
digitalAddressDigital contact informationemail, phoneobjectInternal
correspondenceAddressCorrespondence addresspostal addressobjectInternal

Task Object

For tasks, we'll primarily use the iCalendar standard (RFC 5545), specifically the VTODO component, as our foundational standard. This choice is driven by several key factors:

Historical Context

The iCalendar standard represents the most widely adopted format for calendar and task data exchange. Developed in the late 1990s and refined over time, it remains the foundation for most calendar systems, including those in major email clients, mobile devices, and dedicated calendar applications.

While newer API-based approaches exist, iCalendar's VTODO component provides a comprehensive model for task management that balances simplicity with powerful features like recurrence, reminders, and multi-participant support.

Standards Comparison

While using iCalendar as our primary standard, we maintain compatibility with other major task standards:

StrengthsLimitationsBest Used For
Widespread adoptionComplex recurrence rulesCalendar integration
Rich property setLimited custom fieldsPersonal tasks
Stable standardText-only descriptionsRecurring tasks
Cross-platformLimited relationshipsDeadline tracking
Mature implementationsBasic workflow supportBasic scheduling

iCalendar VTODO Properties

PropertyTypeDescription
UIDStringUnique identifier
SUMMARYStringTask summary/title
DESCRIPTIONStringTask description
DTSTARTDateTimeStart date/time
DUEDateTimeDue date/time
COMPLETEDDateTimeCompletion date/time
STATUSStringTask status (NEEDS-ACTION, IN-PROCESS, COMPLETED, CANCELLED)
PRIORITYIntegerPriority (0-9, 0=undefined, 1=highest, 9=lowest)
PERCENT-COMPLETEIntegerPercent complete (0-100)
CATEGORIESStringCategories/tags
RRULEStringRecurrence rule
ORGANIZERStringTask organizer
ATTENDEEStringTask participants
ATTACHURIFile attachments
RELATED-TOStringRelated tasks
CREATEDDateTimeCreation timestamp
LAST-MODIFIEDDateTimeLast modification timestamp

Property Comparison

The following table compares task properties across relevant standards:

Our PropertyiCalendarSchema.orgMicrosoft To DoGoogle TasksTrelloDescription
Core Properties
idUIDidentifieridididUnique identifier
titleSUMMARYnametitletitlenameTask title
descriptionDESCRIPTIONdescriptionbody.contentnotesdescTask description
startTimeDTSTARTstartTimestartDateTime--Start date/time
dueTimeDUEendTimedueDateTimeduedueDue date/time
completedTimeCOMPLETEDcompletedTimecompletedDateTimecompleted-Completion date/time
Status Properties
statusSTATUSactionStatusstatusstatus-Task status
priorityPRIORITY-importance-posPriority level
percentCompletePERCENT-COMPLETEpercentComplete---Percent complete
Categorization
categoryCATEGORIEScategorycategories-idLabelsCategories/tags
People
assigneeORGANIZERagentassignedTo-idMembersPerson assigned to task
participantsATTENDEEparticipant--idMembersOther participants
Relationships
parentRELATED-TOisPartOf-parent-Parent task
subtasks-hasPart---Child tasks
relatedToRELATED-TOabout---Related entities
Metadata
createdAtCREATEDdateCreatedcreatedDateTime--Creation timestamp
updatedAtLAST-MODIFIEDdateModifiedlastModifiedDateTimeupdateddateLastActivityLast update timestamp
recurrenceRRULE-recurrence--Recurrence pattern
attachmentsATTACH---attachmentsFile attachments

Our Hybrid Approach

Based on this analysis, our task register uses a hybrid approach that:

  1. Adopts iCalendar VTODO as the foundation

    • Ensures compatibility with calendar systems
    • Provides robust recurrence support
    • Leverages a mature, widely-implemented standard
  2. Incorporates Schema.org PlanAction properties

    • Improves web discoverability
    • Adds semantic relationships
    • Supports knowledge graph integration
  3. Adds Microsoft and Google compatibility

    • Enables integration with popular productivity suites
    • Supports enterprise workflows
    • Provides mobile compatibility
  4. Includes Trello-inspired visual elements

    • Supports kanban-style organization
    • Enables visual task management
    • Improves team collaboration

This approach ensures that our task register works seamlessly with existing calendar systems while providing the rich features needed for business process management.

Proposal

PropertyDescriptionExampleTypeOrigin
idUnique identifier"task-12345"stringiCalendar UID
titleTask title"Complete client proposal"stringiCalendar SUMMARY
descriptionTask description"Draft the proposal document including..."stringiCalendar DESCRIPTION
startTimeWhen task begins"2023-06-15T09:00:00Z"string (ISO 8601)iCalendar DTSTART
dueTimeWhen task is due"2023-06-20T17:00:00Z"string (ISO 8601)iCalendar DUE
completedTimeWhen task was completed"2023-06-19T16:30:00Z"string (ISO 8601)iCalendar COMPLETED
statusCurrent status"in-progress"string (enum)iCalendar STATUS
priorityPriority level"high"string (enum)iCalendar PRIORITY
percentCompleteCompletion percentage75integer (0-100)iCalendar PERCENT-COMPLETE
categoryCategories/tags["proposal", "sales"]array[string]iCalendar CATEGORIES
assigneePerson assigned to task{"id": "user-123", "name": "Jane Doe"}objectiCalendar ORGANIZER
participantsOther participants[{"id": "user-456", "name": "John Smith", "role": "reviewer"}]array[object]iCalendar ATTENDEE
parentParent task"task-789"stringiCalendar RELATED-TO
subtasksChild tasks["task-101", "task-102"]array[string]Schema.org hasPart
relatedToRelated entities[{"id": "client-456", "type": "Client"}]array[object]iCalendar RELATED-TO
recurrenceRecurrence pattern"FREQ=WEEKLY;BYDAY=MO"string (iCal RRULE)iCalendar RRULE
attachmentsFile attachments[{"name": "draft.docx", "url": "https://..."}]array[object]iCalendar ATTACH
createdAtCreation timestamp"2023-06-10T14:30:00Z"string (ISO 8601)iCalendar CREATED
updatedAtLast update timestamp"2023-06-15T09:15:00Z"string (ISO 8601)iCalendar LAST-MODIFIED
createdByCreator information{"id": "user-789", "name": "Alice Brown"}objectSchema.org creator
updatedByLast modifier information{"id": "user-123", "name": "Jane Doe"}objectSchema.org editor
Thread Identifier

A thread is a way to group related messages together in a conversation. In messaging systems, it acts like a conversation ID that links all messages in a back-and-forth exchange. For example, when someone replies to an email or chat message, all those messages share the same thread ID (usually the UUID of the first message in the conversation) to keep them connected.

Message Object

For messages associated with clients, we'll use email standards (RFC 5322) as our primary foundation, while incorporating elements from JMAP and Schema.org to create a comprehensive message model.

Historical Context

Email standards represent one of the oldest and most widely implemented digital communication formats. The Internet Message Format (RFC 5322, previously RFC 822) has been the foundation of email communication since the early days of the internet. This format has proven remarkably resilient, continuing to serve as the backbone of electronic communication despite the emergence of numerous messaging platforms.

While email standards provide an excellent foundation for message structure, newer standards like JMAP (JSON Meta Application Protocol) offer more modern API approaches for message handling. By combining these standards with Schema.org's semantic web capabilities, we create a message model that works across traditional email, modern messaging platforms, and web applications.

Standards Comparison

StrengthsLimitationsBest Used For
SEO benefitsLimited messaging focusWeb content
Semantic relationshipsBasic properties onlyPublic messages
Web integrationLoose validationSearch visibility
Flexible propertiesWeb-centric designKnowledge graphs
Search engine supportSemantic relationships

Schema.org Message Properties

PropertyTypeDescription
identifierText/URLUnique identifier
nameTextMessage name/subject
descriptionTextMessage description
aboutThingWhat the message is about
textTextMessage content
dateCreatedDateTimeCreation date
dateReceivedDateTimeDate received
dateSentDateTimeDate sent
dateReadDateTimeDate read
senderPerson/OrganizationMessage sender
recipientPerson/OrganizationMessage recipient
messageAttachmentCreativeWorkAttached content
inLanguageLanguageMessage language
potentialActionActionPotential actions
urlURLURL for the message

Property Comparison

The following table compares message properties across relevant standards:

Our PropertyRFC 5322JMAPSchema.orgUBLDescription
Core Properties
idMessage-IDididentifierIDUnique identifier
aboutSubjectsubjectaboutSubjectMessage subject
textBodybodyValuestextTextContentMessage content
fromFromfromsenderSenderPartySender information
recipientTo/Cc/Bccto/cc/bccrecipientReceiverPartyRecipient information
dateSentDatesentAtdateSentIssueDateWhen message was sent
dateReceivedReceivedreceivedAtdateReceivedReceivedDateWhen message was received
dateRead--dateRead-When message was read
attachmentAttachmentattachmentsmessageAttachmentAttachmentFile attachments
Threading Properties
threadReferences/Thread-IDthreadId--Thread identifier
inReplyToIn-Reply-ToinReplyTo--Message being replied to
referencesReferencesreferences--Related messages
Metadata Properties
channel---ChannelCodeCommunication channel
direction----Message direction
status-keywords-StatusCodeDelivery status
languageContent-Language-inLanguage-Message language
priorityPriority---Message priority
System Properties
createdAt--dateCreated-Creation timestamp
updatedAt--dateModified-Last update timestamp
createdBy--creator-Record creator
updatedBy--editor-Last modifier

Our Hybrid Approach

Based on this analysis, our message register uses a hybrid approach that:

  1. Adopts RFC 5322 as the foundation

    • Ensures compatibility with email systems
    • Leverages a mature, widely-implemented standard
    • Provides a comprehensive message structure
  2. Incorporates JMAP concepts

    • Adds modern API capabilities
    • Improves threading and synchronization
    • Supports efficient client operations
  3. Includes Schema.org properties

    • Enhances semantic relationships
    • Improves web discoverability
    • Supports knowledge graph integration
  4. Adds UBL elements for business context

    • Supports formal business communications
    • Enables process integration
    • Provides structured metadata

This approach ensures that our message register works with existing email systems while providing the rich features needed for business communication management.

Proposal

PropertyDescriptionExampleTypeOrigin
idUnique identifier"msg-12345"stringRFC 5322 Message-ID
subjectMessage subject"Project Update - June 2023"stringRFC 5322 Subject
bodyMessage content"Dear John, I'm writing to update you on..."stringRFC 5322 Body
fromSender information{"name": "Jane Doe", "email": "jane.doe@example.com"}objectRFC 5322 From
toRecipient information[{"name": "John Smith", "email": "john.smith@example.com"}]array[object]RFC 5322 To
ccCarbon copy recipients[{"name": "Alice Brown", "email": "alice@example.com"}]array[object]RFC 5322 Cc
sentAtWhen message was sent"2023-06-10T14:30:00Z"string (ISO 8601)RFC 5322 Date
receivedAtWhen message was received"2023-06-10T14:31:05Z"string (ISO 8601)RFC 5322 Received
readAtWhen message was read"2023-06-10T15:45:22Z"string (ISO 8601)JMAP ReadAt
attachmentsFile attachments[{"name": "proposal.pdf", "url": "https://..."}]array[object]MIME Attachments
threadThread identifier"thread-123456"stringRFC 5322 References
inReplyToMessage being replied to"msg-12344"stringRFC 5322 In-Reply-To
referencesRelated messages["msg-12343", "msg-12344"]array[string]RFC 5322 References
channelCommunication channel"email", "sms", "chat", "phone"string (enum)UBL Channel Code
directionMessage direction"inbound", "outbound"string (enum)Schema.org MessageDirection
statusDelivery status"sent", "delivered", "read", "failed"string (enum)JMAP DeliveryStatus
Thread Identifier

A thread is a way to group related messages together in a conversation. In messaging systems, it acts like a conversation ID that links all messages in a back-and-forth exchange. For example, when someone replies to an email or chat message, all those messages share the same thread ID (usually the UUID of the first message in the conversation) to keep them connected.

Note Object

For client notes, we'll create a schema based on Schema.org's Comment type as our primary foundation, enhanced with properties from UBL's Note element and commercial note-taking platforms to ensure broad compatibility.

Historical Context

Note-taking and comment systems have evolved significantly from simple text annotations to rich, collaborative content platforms. While early digital note systems were primarily text-based, modern note-taking applications support rich formatting, multimedia content, and collaborative features.

The Schema.org Comment type provides a web-standard approach to representing notes and comments, with strong support for semantic relationships between the note and its subject. By combining this with UBL's more formal Note element structure and features from commercial platforms, we create a note system that works across different contexts from formal business documentation to collaborative team environments.

Standards Comparison

StrengthsLimitationsBest Used For
SEO benefitsLoose structureWeb content
Flexible formatWeb focusedPublic notes
Web standardsBasic validationBlog comments
Rich propertiesLimited toolingReviews
Growing supportEvolving specSocial content

Schema.org Comment Properties

PropertyTypeDescription
identifierText/URLUnique identifier
nameTextTitle or headline
textTextThe actual comment content
aboutThingThe subject of the comment
authorPerson/OrganizationWho created the comment
dateCreatedDateTimeWhen the comment was created
dateModifiedDateTimeWhen the comment was last modified
upvoteCountIntegerNumber of upvotes
downvoteCountIntegerNumber of downvotes
parentItemCommentParent comment in a thread
urlURLURL of the comment
versionNumber/TextVersion of the comment
contentLocationPlaceLocation the comment is about
contentRatingRatingRating given in the comment
keywordsTextKeywords or tags
inLanguageLanguage/TextLanguage of the content
encodingFormatTextFormat of the content
publisherPerson/OrganizationWho published the comment
isPartOfCreativeWorkLarger work this is part of
positionInteger/TextPosition in a series
accessModeTextSystem of access
accessModeSufficientTextSufficient access mode
accessibilityAPITextAccessibility API used
accessibilityControlTextControl methods
accessibilityFeatureTextAccessibility features
accessibilityHazardTextPotential hazards

Property Comparison

The following table compares note properties across relevant standards and platforms:

Our PropertySchema.orgUBLMicrosoft 365Google DocsNextcloudDescription
Core Properties
ididentifierIDidididUnique identifier
titlenameSubjecttitletitletitleNote title
contenttextNotecontenttextContentcontentNote content
aboutabout----What the note is about
formatencodingFormatFormatcontentType-contentTypeContent format
languageinLanguageLanguageIDlanguage--Content language
Metadata Properties
createdByauthorIssuerPartycreatedBy-userIdAuthor information
createdAtdateCreatedIssueDatecreatedDateTime--Creation timestamp
updatedAtdateModified-lastModifiedDateTime-modifiedLast update timestamp
versionversionVersionID--etagVersion number
parentisPartOf-parentNotebook-categoryParent container
Organization Properties
tagskeywords----Categorization tags
visibility----shareTypesVisibility settings
pinned----favoriteWhether note is pinned
Relationships
aboutabout----Associated client/entity
references-----Referenced content

Our Hybrid Approach

Based on this analysis, our note register uses a hybrid approach that:

  1. Adopts Schema.org Comment as the foundation

    • Ensures web compatibility
    • Provides simple, clear structure
    • Supports semantic relationships
  2. Adds rich content capabilities

    • Supports formatted text
    • Enables multimedia content
    • Provides flexible layout options
  3. Includes organizational features

    • Supports categorization and tagging
    • Enables pinning important notes
    • Provides visibility controls
  4. Incorporates CRM-inspired metadata

    • Links notes to business processes
    • Tracks authorship and history
    • Supports relationship modeling

This approach ensures that our note register provides a flexible yet structured way to capture important client information that doesn't fit into other structured data models.

Proposal

PropertyDescriptionExampleTypeOrigin
idUnique identifier for the note"note-123456"stringSchema.org identifier
titleNote title"Meeting Summary - June 10"stringSchema.org name
contentNote content"Met with client to discuss new requirements..."stringSchema.org text
aboutReference to the object this note is about550e8400-e29b-41d4-a716-446655440000uuid/uriSchema.org about
formatContent format"text/html"stringSchema.org encodingFormat
languageContent language"en-US"stringSchema.org inLanguage
createdByAuthor information{"id": "user-123", "name": "Jane Doe"}objectSchema.org author
createdAtCreation timestamp"2023-06-10T16:30:00Z"string (ISO 8601)Schema.org dateCreated
updatedAtLast update timestamp"2023-06-11T09:15:00Z"string (ISO 8601)Schema.org dateModified
versionVersion number"1.2"stringSchema.org version
parentParent container reference"folder-789"stringSchema.org isPartOf
tagsCategorization tags["meeting", "requirements", "important"]array[string]Schema.org keywords
visibilityWho can see the note"private", "team", "public"string (enum)Microsoft/Google extension
pinnedWhether note is pinnedtrue/falsebooleanGoogle Keep isPinned
sharedSharing status{"type": "team", "users": ["user-456"]}objectNextcloud shareTypes
permissionsAccess rights["read", "write", "share"]array[string]Nextcloud permissions
About Property

The 'about' property is based on Schema.org's about property, which indicates the subject matter of the content. In our implementation, we use it to create a direct link between the note and the entity it refers to (like a client, task, or message). The value should be a UUID or URI that uniquely identifies the referenced object. This creates a semantic relationship that can be used for filtering, searching, and organizing notes by their subject matter.

For example, a note with about: "550e8400-e29b-41d4-a716-446655440000" indicates this note is about that specific client record.

This schema ensures notes can be:

  • Synchronized with Office 365 OneNote/SharePoint
  • Integrated with Google Keep/Docs
  • Shared via Nextcloud Notes
  • Embedded in UBL business documents
  • Indexed for semantic search

Order Object

For orders associated with clients, we'll use the Universal Business Language (UBL) Order schema as our primary foundation, while incorporating elements from other standards to create a comprehensive order model suitable for government and business contexts.

Historical Context

The concept of standardized order documents has evolved significantly from paper-based purchase orders to electronic data interchange (EDI) formats and modern XML/JSON-based standards. The Universal Business Language (UBL) Order schema represents one of the most comprehensive and widely adopted standards for electronic order documents in Europe.

Developed by OASIS and adopted as an ISO standard (ISO/IEC 19845), UBL provides a rich set of elements for representing orders in both commercial and governmental contexts. The European Committee for Standardization (CEN) has further endorsed UBL as part of the European e-procurement standards.

Standards Comparison

StrengthsLimitationsBest Used For
ISO/EU standardComplex structureGovernment procurement
ComprehensiveSteep learning curveB2G transactions
Legally recognizedVerbose XML formatFormal order processes
Strong validationImplementation costRegulatory compliance
Cross-border supportLimited flexibilityPublic sector orders

UBL Order Properties

PropertyTypeDescription
IDIdentifierOrder identifier
SalesOrderIDIdentifierSales order identifier
UUIDIdentifierUniversally unique identifier
IssueDateDateDate when the order was issued
IssueTimeTimeTime when the order was issued
OrderTypeCodeCodeOrder type code
NoteTextNote text
RequestedInvoiceCurrencyCodeCodeRequested invoice currency
DocumentCurrencyCodeCodeDocument currency
PricingCurrencyCodeCodePricing currency
TaxCurrencyCodeCodeTax currency
CustomerReferenceTextCustomer's reference
AccountingCostCodeCodeAccounting cost code
AccountingCostTextAccounting cost
LineCountNumericNumericNumber of lines in the order
ValidityPeriodPeriodValidity period
QuotationDocumentReferenceReferenceReference to quotation
OrderDocumentReferenceReferenceReference to another order
OriginatorDocumentReferenceReferenceReference to originator document
BuyerCustomerPartyPartyBuyer information
SellerSupplierPartyPartySeller information
OriginatorCustomerPartyPartyOriginator information
FreightForwarderPartyPartyFreight forwarder information
AccountingCustomerPartyPartyAccounting customer information
DeliveryDeliveryDelivery information
DeliveryTermsTermsDelivery terms
PaymentMeansPaymentMeansPayment means
PaymentTermsTermsPayment terms
AllowanceChargeAllowanceChargeAllowance or charge
TaxTotalTaxTotalTax total
AnticipatedMonetaryTotalMonetaryTotalAnticipated monetary total
OrderLineOrderLineOrder line

Property Comparison

The following table compares order properties across relevant standards:

Our PropertyUBLPEPPOLSchema.orgUN/EDIFACTDescription
Core Properties
idIDIDidentifierBGMOrder identifier
orderNumberIDIDorderNumberBGMOrder number
issueDateIssueDateIssueDateorderDateDTMDate order was issued
orderTypeOrderTypeCode--BGMType of order
status--orderStatusBGMOrder status
currencyDocumentCurrencyCodeDocumentCurrencyCodepriceCurrencyCUXCurrency code
noteNoteNote-FTXNote text
Party Properties
buyerBuyerCustomerPartyBuyerCustomerPartycustomerNADBuyer information
sellerSellerSupplierPartySellerSupplierPartysellerNADSeller information
originatorOriginatorCustomerParty--NADOriginator information
Delivery Properties
deliveryTermsDeliveryTermsDeliveryTerms-TODDelivery terms
deliveryLocationDeliveryDelivery-LOCDelivery location
deliveryDateDelivery/RequestedDeliveryPeriodDelivery/RequestedDeliveryPeriod-DTMRequested delivery date
Payment Properties
paymentTermsPaymentTermsPaymentTermspaymentDueDatePATPayment terms
paymentMethodPaymentMeansPaymentMeanspaymentMethodPAIPayment method
Amount Properties
totalAmountAnticipatedMonetaryTotalAnticipatedMonetaryTotaltotalPriceMOATotal amount
taxTotalTaxTotalTaxTotaltaxTAXTax total
Line Items
orderLinesOrderLineOrderLineorderedItemLINOrder line items
Metadata Properties
referenceCustomerReference--RFFCustomer's reference
accountingCodeAccountingCostCodeAccountingCost--Accounting code
createdBy----User who created the order
createdAtIssueDate/IssueTimeIssueDateorderDateDTMCreation timestamp
updatedAt----Last update timestamp

Our Hybrid Approach

Based on this analysis, our order register uses a hybrid approach that:

  1. Adopts UBL Order as the foundation

    • Ensures compliance with European procurement standards
    • Provides a comprehensive order structure
    • Supports legal and regulatory requirements
  2. Simplifies the structure for government services

    • Reduces complexity for citizen-facing services
    • Focuses on essential order properties
    • Improves usability for non-commercial contexts
  3. Incorporates Schema.org properties

    • Enhances web discoverability
    • Supports online service catalogs
    • Improves citizen service portals
  4. Maintains PEPPOL compatibility

    • Enables cross-border procurement
    • Supports European e-procurement network
    • Ensures interoperability with existing systems

This approach ensures that our order register works for both traditional procurement scenarios and modern government service delivery contexts.

Proposal

PropertyDescriptionExampleTypeOrigin
idUnique identifier"order-12345"stringUBL ID
orderNumberHuman-readable order number"ORD-2023-12345"stringUBL ID
issueDateDate order was issued"2023-06-15"string (ISO 8601)UBL IssueDate
orderTypeType of order"standard", "renewal", "amendment"string (enum)UBL OrderTypeCode
statusOrder status"pending", "approved", "completed", "cancelled"string (enum)Schema.org orderStatus
currencyCurrency code"EUR"stringUBL DocumentCurrencyCode
noteAdditional notes"Please deliver to reception desk"stringUBL Note
buyerBuyer information{"id": "client-789", "name": "John Smith"}objectUBL BuyerCustomerParty
sellerSeller information{"id": "org-456", "name": "City Services Department"}objectUBL SellerSupplierParty
deliveryTermsDelivery terms"Free delivery"stringUBL DeliveryTerms
deliveryLocationDelivery location{"address": "123 Main St", "city": "Amsterdam"}objectUBL Delivery
deliveryDateRequested delivery date"2023-07-01"string (ISO 8601)UBL RequestedDeliveryPeriod
paymentTermsPayment terms"30 days"stringUBL PaymentTerms
paymentMethodPayment method"credit_card", "bank_transfer", "direct_debit"string (enum)UBL PaymentMeans
totalAmountTotal order amount{"value": 125.50, "currency": "EUR"}objectUBL AnticipatedMonetaryTotal
taxTotalTax amount{"value": 25.10, "currency": "EUR"}objectUBL TaxTotal
orderLinesOrder line items[{"id": "line-1", "product": "product-123", "quantity": 2, "unitPrice": 50.00}]array[object]UBL OrderLine
referenceCustomer reference"REF-2023-001"stringUBL CustomerReference
accountingCodeAccounting code"DEPT-123-456"stringUBL AccountingCostCode
createdByUser who created the order{"id": "user-123", "name": "Jane Doe"}objectSystem extension
createdAtCreation timestamp"2023-06-15T10:30:00Z"string (ISO 8601)UBL IssueDate/IssueTime
updatedAtLast update timestamp"2023-06-16T14:15:00Z"string (ISO 8601)System extension

Product Object

For products and services offered to clients, we'll use the Universal Business Language (UBL) Item schema as our primary foundation, while incorporating elements from other standards to create a comprehensive product model suitable for government and business contexts.

Historical Context

Product and service catalogs have evolved from paper catalogs to electronic formats, with various standards emerging to describe products and services in different contexts. The Universal Business Language (UBL) Item schema provides a comprehensive approach to representing products and services in formal business and government contexts.

In the government context, products often represent permits, licenses, documents, and other tangible items that citizens and businesses can request. Having a standardized way to represent these products ensures consistency across different government services and improves interoperability between systems.

Standards Comparison

StrengthsLimitationsBest Used For
ISO/EU standardComplex structureGovernment catalogs
ComprehensiveSteep learning curveFormal procurement
Legally recognizedVerbose XML formatRegulated products
Strong validationImplementation costCross-border trade
Multilingual supportLimited flexibilityPublic sector catalogs

UBL Item Properties

PropertyTypeDescription
DescriptionTextItem description
PackQuantityQuantityPackage quantity
PackSizeNumericNumericPack size
CatalogueIndicatorIndicatorCatalogue indicator
NameNameItem name
HazardousRiskIndicatorIndicatorHazardous risk indicator
AdditionalInformationTextAdditional information
KeywordTextKeyword
BrandNameNameBrand name
ModelNameNameModel name
ManufacturerPartyPartyManufacturer information
InformationContentProviderPartyPartyInformation provider
OriginCountryCountryCountry of origin
CommodityClassificationClassificationCommodity classification
TransactionConditionsConditionsTransaction conditions
HazardousItemItemHazardous item information
ClassifiedTaxCategoryTaxCategoryTax category
AdditionalItemPropertyItemPropertyAdditional item property
ManufacturerItemIdentificationIdentificationManufacturer's item ID
CatalogueItemIdentificationIdentificationCatalogue item ID
StandardItemIdentificationIdentificationStandard item ID
ItemSpecificationDocumentReferenceReferenceItem specification document
OriginAddressAddressOrigin address
ItemInstanceItemInstanceItem instance

Property Comparison

The following table compares product properties across relevant standards:

Our PropertyUBLSchema.orgCPVUNSPSCDescription
Core Properties
idIDidentifier--Product identifier
nameNamename--Product name
descriptionDescriptiondescription--Product description
type-'@type'--Product type
categoryCommodityClassificationcategoryCPV codeUNSPSC codeProduct category
Classification Properties
classificationSchemeCommodityClassification/@listName-"CPV""UNSPSC"Classification scheme
classificationCodeCommodityClassification/ItemClassificationCode-Code valueCode valueClassification code
classificationNameCommodityClassification/ItemClassificationCode/@name-Code descriptionCode descriptionClassification name
Identification Properties
productIdStandardItemIdentificationproductID--Product ID
skuCatalogueItemIdentificationsku--Stock keeping unit
Descriptive Properties
brandBrandNamebrand--Brand name
modelModelNamemodel--Model name
manufacturerManufacturerPartymanufacturer--Manufacturer
originOriginCountry---Country of origin
keywordsKeyword---Keywords
Physical Properties
dimensionsAdditionalItemPropertywidth/height/depth--Dimensions
weightAdditionalItemPropertyweight--Weight
colorAdditionalItemPropertycolor--Color
materialAdditionalItemPropertymaterial--Material
Commercial Properties
price-offers.price--Price
currency-offers.priceCurrency--Currency
availability-offers.availability--Availability
validFrom-offers.validFrom--Valid from date
validThrough-offers.validThrough--Valid through date
Metadata Properties
createdAt----Creation timestamp
updatedAt----Last update timestamp
createdBy----Creator
status----Status

Our Hybrid Approach

Based on this analysis, our product register uses a hybrid approach that:

  1. Adopts UBL Item as the foundation

    • Ensures compliance with European procurement standards
    • Provides a comprehensive product structure
    • Supports legal and regulatory requirements
  2. Incorporates Schema.org properties

    • Enhances web discoverability
    • Supports online service catalogs
    • Improves citizen service portals
  3. Uses standard classification systems

    • Integrates CPV for European procurement
    • Supports UNSPSC for global compatibility
    • Enables statistical analysis and reporting
  4. Adds government-specific extensions

    • Supports permit and license products
    • Includes administrative requirements
    • Addresses citizen service needs

This approach ensures that our product register works for both traditional procurement scenarios and modern government service delivery contexts.

Proposal

PropertyDescriptionExampleTypeOrigin
idUnique identifier"product-12345"stringUBL ID
nameProduct name"Building Permit - Residential"stringUBL Name
descriptionProduct description"Permit for residential building construction"stringUBL Description
typeProduct type"permit", "license", "document", "service"string (enum)Schema.org '@type'
categoryProduct category"Construction permits"stringUBL CommodityClassification
classificationSchemeClassification scheme"CPV"stringUBL CommodityClassification/@listName
classificationCodeClassification code"45214400-4"stringUBL ItemClassificationCode
classificationNameClassification name"Building construction work"stringUBL ItemClassificationCode/@name
productIdProduct ID"BLD-RES-001"stringUBL StandardItemIdentification
keywordsKeywords["permit", "construction", "residential"]array[string]UBL Keyword
departmentResponsible department"Building and Housing Department"stringUBL InformationContentProviderParty
requirementsRequirements["ID proof", "Property documents", "Building plans"]array[string]UBL AdditionalItemProperty
processingTimeProcessing time"10 business days"string