Use of Standards

Use of Standards

This page documents the standards integrated into the Campus-Neighborhood Mentorship Network platform, their relevance to our domain, and how they are used.

---

1. W3C Activity Streams 2.0

Standard: Activity Streams 2.0 (W3C Recommendation, 23 May 2017)

Why it is relevant to our project: Our platform is built around activities — mentors accepting requests, mentees submitting tasks, users publishing blog posts, meetings being scheduled. Activity Streams provides a standardized data model for representing these actions as structured data following the pattern: an actor performs an activity on an object.

How it applies to our project:

Platform event	Activity Streams mapping
Mentee sends a mentorship request	actor: Mentee, type: Offer, object: MentorshipRequest, target: Mentor
Mentor accepts a request	actor: Mentor, type: Accept, object: MentorshipRequest
Mentor rejects a request	actor: Mentor, type: Reject, object: MentorshipRequest
Mentor assigns a task	actor: Mentor, type: Create, object: Task, target: Mentee
Mentee submits an assignment	actor: Mentee, type: Create, object: Submission, inReplyTo: Task
Mentor publishes a blog post	actor: Mentor, type: Create, object: Article
User likes a blog post	actor: User, type: Like, object: Article
User comments on a blog post	actor: User, type: Create, object: Note, inReplyTo: Article
Meeting is scheduled	actor: Mentor, type: Create, object: Event
Mentee rates a mentor	actor: Mentee, type: Create, object: Rating

Integration approach:

• The notification system will produce Activity Streams-compliant JSON-LD payloads using the https://www.w3.org/ns/activitystreams context.
• Each notification stored in the Notification entity maps to an Activity with actor, type, object, and target fields.
• The existing NotificationType enum (REQUEST_ACCEPTED, REQUEST_REJECTED, MATCH_FOUND, etc.) maps directly to Activity Streams activity types (Accept, Reject, Announce, etc.).
• Blog post interactions (like, comment) follow the Activity Streams social patterns.

Status: Planned. Will be applied to the notification system and blog interactions.

---

2. JSON-LD 1.1

Standard: JSON-LD 1.1 (W3C Recommendation, 16 July 2020)

Why it is relevant to our project: JSON-LD is the serialization format used by both Activity Streams and Schema.org. It allows our existing JSON API responses to become linked data by simply adding a @context field — no changes to the existing response structure needed. This means our API can serve both plain JSON to web/mobile clients and semantically meaningful linked data to any system that understands the vocabulary.

How it applies to our project:

A mentor profile response today:

{
  "firstName": "Esra",
  "expertise": "Data Science",
  "affiliation": "Bogazici University",
  "bio": "10 years in ML research"
}

With JSON-LD, the same response becomes linked data:

{
  "@context": "https://schema.org/",
  "@type": "Person",
  "givenName": "Esra",
  "knowsAbout": "Data Science",
  "affiliation": {
    "@type": "Organization",
    "name": "Bogazici University"
  },
  "description": "10 years in ML research"
}

A notification becomes an Activity Streams activity:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Accept",
  "actor": { "type": "Person", "name": "Esra" },
  "object": { "type": "Offer", "summary": "Mentorship request" },
  "published": "2026-04-18T12:00:00Z"
}

Integration approach:

• Profile endpoints will support content negotiation: Accept: application/ld+json returns JSON-LD, Accept: application/json returns plain JSON (backward compatible).
• JSON-LD @context references Schema.org for profiles/events and Activity Streams for notifications/activities.
• No separate serialization layer needed — JSON-LD is valid JSON, so existing clients continue to work.

Status: Planned. Tracked in issue #251.

---

3. Schema.org Vocabulary

Standard: Schema.org — collaborative vocabulary maintained by Google, Microsoft, Yahoo, and Yandex

Why it is relevant to our project: Schema.org provides the vocabulary (the "words") that JSON-LD uses to describe our data. It defines types like Person, Event, Schedule, Rating, and Article — all of which map directly to our platform's core concepts: mentor profiles, availability, meetings, ratings, and blog posts.

How it applies to our project:

Our concept	Schema.org type	Properties we use
Mentor/Mentee profiles	Person	givenName, familyName, jobTitle, knowsAbout (expertise, interests, skills), alumniOf (university), affiliation, description (bio)
Mentor availability	Schedule	byDay, startTime, endTime, repeatFrequency (weekly), scheduleTimezone
Mentorship meetings	Event	startDate, endDate, location, organizer (mentor), attendee (mentee), eventStatus
Mentor ratings	Rating	ratingValue (1–5), bestRating, worstRating, author (mentee)
Blog posts	Article	headline, author, datePublished, articleBody, commentCount

Integration approach:

• Schema.org types are used as the @type values in JSON-LD profile responses.
• Our entity fields map to Schema.org properties: expertise → knowsAbout, field → jobTitle, affiliation → affiliation, bio → description.
• Availability slots map to Schema.org Schedule with byDay (day of week) and startTime/endTime.
• For skills, interests, and expertise values, we use standardized terms from ESCO (see section 4). For field/major values, we use ISCED-F (see section 5).

Status: Planned. Tracked in issue #251.

---

4. ESCO for Skills, Competences, and Occupations

Standard: ESCO — European Skills, Competences, Qualifications and Occupations (European Commission)

Why it is relevant to our project: Our recommendation system matches mentors and mentees based on skills, interests, and expertise. Currently these are stored as free-text strings, which leads to duplicates and mismatches (e.g., "Machine Learning" vs "ML" vs "machine learning"). ESCO provides a standardized, multilingual taxonomy of 3,039 occupations and 13,890 skills that eliminates this ambiguity.

How it applies to our project:

Our field	ESCO classification	Example
Mentor expertise	ESCO Skills & Competences	"develop machine learning models" (skill URI: http://data.europa.eu/esco/skill/...)
Mentee skills	ESCO Skills & Competences	"Python programming", "data analysis", "statistical modelling"
Mentor occupation/field	ESCO Occupations (based on ISCO-08)	"software developer", "data scientist", "university lecturer"
Professional interests	ESCO Skills (transversal)	"artificial intelligence", "web development", "entrepreneurship"
Hobbies & personal interests	Wikidata entities (see section 5)	"photography" (Q11633), "chess" (Q718)

Why ESCO over free text:

• A mentee typing "ML" and a mentor listing "Machine Learning" are recognized as the same concept through ESCO's multilingual labels and synonyms.
• ESCO's hierarchy enables the recommendation system to understand that "Deep Learning" is a narrower skill within "Machine Learning", improving recommendation quality.
• ESCO is published as linked data, compatible with Schema.org — skill URIs can be used as values for Schema.org knowsAbout and skills properties in our JSON-LD responses.

Integration approach:

• Use the ESCO API for skill/occupation autocomplete in profile forms (typeahead search).
• Store ESCO URIs alongside display labels for each skill, interest, and expertise entry.
• Users can also add free-text entries for tool/framework-level detail that ESCO does not cover (e.g., "PyTorch" under ESCO's "Machine Learning", or "React" under "Computer programming"). The recommendation algorithm matches on standardized ESCO terms while free-text entries provide additional granularity.
• Hobbies and personal interests are standardized through Wikidata (see section 5), not ESCO.
• The recommendation algorithm uses ESCO's hierarchy and relationships to find matches across synonyms and related concepts.
• ESCO terms populate Schema.org knowsAbout and skills fields in JSON-LD profile responses.

Status: Planned. Will be integrated alongside the recommendation system (#137).

---

5. Wikidata for Hobbies and Personal Interests

Standard: Wikidata — free, collaborative knowledge base maintained by the Wikimedia Foundation

Why it is relevant to our project: Our recommendation system can suggest mentors based on shared personal interests and hobbies (req 1.1.2.4 — diverse, out-of-the-box recommendations). ESCO covers professional skills but not hobbies like photography, chess, or hiking. Wikidata provides stable, multilingual identifiers for virtually every hobby, sport, art form, and personal interest — with hierarchies and linked data compatibility.

How it applies to our project:

Interest	Wikidata entity	Hierarchy
Photography	Q11633	photography → visual arts → arts
Chess	Q718	chess → board game → game
Hiking	Q182034	hiking → outdoor recreation → recreation
Guitar	Q6607	guitar → string instrument → musical instrument
Cooking	Q36539	cooking → food preparation
Entrepreneurship	Q170584	entrepreneurship → business

Integration approach:

• Profile forms offer Wikidata-powered autocomplete for hobbies and personal interests using the Wikidata API.
• Store Wikidata Q-IDs alongside display labels for each interest.
• Wikidata's hierarchy enables the recommendation system to understand that a mentee interested in "chess" and a mentor interested in "board games" share a related interest.
• Wikidata entities are linked data (RDF) and can be referenced in JSON-LD responses.
• Free text is still allowed as a fallback for interests not in Wikidata.

How ESCO and Wikidata complement each other: ESCO standardizes professional skills and knowledge (e.g., "machine learning", "project management"). Wikidata standardizes personal interests and hobbies (e.g., "photography", "chess"). Together they cover the full range of user interests that feed into our recommendation system, including the diverse/out-of-the-box suggestions required by 1.1.2.4.

Status: Planned. Will be integrated alongside the recommendation system (#137).

---

6. ISCED-F for Fields of Education

Standard: ISCED Fields of Education and Training 2013 (ISCED-F) (UNESCO)

Why it is relevant to our project: Mentors specify their professional field and mentees specify their university major. ISCED-F provides a standardized classification of education fields used internationally, ensuring consistent categorization across users. For example, "CS", "Computer Science", and "Bilgisayar Mühendisliği" all map to ISCED-F code 0613 (Software and applications development and analysis).

How it applies to our project:

Our field	ISCED-F level	Example codes
Mentor field	Broad field (2-digit)	06 — Information and Communication Technologies
Mentee major	Narrow field (3-digit)	061 — Information and Communication Technologies
Detailed specialization	Detailed field (4-digit)	0613 — Software and applications development

Integration approach:

• Profile forms offer a dropdown of ISCED-F fields for mentor field and mentee major selection.
• Store ISCED-F codes alongside display labels.
• The recommendation algorithm uses ISCED-F hierarchy: a mentee studying "0613 Software development" matches with a mentor in the broader "06 ICT" field.
• ISCED-F field codes complement ESCO occupation codes — together they describe what someone studied (ISCED-F) and what they can do (ESCO).

Status: Planned. Will be integrated alongside profile updates and the recommendation system (#137).

---

7. iCalendar (RFC 5545) for Scheduling

Standard: RFC 5545 — Internet Calendaring and Scheduling Core Object Specification (IETF)

Why it is relevant to our project: Mentors define weekly availability slots and schedule recurring meetings with mentees. iCalendar is the universal format supported by Google Calendar, Apple Calendar, and Outlook, allowing users to sync mentorship schedules with their personal calendars.

How it applies to our project:

Our concept	iCalendar component	Properties
Mentor availability slot	VEVENT with RRULE	RRULE:FREQ=WEEKLY;BYDAY=MO for a recurring Monday slot
Scheduled meeting	VEVENT	DTSTART, DTEND, SUMMARY, DESCRIPTION, ORGANIZER, ATTENDEE
Meeting reminder	VALARM	TRIGGER:-PT1H for a 1-hour-before reminder
Timezone	VTIMEZONE	TZID=Europe/Istanbul

Integration approach:

• Endpoint GET /api/availability/{mentorId}/ical serves a .ics file with Content-Type: text/calendar.
• Each AvailabilitySlot (which stores dayOfWeek, startTime, endTime, recurring) is converted to a VEVENT with RRULE:FREQ=WEEKLY.
• The ical4j library handles serialization to ensure RFC 5545 compliance.

Note: Schema.org Schedule (section 3) and iCalendar serve different purposes and do not conflict. Schema.org Schedule models availability data within our API responses as linked data. iCalendar provides an export format for external calendar applications. The same underlying AvailabilitySlot data is served in both formats depending on the client's needs.

Status: Planned. Tracked in issue #250.

---

8. OpenAPI 3.0

Standard: OpenAPI Specification 3.0 by the OpenAPI Initiative (Linux Foundation)

Why it is relevant to our project: Our platform has three clients — web frontend (React), mobile app (React Native), and developer documentation. OpenAPI provides a single machine-readable API contract that all consumers share.

How it is integrated:

• springdoc-openapi-starter-webmvc-ui (v2.8.0) auto-generates the OpenAPI 3.0 specification from annotated controllers.
• All controllers use @Operation, @ApiResponses, @Schema, @Tag, and @Parameter annotations.
• JWT Bearer authentication is documented in the OpenAPI security scheme.
• Swagger UI at /swagger-ui.html in development; disabled in production.
• Raw specification at /v3/api-docs.

Status: Fully implemented.

---

9. JWT (RFC 7519) for Authentication

Standard: RFC 7519 — JSON Web Token (IETF)

Why it is relevant to our project: Stateless authentication across web and mobile clients. JWT encodes user identity (mentor/mentee/admin) and role in a compact token, eliminating server-side session storage.

How it is integrated:

• Tokens issued on login (POST /api/auth/login) signed with HMAC-SHA256 (HS256).
• Claims: sub (email), userId, role (MENTOR/MENTEE), iat, exp (24-hour expiry).
• JwtAuthenticationFilter validates tokens and populates Spring Security context.
• Stateless session management (SessionCreationPolicy.STATELESS).
• Passwords hashed with BCrypt.

Status: Fully implemented.

---

10. WCAG 2.1 for Accessibility

Standard: Web Content Accessibility Guidelines 2.1 (W3C Recommendation)

Why it is relevant to our project: The platform connects students with community mentors — accessibility ensures all users, including those with disabilities, can participate in the mentorship experience.

How it is integrated:

• ARIA attributes: aria-label, aria-expanded, aria-haspopup, aria-invalid, aria-modal, and role on interactive elements (buttons, modals, dropdowns, notification bell).
• Semantic HTML: <nav> for navigation, <main> for content, proper heading hierarchy.
• Form accessibility: Inputs linked to labels via htmlFor/id, validation errors via aria-invalid.
• Modal accessibility: Mentorship request modal uses role="dialog" and aria-modal.

Areas for improvement: Image alt text, skip navigation links, color contrast, keyboard focus indicators, screen reader testing.

Status: Partially implemented.

---

Summary

Standard	Source	Role in our project	Status
Activity Streams 2.0	W3C	Data model for platform events and notifications	Planned
JSON-LD 1.1	W3C	Serialization format for linked data (profiles, activities)	Planned (#251)
Schema.org	Google/W3C	Vocabulary for profiles, schedules, ratings, blog posts	Planned (#251)
ESCO	European Commission	Standardized taxonomy for skills, competences, and occupations	Planned (#137)
Wikidata	Wikimedia Foundation	Standardized identifiers for hobbies and personal interests	Planned (#137)
ISCED-F	UNESCO	Classification of education fields and university majors	Planned (#137)
iCalendar (RFC 5545)	IETF	Calendar export for availability and meetings	Planned (#250)
OpenAPI 3.0	Linux Foundation	API contract for web, mobile, and developer consumers	Implemented
JWT (RFC 7519)	IETF	Stateless authentication across all clients	Implemented
WCAG 2.1	W3C	Web accessibility compliance	Partial

How the standards work together: Activity Streams defines the data model (actor-activity-object), JSON-LD provides the serialization format (@context, @type), and Schema.org supplies the vocabulary for domain objects (Person, Event, Rating, Article). ESCO provides standardized professional skills and occupations, Wikidata provides standardized hobbies and personal interests, and ISCED-F provides standardized education fields — all populating Schema.org's knowsAbout, skills, and education properties. iCalendar exports the same scheduling data that Schema.org Schedule models in the API. Together they form a coherent, interoperable data layer where every piece of user data is standardized and machine-readable.