Skip to content

revise to use "abstract data model" to unify "abstract syntax" and "data model" #232

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Sep 4, 2025
Merged

revise to use "abstract data model" to unify "abstract syntax" and "data model" #232

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
8034436
proposed changes to use 'abstract syntax' where it is appropriate.
lisp Aug 7, 2025
1cd0859
the changes replace 'abstract syntax' and 'data model' with the phras…
lisp Aug 10, 2025
e969123
this version of the changes use 'abstract data model' instead of 'ab…
lisp Aug 31, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
47 changes: 24 additions & 23 deletions spec/index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@
<head>
<meta charset="utf-8">
<meta name="color-scheme" content="light dark">
<title>RDF 1.2 Concepts and Abstract Syntax</title>
<title>RDF 1.2 Concepts and Abstract Data Model</title>
<script src="https://www.w3.org/Tools/respec/respec-w3c" class="remove"></script>
<script src="./common/local-biblio.js" class="remove"></script>
<script src="./common/fixup.js" class="remove"></script>
Expand Down Expand Up @@ -77,9 +77,9 @@
<section id="abstract">
<p>The Resource Description Framework (RDF) is a framework for
representing information on the Web.
This document defines an abstract syntax (a data model)
This document defines an abstract data model
which serves to link all RDF-based languages and specifications.
The abstract syntax has two key data structures:</p>
The abstract model has two key data structures:</p>
Copy link
Contributor

@niklasl niklasl Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The abstract model has two key data structures:</p>
The abstract data model has two key data structures:</p>

I think it's important to consistently spell out "data" in "data model", since "model" may refer to domain models (related to (properties and classes in) an interpretation).

Copy link
Contributor Author

@lisp lisp Aug 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in general, my concern is clarity.

  • the suggestion, to use "abstract model" rather than "abstract data model" was intended to create more distance to "data model", which itself tends to concern domains.

  • reintroducing the phrase "abstract syntax" where one intends the topic to be "syntax" could make sense, were it that the document contained an actual abstract syntax. as it does not, its appearance in the title misleads.

Copy link
Contributor

@niklasl niklasl Aug 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, clarity is the goal here.

This document defines RDF graphs as sets of RDF triples. Using notions from Wikipedia (FWIW), those are a kind of graph, which is a data structure (a kind of data type). And "an abstract syntax of data is its structure described as a data type". I'm not sure how clear that is; but do you say that the set of triples so defined, while being a structure, is not described properly as a data type?

I can accept data model:

A data model is an abstract model that organizes elements of data and standardizes how they relate to one another and to the properties of real-world entities.

if it's clear enough to avoid conflating that with any kind of conceptual model, which is sometimes called an abstract model (and therein lies the rub).

I've been happy enough with "abstract syntax", to avoid cans of worms such as "what is the model, and what does it model".

I think we need to make this clearer still; perhaps keep explicitly saying "graph data model" instead of "abstract", and note that the abstract syntax is "the structural definition of this data model". I recall @franconi wanting to include a grammar for this as well; would that be useful? Such as:

graph       ::= triple*
triple      ::= subject IRI object
subject     ::= IRI | BlankNode
object      ::= subject | Literal | triple

Copy link
Contributor Author

@lisp lisp Aug 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

indeed.
without this

graph ::= triple*
triple ::= subject IRI object
subject ::= IRI | BlankNode
object ::= subject | Literal | triple

you have a discursive description which introduces terminology.

<ul>
<li>RDF graphs are sets of subject-predicate-object triples,
where the elements may be IRIs, blank nodes, datatyped literals, or triple terms.
Expand Down Expand Up @@ -119,7 +119,7 @@ <h2>Introduction</h2>
<p>The <em>Resource Description Framework</em> (RDF) is a framework
for representing information on the Web.</p>

<p>This document defines an abstract syntax (a data model)
<p>This document defines an abstract data model
which serves to link all RDF-based languages and specifications,
including the following:</p>

Expand All @@ -135,9 +135,9 @@ <h2>Introduction</h2>
</ul>

<section id="data-model">
<h3>Graph-based Data Model</h3>
<h3>Graph-based Abstract Data Model</h3>

<p>The core structure of the abstract syntax is a set of
<p>The core structure of the abstract model is a set of
Copy link
Contributor

@niklasl niklasl Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<p>The core structure of the abstract model is a set of
<p>The core structure of the abstract data model is a set of

<a data-lt="RDF triple">triples</a>, each consisting of a <a>subject</a>,
a <a>predicate</a> and an <a>object</a>. A set of such triples is called
an <a>RDF graph</a>. An RDF graph can be visualized as a node and
Expand All @@ -155,8 +155,8 @@ <h3>Graph-based Data Model</h3>
<p>There can be four kinds of <a>nodes</a> in an
<a>RDF graph</a>: <a>IRIs</a>, <a>literals</a>,
<a>blank nodes</a>, and <a>triple terms</a>.</p>

<p class="issue" data-number="129">There is a mixture of "Abstract Syntax" and "Data Model". We should have a consistent way to say "Abstract Syntax" vs "Data Model". One way is to use "Abstract Syntax" as the basis of semantics and usually say "Data Model" in Concepts otherwise.</p>
<!--
<p class="issue" data-number="129">There is a mixture of "Abstract Syntax" and "Data Model". We should have a consistent way to say "Abstract Syntax" vs "Data Model". One way is to use "Abstract Syntax" as the basis of semantics and usually say "Data Model" in Concepts otherwise.</p> -->
</section>

<section id="resources-and-statements">
Expand Down Expand Up @@ -255,7 +255,7 @@ <h3>The Referent of an IRI</h3>
unique identifiers in a graph data model that describes resources.
However, those interactions are critical to the concept of
[[[LINKED-DATA]]], [[LINKED-DATA]],
which makes use of the RDF data model and serialization formats.</p>
which uses the RDF abstract syntax and serialization formats.</p>
Copy link
Contributor

@niklasl niklasl Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's good to keep "abstract syntax" where applicable. It needs some explanation, such as "the form of the abstract data model" (will consider that more in w3c/rdf-star-wg#172).

</section>

<section id="vocabularies">
Expand Down Expand Up @@ -305,7 +305,7 @@ <h3>RDF Vocabularies and Namespace IRIs</h3>
would be abbreviated as <code>rdf:XMLLiteral</code>.
Note however that such abbreviations are <em>not</em> meant to be processed directly as IRIs,
and are not to be used in syntactic contexts where IRIs are expected.
Note also that [=namespace IRIs=] and [=namespace prefixes=] are not a formal part of the RDF data model.
Note also that [=namespace IRIs=] and [=namespace prefixes=] are not a formal part of the RDF abstract model.
Copy link
Contributor

@niklasl niklasl Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Note also that [=namespace IRIs=] and [=namespace prefixes=] are not a formal part of the RDF abstract model.
Note also that [=namespace IRIs=] and [=namespace prefixes=] are not a formal part of the RDF abstract data model.

They are merely a syntactic convenience for abbreviating IRIs;
for processing, the actual IRIs are reconstructed by replacing each namespace prefix with the corresponding namespace IRI.
</p>
Expand Down Expand Up @@ -400,7 +400,7 @@ <h3>Triple Terms and Reification</h3>
<section id="change-over-time">
<h3>RDF and Change over Time</h3>

<p>The RDF data model is <em>atemporal</em>: <a>RDF graphs</a>
<p>The RDF abstract model is <em>atemporal</em>: <a>RDF graphs</a>
Copy link
Contributor

@niklasl niklasl Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<p>The RDF abstract model is <em>atemporal</em>: <a>RDF graphs</a>
<p>The RDF abstract data model is <em>atemporal</em>: <a>RDF graphs</a>

are static snapshots of information.</p>

<p>However, <a>RDF graphs</a> can express information
Expand Down Expand Up @@ -595,13 +595,13 @@ <h3>RDF Version Announcement</h3>
</section>

<section id="conformance">
<p>This specification, <em>RDF 1.2 Concepts and Abstract Syntax</em>,
defines a data model and related terminology for use in
<p>This specification, <em>RDF 1.2 Concepts and Abstract Model</em>,
Copy link
Contributor

@niklasl niklasl Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<p>This specification, <em>RDF 1.2 Concepts and Abstract Model</em>,
<p>This specification, <em>RDF 1.2 Concepts and Abstract Data Model</em>,

defines an abstract model and related vocabulary for use in
Copy link
Contributor

@niklasl niklasl Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
defines an abstract model and related vocabulary for use in
defines an abstract data model and related vocabulary for use in

Copy link
Contributor

@pchampin pchampin Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that "vocabulary" has a rather specific meaning in the context of RDF, I would keep the word "terminology" here.

Suggested change
defines an abstract model and related vocabulary for use in
defines an abstract model and related terminology for use in

NB: arguably, we are also defining an RDF vocabulary (in the rdf: namespace), but I don't think that's what is referred to here.

Copy link
Contributor Author

@lisp lisp Aug 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i had suggested the change because the document does introduce specific rdf terms.
at the same time, other passages do remain at the abstract level of terminology.
an alternative is to draw in all three aspects

abstract model and related terminology and elements of a vocabulary

Copy link
Contributor

@niklasl niklasl Aug 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That might be proper. AFAICS, it defines five datatypes (rdf:langString, rdf:dirLangString, rdf:HTML, rdf:XMLLiteral, and rdf:JSON). (I'm not sure if it fully defines rdf:reifies as that is at least further documented in RDF Schema.) Perhaps keep "terminology" here, and if needed add a sentence after? Something like:

It also defines some of the terms in the RDF vocabulary.

other specifications, such as
<a>concrete RDF syntaxes</a>,
API specifications, and query languages.
Implementations cannot directly conform to
<em>RDF 1.2 Concepts and Abstract Syntax</em>,
<em>RDF 1.2 Concepts and Abstract Model</em>,
Copy link
Contributor

@niklasl niklasl Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<em>RDF 1.2 Concepts and Abstract Model</em>,
<em>RDF 1.2 Concepts and Abstract Data Model</em>,

but can conform to such other specifications that normatively
reference terms defined here.</p>

Expand Down Expand Up @@ -847,7 +847,8 @@ <h3>IRIs</h3>
is a <a>string</a> that conforms to the syntax
defined in RFC 3987 [[!RFC3987]].</p>

<p>An IRI in the RDF abstract syntax
<p>An IRI in the RDF abstract model
Copy link
Contributor

@niklasl niklasl Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we keep "abstract syntax" where applicable (see above), I propose to keep it in places discussing syntactic details:

Suggested change
<p>An IRI in the RDF abstract model
<p>An IRI in the RDF abstract syntax

<!-- this passeage does not discuss abstract syntax. it concerns concrete systax -->
MUST be <a data-cite="RFC3986#section-5">resolved</a> per [[RFC3986]] and
MUST NOT be a <a data-cite="RFC3986#section-4.2">relative reference</a>.
An IRI MAY contain a <a data-cite="RFC3986#section-3.5">fragment identifier</a>.
Expand All @@ -859,7 +860,7 @@ <h3>IRIs</h3>
<a data-cite="I18N-GLOSSARY#dfn-code-point" class="lint-ignore">Unicode code points</a>,
as in Simple String Comparison in
<a data-cite="rfc3987#section-5.3.1">section 5.3.1</a> of [[!RFC3987]].
(This is done in the abstract syntax, so the IRIs are resolved
(This is done in the abstract model, so the IRIs are resolved
Copy link
Contributor

@niklasl niklasl Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
(This is done in the abstract model, so the IRIs are resolved
(This is done in the abstract syntax, so the IRIs are resolved

IRIs with no escaping or encoding.)
Further normalization MUST NOT be performed before this comparison. </p>

Expand All @@ -877,7 +878,7 @@ <h3>IRIs</h3>
An IRI reference is common usage of an Internationalized Resource Identifier.
An IRI reference refers to either a resolved <a>IRI</a> or <a>relative IRI reference</a>,
as described by the <em>IRI-reference</em> production in <a href="#iri-abnf" class="sectionRef"></a>.
The abstract syntax uses only fully resolved <a>IRIs</a>.
The abstract model uses only fully resolved <a>IRIs</a>.
Copy link
Contributor

@niklasl niklasl Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The abstract model uses only fully resolved <a>IRIs</a>.
The abstract syntax uses only fully resolved <a>IRIs</a>.

When IRIs are used in operations that are only
defined for URIs, they must first be converted according to
the mapping defined in
Expand Down Expand Up @@ -1008,7 +1009,7 @@ <h4>Representation of Literals</h4>
<p>Some concrete syntaxes MAY support
<dfn data-lt="simple literal" class="export">simple literals</dfn> consisting of only a
<a>lexical form</a> without any <a>datatype IRI</a>, <a>language tag</a>, or <a>base direction</a>.
Simple literals are syntactic sugar for abstract syntax
Simple literals are syntactic sugar for data model
Copy link
Contributor

@niklasl niklasl Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Simple literals are syntactic sugar for data model
Simple literals are syntactic sugar for abstract syntax

<a>literals</a>
with the <a>datatype IRI</a>
<code>http://www.w3.org/2001/XMLSchema#string</code>
Expand Down Expand Up @@ -1037,7 +1038,7 @@ <h4>Representation of Literals</h4>
In RDF 1.1, `"chat"@fr` and `"chat"@FR` represent two distinct terms,
but implementations may replace either with the other via some form of normalization.
In RDF 1.2, they represent the exact same literal,
i.e., the case difference in the concrete syntax does not propagate into the abstract syntax.
i.e., the case difference in the concrete syntax does not propagate into the abstract model.
Copy link
Contributor

@niklasl niklasl Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
i.e., the case difference in the concrete syntax does not propagate into the abstract model.
i.e., the case difference in the concrete syntax does not propagate into the abstract syntax.

Since many RDF 1.1 implementations do normalize language tags internally, they will not be impacted by this change.
</aside>

Expand Down Expand Up @@ -1145,7 +1146,7 @@ <h3>Blank Nodes</h3>
They are always locally scoped to the file or RDF store,
and are <em>not</em> persistent or portable identifiers
for blank nodes. Blank node identifiers are <em>not</em>
part of the RDF abstract syntax, but are entirely dependent
part of the RDF abstract model, but are entirely dependent
Copy link
Contributor

@niklasl niklasl Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
part of the RDF abstract model, but are entirely dependent
part of the RDF abstract syntax, but are entirely dependent

on the concrete syntax or implementation. The syntactic restrictions
on blank node identifiers, if any, therefore also depend on
the concrete RDF syntax or implementation. Implementations that handle blank node
Expand Down Expand Up @@ -1943,7 +1944,7 @@ <h3>The <code>rdf:JSON</code> Datatype</h3>
<section id="section-skolemization">
<h2>Replacing Blank Nodes with IRIs</h2>

<p>Blank nodes do not have identifiers in the RDF abstract syntax. The
<p>Blank nodes do not have identifiers in the RDF abstract model. The
Copy link
Contributor

@niklasl niklasl Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<p>Blank nodes do not have identifiers in the RDF abstract model. The
<p>Blank nodes do not have identifiers in the RDF abstract syntax. The

<a>blank node identifiers</a> introduced
by some concrete syntaxes have only
local scope and are purely an artifact of the serialization.</p>
Expand Down Expand Up @@ -1999,7 +2000,7 @@ <h2>Privacy Considerations</h2>
<section id="security" class="appendix informative">
<h2>Security Considerations</h2>

<p>The RDF Abstract Syntax is not used directly for conveying information,
<p>The RDF Abstract Model is not used directly for conveying information,
Copy link
Contributor

@niklasl niklasl Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<p>The RDF Abstract Model is not used directly for conveying information,
<p>The RDF Abstract Data Model is not used directly for conveying information,

Copy link
Member

@TallTed TallTed Aug 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<p>The RDF Abstract Model is not used directly for conveying information,
<p>The RDF Abstract Data Model is not used directly for conveying information;

although concrete serialization forms are specifically intended to do so.</p>
Copy link
Member

@TallTed TallTed Aug 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
although concrete serialization forms are specifically intended to do so.</p>
concrete serialization forms are specifically intended to do so.</p>

Copy link
Contributor Author

@lisp lisp Aug 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, with the period to end the previous line.

Copy link
Member

@TallTed TallTed Aug 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lisp — I suggested ending the previous line with a semicolon, which is why I suggested this line retain the lowercase concrete instead of changing to an uppercase Concrete.

Copy link
Contributor Author

@lisp lisp Aug 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i did see the previous suggestion.

Copy link
Member

@TallTed TallTed Aug 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lisp — I'm confused...

You "did see the previous suggestion", that being to end the previous line with a semicolon, but you previously said "with the period to end the previous line".

Are you now saying you're OK with the semicolon, or are you pushing for the period? If the period is to happen, then although concrete must change to Concrete rather than concrete, as it stands, upon which you did not comment, and I think this puts too much separation between "conveying information" from the "specific [intent]".

My full preferred suggestion:

  <p>The RDF Abstract Model is not used directly for conveying information;
    concrete serialization forms are specifically intended to do so.</p>

What I think you want:

  <p>The RDF Abstract Model is not used directly for conveying information.
    Concrete serialization forms are specifically intended to do so.</p>

These are very similar, but not identical, in their effect. The semicolon tightly connects the latter phrase to the former, making it clearer that to do so refers to conveying information, i.e., making it clearly say concrete serialization forms are specifically intended to convey information without repeating the latter two words.


<p>Applications MAY evaluate given data to infer more assertions or to dereference <a>IRIs</a>,
Expand Down Expand Up @@ -2215,7 +2216,7 @@ <h2>Changes between RDF 1.1 and RDF 1.2</h2>
<li>Improved the use of IRI terminology,
and added <a href="#iri-abnf" class="sectionRef"></a>.
This improves the language using <a>relative IRI references</a>
and clarifies that, in the abstract syntax, IRIs are resolved,
and clarifies that, in the abstract model, IRIs are resolved,
Copy link
Contributor

@niklasl niklasl Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
and clarifies that, in the abstract model, IRIs are resolved,
and clarifies that, in the abstract syntax, IRIs are resolved,

avoiding the incorrect use of "absolute IRI".</li>
<li>Changed reference from DOM4, which was not a recommendation at the time, to [[DOM]],
making the definitions of <a>rdf:HTML</a> and <a>rdf:XMLLiteral</a> datatypes normative.</li>
Expand Down
Loading