Semantic Value Staging Ontology
Minimal vocabulary for staging a professional claim's Syntax/Meaning/Proof revisions across time. Deliberately small: it supplements oplli:, schema.org, PROV-O and W3C Verifiable Credentials rather than replacing any of them — every fact those vocabularies can already express is expressed with them, not re-declared here.
Professional Claim
A syntactically well-formed assertion about a person's work, applied as an additional type alongside a native oplli: resource (oplli:Position, oplli:Person). On its own — as plain oplli:positionSummary/oplli:headline text — it carries no bound meaning and no external proof. Corresponds to Turner's 'syntax' layer. Specializes schema:Claim (verified real schema.org type, 'a specific, factually-oriented claim that could be the itemReviewed in a ClaimReview') to the professional-work domain.
Semantic Value Level
Which layer(s) of Turner's formula (Syntax, Meaning, Proof) a given RDF rendition of a claim satisfies. Specializes skos:Concept, consistent with :Syntax/:Meaning/:Proof already carrying skos:prefLabel and skos:inScheme below.
Syntax only
Syntax + Meaning
Syntax + Meaning + Proof
has semantic value level
Assigns the single Syntax/Meaning/Proof stage a claim resource currently occupies. Checked for a broader schema.org/DBpedia/Wikidata superproperty; none found — schema:additionalType is untyped/generic and not a defensible match for a three-value enumeration, so no rdfs:subPropertyOf is asserted. owl:FunctionalProperty: a claim resource has exactly one stage at a time, never two.
revision of
Chains successive renditions of the same underlying claim as it accrues ontology typing (meaning) and then external evidence (proof). owl:AsymmetricProperty + owl:IrreflexiveProperty: a claim cannot be a revision of itself, and if A revisionOf B then B is never revisionOf A. owl:FunctionalProperty: each stage in this file has exactly one immediate predecessor.
Claimant
Syntax stage — bare claim
Grammatically well-formed and parseable, but oplli:Position has no oplli:jobTitle and no oplli:company asserted: 'enterprise' and 'transformation' are unbound. A reasoner can validate the string; it cannot validate the claim.
Meaning stage — bound to Position/Company/JobTitle
Led enterprise sales transformation across a 6,000+ seller organization.
oplli:jobTitle and oplli:company are now bound to named resources — the claim's variables are populated using the ontology's own native Position/Company/JobTitle classes. Nothing outside the claim yet confirms it happened or worked.
Proof stage — schema:result metrics via PROV-O
Led enterprise sales transformation across a 6,000+ seller organization, improving Salesforce adoption, pipeline governance and executive decision-making.
oplli: — a real, dereferenceable LinkedIn/Xing profile ontology — has no property anywhere for a Position's measurable outcome; it predates 'proof metrics' as a stated concern. schema:result plus PROV-O fill exactly that gap: the same resource is additionally typed prov:Activity so its outcomes can be independently addressed, typed schema:QuantitativeValue entities rather than more adjectives inside positionSummary.
Salesforce adoption rate
Pipeline governance maturity
Trust Loop — self-issued, ungrounded
I'm strategic because I say I'm strategic.
vc:issuer is identical to vc:credentialSubject — the standard-vocabulary definition of self-attestation. No sec:proof is asserted, and post:person has zero incoming oplli:recommendationsReceived — no oplli:Recommendation resource exists anywhere in the graph. That absence, checkable by a simple query, IS Turner's Trust Loop.
Trust Loop broken — externally witnessed
Led the board-approved 3-year growth strategy that took ARR from $40M to $95M.
Contrast case: vc:issuer now resolves to a distinct schema:Organization and sec:proof references independent evidence — the formal/cryptographic shape of an external witness. In parallel, post:person carries an actual oplli:recommendationsReceived link to an oplli:Recommendation, which is the ontology's own native answer to the same problem: 'a Recommendation adds third-party corroboration,' in Turner's words, not a custom property invented for this file.
Board of Directors
Board resolution approving 3-year growth strategy
ARR growth, 3-year strategy
Syntax stage — bare, ambiguous number
A number is present, but post:ambiguousAmount is untyped beyond a bare value: no schema:MonetaryAmount subtype, no schema:currency asserted as a distinguishing fact, no prov:wasGeneratedBy link — and oplli: has no property for this at all. Revenue, savings, pipeline, valuation, bookings and budget remain equally consistent with this graph. Proof-shaped syntax without proof.
Proof stage — typed MonetaryAmount with provenance
Generated $17M in incremental revenue by rebuilding the enterprise partner strategy across North America, reversing two years of channel decline.
rdf:type schema:MonetaryAmount (not a bare schema:QuantitativeValue) plus schema:currency plus prov:wasGeneratedBy an explicitly typed, geographically scoped schema:Action/prov:Activity resolves what kind of $17M this is and what produced it — using schema.org/PROV-O precisely where oplli: is silent.
Incremental revenue from partner strategy rebuild
Enterprise Partner Strategy Rebuild
North America
Proof stage — scale, comparison and timeframe
Raised customer retention from 72% to 91% in 18 months across a 4.2M-member portfolio.
A bare 'Improved customer retention' claim would render here as a single unscoped schema:QuantitativeValue with no minValue/maxValue/duration — the reader (human or machine) would have to supply starting point, ending point, timeframe and scale itself. Typing the change as minValue/maxValue/duration on one resource, plus a separately typed schema:Audience for portfolio size, makes all four dimensions queryable facts instead of prose to infer. oplli: has no equivalent property for a Position's performance delta, so schema.org carries this stage entirely.
Customer retention rate, before/after
percent
Retention program membership base
Turner Semantic Value Levels
Semantic Value on LinkedIn: Why Proof Changes What a Claim Means
The source article. Prose-only: it states 'Syntax + Meaning + Proof = Semantic Value' and walks worked before/after claim pairs, but never renders a claim as structured data. This TTL/HTML pair is the worked RDF demonstration the article itself does not provide.
Kevin D. Turner
Author of the source LinkedIn article. IRI is the author's own LinkedIn profile URL, read directly from the article page's byline link (linkedin.com/in/president), per the LinkedIn-profile-first Person IRI denotation priority.
Semantic Value on LinkedIn — Worked RDF Examples in oplli:, schema.org, PROV-O and W3C Verifiable Credentials
Kevin D. Turner's LinkedIn article makes one point: a claim on a profile only becomes trustworthy once it has context and evidence behind it — not just confident wording. This page proves that point by rebuilding four of his own example claims as structured data, one stage at a time: the bare claim, the claim with context added, and the claim backed by evidence. The structured data reuses existing, real standards rather than inventing new ones. OpenLink's own oplli: vocabulary already matches LinkedIn's own profile fields, so it does most of the work. schema.org and PROV-O step in only where that vocabulary has a genuine gap: describing a measurable result. And the W3C's Verifiable Credentials standard distinguishes a claim someone else vouches for from a claim that only vouches for itself. Two small labels — post:ProfessionalClaim and post:SemanticValueLevel — were added on top, because nothing else marks which of the three stages a given claim has reached.
How to Render a Professional Claim's Syntax/Meaning/Proof Stages in RDF
Survey existing vocabularies before minting anything
Check for a dedicated vocabulary first (here: DOAC and ResumeRDF for CVs/resumes). Reject any candidate whose namespace cannot be confirmed as stable and dereferenceable at authoring time — do not fabricate or guess an IRI to make a candidate usable.
Prefer a real, field-matching ontology over a generic one
When a supplied or locally available ontology matches the source's own field structure (here: OpenLink's oplli: LinkedIn ontology, whose positionSummary/headline/Position/Recommendation map directly onto Turner's [Experience]/[Headline]/[About] examples), use it as the primary vocabulary rather than a generic alternative.
Render the bare claim as the Syntax stage
Attach the claim's literal text to the chosen native property (oplli:positionSummary or oplli:headline) with no supporting typed entities. This stage should look exactly as unbound as the plain-English sentence is.
Bind claim variables using the ontology's own classes for the Meaning stage
Add typed resources using the chosen ontology's native classes (oplli:JobTitle, oplli:Company) so the claim's previously-unbound variables (who, where, how large) resolve to addressable entities.
Identify a genuine gap before reaching for a second vocabulary
Confirm, rather than assume, that the primary ontology has no property for the needed fact. oplli: (dateCreated 2013) has no property anywhere for a Position's measurable outcome — a genuine, checkable gap, not a convenience shortcut.
Fill confirmed gaps with schema.org and PROV-O for the Proof stage
Use schema:result, schema:QuantitativeValue, schema:MonetaryAmount and prov:wasGeneratedBy/prov:Entity only where the primary ontology has nothing to offer, so outcomes exist as independently addressable, typed resources rather than more adjectives in the claim text.
Model self-attestation vs. external witness with W3C Verifiable Credentials
For claims whose 'proof' is corroboration rather than a metric (the Trust Loop), use vc:credentialSubject and vc:issuer: identical values model self-attestation, distinct values plus sec:proof model an external witness. Chain every stage to its predecessor with post:revisionOf (subPropertyOf prov:wasRevisionOf) so the claim's history stays queryable.
FAQ: Semantic Value, Proof, and RDF
What does "Syntax + Meaning + Proof = Semantic Value" mean?
It is Kevin D. Turner's formula for why one professional claim reads as trustworthy and another, using similar words, reads as empty. Syntax is whether the sentence is well-formed; Meaning is whether its variables (who, what, how large) are bound to something specific; Proof is whether evidence exists outside the claim itself for someone to evaluate it against.
Why does this RDF/HTML pair exist if Turner's article already makes the argument?
The article stays entirely in prose — it never shows what a claim actually looks like once ontologies bind its meaning and proof. This companion renders four of the article's own before/after examples as RDF at each of the three stages, so the mechanism Turner describes is literal and machine-checkable rather than just asserted.
Why was OpenLink's oplli: ontology chosen instead of a generic vocabulary?
oplli: is a field-for-field match: oplli:headline and oplli:summary correspond directly to Turner's [Headline]/[About] examples, and oplli:Position/oplli:positionSummary/oplli:jobTitle/oplli:company correspond to his [Experience] examples. It also has built-in oplli:Certification and oplli:Recommendation classes — a Recommendation is exactly the third-party corroboration Turner names explicitly.
Why weren't DOAC or ResumeRDF used, since they are dedicated CV/resume ontologies?
Both were checked. Both are archived/inactive Semantic Web efforts from the early 2010s, and neither has a namespace that could be confirmed as stable and dereferenceable at authoring time — so neither is cited by IRI here, per the house rule against asserting unverified URLs.
What genuine gap in oplli: do schema.org and PROV-O fill?
oplli: (last modified 2018) has no property anywhere for a Position's measurable outcome — nothing plays the role of a 'proof metric.' schema:result, schema:QuantitativeValue, schema:MonetaryAmount and prov:wasGeneratedBy/prov:Entity are used only for that confirmed gap, not as a general replacement for oplli:.
Why use W3C Verifiable Credentials instead of a custom "grounded by" property?
An earlier draft of this file used a custom post:groundedBy property pointed at itself to model self-attestation. W3C Verifiable Credentials already has the standard shape for this: vc:issuer identical to vc:credentialSubject is self-attestation; vc:issuer distinct from vc:credentialSubject, alongside sec:proof, is an external witness. Reusing that standard shape is more precise than inventing a parallel one.
What is the "Trust Loop" and how does the RDF show it?
Turner's Trust Loop is a claim whose only support is repeating itself ('I'm strategic because I say I'm strategic'). In post:trustLoopClaim, vc:issuer is literally the same resource as vc:credentialSubject, and the claimant has zero incoming oplli:recommendationsReceived links anywhere in the graph — both facts are checkable by a simple query, unlike a feeling of confidence in prose.
What does post:hasSemanticValueLevel do that rdf:type alone could not?
post:hasSemanticValueLevel is a dedicated object property pointing at a post:SemanticValueLevel individual (post:Syntax, post:Meaning, or post:Proof) so a query can filter claims by stage directly, independent of which native ontology (oplli:, VC) is also typing that same resource via rdf:type.
Why is "Generated $17M." ambiguous even though it contains a number?
In post:positionC_numbersOnly, the linked post:ambiguousAmount is typed only as a bare schema:QuantitativeValue with a numeric schema:value — no schema:MonetaryAmount subtype, no schema:currency, no prov:wasGeneratedBy. Revenue, savings, pipeline, valuation, bookings and budget are all still equally consistent with that graph. A number is not proof; a typed, provenance-linked number is.
What does oplli:Recommendation contribute that Turner's article names explicitly?
Turner writes that 'a Recommendation adds third-party corroboration.' oplli:Recommendation, reached via oplli:recommendationsReceived, is that exact mechanism already built into a real, dereferenceable LinkedIn/Xing profile ontology — not a term invented for this exercise.
How does this relate to Tarski's Convention T, which Turner cites?
Tarski's Convention T distinguishes a sentence from the condition that would make it true ('snow is white' is true iff snow is white). Turner applies this to profiles: a profile cannot make its own claim true by restating it. In RDF terms, the Meaning and Proof stages exist precisely to give a claim resources outside itself — schema:result entities, oplli:Recommendation, sec:proof — that a reasoner or a reader can check independently of the claim's own text.
Why does oplli:recommender use a plain string instead of an object property to a Person?
That is a real, honest limitation of the 2013-vintage oplli: ontology, not a choice made for this exercise — oplli:recommender's declared rdfs:range is xsd:string. It is why the Trust-Loop contrast case also layers in vc:issuer/sec:proof: those add the machine-checkable, distinct-external-party structure that a bare string name cannot guarantee on its own.
Glossary: Ontologies, Proof, and Semantic Value
Semantic Value
Turner's term for a claim's combined trustworthiness and informational content, produced by Syntax + Meaning + Proof together, not by any one layer alone.
Syntax (layer)
Whether a claim is grammatically well-formed and parseable. Corresponds in this file to a claim resource typed post:Syntax via post:hasSemanticValueLevel, with no supporting typed entities yet.
Meaning (layer)
Whether a claim's variables are bound to something specific and checkable. Rendered here as ontology typing (oplli:jobTitle, oplli:company) that resolves who/what/how-large.
Proof (layer)
Whether evidence exists outside the claim itself for someone to evaluate it against. Rendered here via schema:result/PROV-O outcomes or W3C Verifiable Credentials issuer/proof structure.
Trust Loop
Turner's term for a claim whose only support is repeating itself ('I'm strategic because I say I'm strategic'). Modeled here as vc:issuer identical to vc:credentialSubject with no external oplli:Recommendation anywhere in the graph.
oplli: (OpenLink Ontology for Professional Network Profiles)
A real, dereferenceable ontology at http://www.openlinksw.com/schemas/linkedin# (v1.0.0) for LinkedIn/Xing-style profile data — Person, Position, Certification, Recommendation, Skill, Company and their fields. Used as the primary vocabulary in this exercise because its fields map directly onto Turner's own [Headline]/[About]/[Experience] examples.
An oplli: class representing a position a profile member holds or has held, with properties positionSummary, jobTitle, company, startDate and endDate. Used here as the resource type for the [Experience]-style claim examples.
An oplli: class for a recommendation of one profile member by another, reached via oplli:recommendationsReceived. Matches Turner's own line that 'a Recommendation adds third-party corroboration.'
PROV-O
The W3C Provenance Ontology (http://www.w3.org/ns/prov#), supplying prov:Activity, prov:Entity, prov:wasGeneratedBy and prov:wasRevisionOf. Used here to fill oplli:'s confirmed gap around measurable outcomes.
schema.org
The widely-deployed general-purpose vocabulary, used here for schema:QuantitativeValue, schema:MonetaryAmount, schema:result and schema:Audience, again only where oplli: has no equivalent property.
W3C Verifiable Credentials (VC)
A W3C standard (terms confirmed to expand to https://www.w3.org/2018/credentials#) for credentials with a stated issuer and subject. Its issuer/credentialSubject/proof structure is reused here to make Turner's self-attestation-versus-external-witness distinction machine-checkable.
DOAC (Description of a Career)
An early Semantic Web vocabulary for career/resume data, extending FOAF. Checked and rejected for this exercise: archived/inactive, with no namespace confirmable as stable and dereferenceable at authoring time.
ResumeRDF
Another early Semantic Web resume/skill vocabulary (documented at rdfs.org/resume-rdf/). Checked and rejected for the same reason as DOAC: no namespace confirmable as stable and dereferenceable at authoring time.
Convention T (Tarski)
Alfred Tarski's schema for defining truth in formal languages ('snow is white' is true iff snow is white), cited by Turner to argue a profile cannot make its own claim true by restating it. Applied here as the reason Meaning/Proof stages point OUTSIDE the claim resource to independent evidence.
Example A — Led Enterprise Transformation
Turner's flagship progression. A bare claim ('Led enterprise transformation') is grammatically fine but leaves 'enterprise' and 'transformation' unbound. Binding it to oplli:Position with oplli:jobTitle and oplli:company supplies Meaning. Adding schema:result-linked, PROV-O-provenanced outcome metrics — filling a confirmed gap in oplli: — supplies Proof.
Example B — The Trust Loop
Turner's self-referential claim ('I'm strategic because I say I'm strategic'), modeled as a W3C Verifiable Credential whose vc:issuer equals its own vc:credentialSubject — self-attestation by definition. The contrast case adds a distinct vc:issuer, sec:proof, and an oplli:Recommendation, the ontology's own native third-party-corroboration class.
Example C — Quantified Personal Blanding
"Generated $17M." is proof-shaped but not proof: the linked amount is a bare schema:QuantitativeValue, equally consistent with revenue, savings, pipeline, valuation, bookings or budget. Retyping it as schema:MonetaryAmount with schema:currency and a prov:wasGeneratedBy-linked, geographically scoped activity resolves what kind of $17M it is.
Example D — Proof Metrics as Scale, Comparison and Timeframe
"Raised customer retention from 72% to 91% in 18 months across a 4.2M-member portfolio" is rendered with minValue/maxValue/duration on one schema:QuantitativeValue plus a separately typed schema:Audience for portfolio size — turning four dimensions a reader would otherwise have to infer from prose into queryable facts.
List every claim grouped by Semantic Value level
SPARQL
PREFIX : <https://linkeddata.uriburner.com/DAV/demos/daas/turner-semantic-value-linkedin-proof-examples-claude_sonnet_5-1.ttl#> PREFIX oplli: <http://www.openlinksw.com/schemas/linkedin#> PREFIX schema: <http://schema.org/> SELECT ?level ?claim (COALESCE(?summary, ?headline) AS ?claimText) WHERE { GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/turner-semantic-value-linkedin-proof-examples-claude_sonnet_5-1.ttl> { ?claim a :ProfessionalClaim ; :hasSemanticValueLevel ?level . OPTIONAL { ?claim oplli:positionSummary ?summary } OPTIONAL { ?claim oplli:headline ?headline } } } ORDER BY ?level ?claim
The baseline query: confirms every claim resource in the file declares exactly one post:hasSemanticValueLevel and that its native oplli: text is retrievable regardless of whether it lives on positionSummary or headline.
Detect self-attested (Trust Loop) claims
PREFIX vc: <https://www.w3.org/2018/credentials#> PREFIX sec: <https://w3id.org/security#> PREFIX oplli: <http://www.openlinksw.com/schemas/linkedin#> SELECT ?claim ?headline WHERE { GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/turner-semantic-value-linkedin-proof-examples-claude_sonnet_5-1.ttl> { ?claim a vc:VerifiableCredential ; vc:credentialSubject ?subject ; vc:issuer ?subject ; oplli:headline ?headline . FILTER NOT EXISTS { ?claim sec:proof ?anyProof } } }
Tests the Trust Loop proposition directly: a claim is flagged as self-attested if and only if its vc:issuer is the exact same node as its vc:credentialSubject and it carries no sec:proof. Run against this graph, this returns exactly post:trustLoopClaim and nothing else — post:groundedStrategicClaim has a distinct vc:issuer and IS excluded.
Verify every Proof-stage claim points outside itself
PREFIX : <https://linkeddata.uriburner.com/DAV/demos/daas/turner-semantic-value-linkedin-proof-examples-claude_sonnet_5-1.ttl#> PREFIX vc: <https://www.w3.org/2018/credentials#> PREFIX sec: <https://w3id.org/security#> PREFIX schema: <http://schema.org/> PREFIX oplli: <http://www.openlinksw.com/schemas/linkedin#> SELECT ?claim (BOUND(?evidence) AS ?hasExternalEvidence) WHERE { GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/turner-semantic-value-linkedin-proof-examples-claude_sonnet_5-1.ttl> { ?claim a :ProfessionalClaim ; :hasSemanticValueLevel :Proof . OPTIONAL { { ?claim schema:result ?evidence } UNION { ?claim schema:about ?evidence } UNION { ?claim sec:proof ?evidence } UNION { ?claim oplli:recommendationsReceived ?evidence } FILTER(?evidence != ?claim) } } } ORDER BY ?claim
Tests Tarski's Convention-T-derived proposition from the FAQ (a profile cannot make its own claim true by restating it): every row where ?hasExternalEvidence is false is a claim that calls itself post:Proof-level without actually pointing at a resource other than itself. Run against this graph, every row returns true.
Confirm the oplli: vocabulary gap empirically
PREFIX : <https://linkeddata.uriburner.com/DAV/demos/daas/turner-semantic-value-linkedin-proof-examples-claude_sonnet_5-1.ttl#> PREFIX oplli: <http://www.openlinksw.com/schemas/linkedin#> PREFIX schema: <http://schema.org/> PREFIX prov: <http://www.w3.org/ns/prov#> SELECT ?claim WHERE { GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/turner-semantic-value-linkedin-proof-examples-claude_sonnet_5-1.ttl> { ?claim a :ProfessionalClaim, oplli:Position ; :hasSemanticValueLevel :Proof . FILTER NOT EXISTS { ?claim ?oplliOutcomeProp ?outcome . FILTER(STRSTARTS(STR(?oplliOutcomeProp), STR(oplli:))) FILTER(?oplliOutcomeProp NOT IN (oplli:positionSummary, oplli:jobTitle, oplli:company, oplli:companySynopsis, oplli:startDate, oplli:endDate, oplli:title)) } } }
Tests the FAQ/glossary claim that oplli: has no property for a Position's measurable outcome. This query looks for any oplli:-namespaced predicate on a Proof-level oplli:Position claim OTHER than oplli:'s known descriptive Position/JobTitle fields. Run against this graph, every Proof-level oplli:Position claim (post:positionA_proof, post:positionC_proof, post:positionD_proof) matches — none of them has an oplli: outcome property, because none exists to have.
Walk a claim's revision chain from Syntax to Proof
PREFIX : <https://linkeddata.uriburner.com/DAV/demos/daas/turner-semantic-value-linkedin-proof-examples-claude_sonnet_5-1.ttl#> PREFIX oplli: <http://www.openlinksw.com/schemas/linkedin#> SELECT ?stage0 ?level0 ?stage1 ?level1 ?stage2 ?level2 WHERE { GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/turner-semantic-value-linkedin-proof-examples-claude_sonnet_5-1.ttl> { ?stage2 :revisionOf ?stage1 ; :hasSemanticValueLevel ?level2 . ?stage1 :revisionOf ?stage0 ; :hasSemanticValueLevel ?level1 . ?stage0 :hasSemanticValueLevel ?level0 . FILTER NOT EXISTS { ?stage0 :revisionOf ?anyEarlier } } }
Tests that post:revisionOf chains are well-formed three-hop paths ending at an unrevised Syntax-level claim. Run against this graph, this returns exactly the Example A chain (positionA_syntax → positionA_meaning → positionA_proof) — Example C's two-stage chain does not match a three-hop pattern, and Examples B/D have no post:revisionOf chain at all, both correctly, since B contrasts two independent claims and D has only one recorded stage.