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

[lisp]

this revision introduces the phrase, "abstract data model", to replace "abstract syntax" and "data model".
this permits the intended readers to align this document with usage from other graph modelling domains.
it also better indicates the actual document content.
the text includes neither expressions to specify the abstract relations nor terminals as required by a concrete model.

---

Preview | Diff

[pchampin]

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.

[lisp]

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

[niklasl]

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.

[w3cbot]

This was discussed during the #rdf-star meeting on 14 August 2025.

View the transcript

w3c/rdf-concepts#232

ora: where are we with abstract data model/syntax issue?

lisp: I was and I did.
… my change was a consequence of listening to comments last week.
… suggested to me that the wording was too ambiguous.
… my first attempt was to pick a term and use it. see reaction.
… that was not appreciated. several concerns.
… pulled back that PR and made another one.

<TallTed> latest is w3c/rdf-concepts#232

<gb> Pull Request 232 revise to use "abstract data model" to unify "abstract syntax" and "data model" (by lisp)

lisp: changes the usages which are about an abstract data model to "abstract data model".
… documented doesn't really have an abstract syntax in it.
… doesn't have concrete data model.
… now a PR with substitutions with "abstract data model" but no reactions so far.

ora: urge everyone to take a look at this.
… want to hear comments

niklasl: I've looked at that. In middle of review.
… I will post review.
… I think it's good to see it spelled out.
… The PR as it stands keeps abstract syntax in one place which is good. Has been there for ~20 years.

pfps: This changes the title of document. That's not a problem for W3C process(?)

pchampin: I don't think it is.

ora: docs identified by URL, not title, I suppose.

pfps: I'm fine with title change.

ora: Considering we do this, should I put a paragraph in the RDF New document informing people about our thinking on this?

<pfps> +1 to put something in RDF New

<gkellogg> +1

ora: let's record an action for me to do that.

<pchampin> +1 to mention this change in rdf-new if we abandon (or tone down) "abstract syntax"

lisp: I devoted no thought to the consequences of this with respect to other documents.
… attempt to be consistent with the term.
… to be consistent, the title had to change.
… with respect to explanations, considering adding paragraph which could go in this document.

ora: might still be a good idea to put something in RDF New.

<niklasl> +1 I have that action in mind.

ACTION: ora to put a note in RDF-new that "abstract syntax" is now "abstract data model"

<TallTed> we probably will need a consistency check across the other documents

<gb> Created action #176

pfps: Every place we refer to this docuemnt, we say "RDF Concepts".
… bibliography has the full title.
… they will change semi-automatically?

pchampin: they should.

pchampin: once a new draft is published.

ora: we don't touch bibliographies.

pfps: nothing has to be changed for title change.

<pchampin> RDF Semantics contains one occurrence of "RDF abstract syntax" that is not generated and would need to be updated

ora: urge everyone to take a look at what James has done.

lisp: in terms of terminology, it's not a casual change.

pchampin: I found one mention of "RDF Abstract Syntax" not generated by resepc.
… in a number of places, we talk about "concrete syntaxes".
… is it a problem? I don't think it is, but might want to consider.

niklasl: I noticed that, too. Perhaps we might want to keep the abstract syntax in more than once place.
… that will be part of the Note. Not part of this PR.

ora: homework for next week.
… if everyone is happy, James can merge.

<TallTed> maybe replace "concrete syntaxes" with "concrete serializations"?

ora: I think it's OK to talk about concrete syntax. Emphasizes we're talking about textual representations.

<pfps> I'm going to change the "abstract syntax" mention in Semantics, as it really means just parts of an RDF graph.

TallTed: maybe replace "concrete syntaxes" with "concrete serializations"?

gkellogg: it feels backwards to me. serializations formed by serializing something out. syntax is the way you write things that can then be parsed into data model.

TallTed: take abstract data model and serialize it into a concrete serialization.

gkellogg: that's correct. but many ways to serialize a graph that would not be the automatic result of running an automatic serializer.

<niklasl> +1 to gkellogg, I think syntax is relevant here.

ora: understand, but sounds nit-picking to me. to clarify, gkellogg are you saying if I write turlte in emacs, I'm not serializing anythign?

gkellogg: depends on definition of "serialization".

ora: suggest everybody think about this. we can bring this up next week.

ora: other PRs?

gkellogg: n-quads and turtle.

---

[niklasl]

I think this can be a useful change. I propose some adjustments to consistently say "data model", and keeping "abstract syntax" in some more places.

[niklasl]

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).

[lisp]

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.

[niklasl]

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

[lisp]

indeed.
without this

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

you have a discursive description which introduces terminology.

[niklasl]

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

[niklasl]

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>,

[niklasl]

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.

[niklasl]

Suggested change

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

[niklasl]

Suggested change

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

[niklasl]

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.

[niklasl]

Suggested change

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

[niklasl]

Suggested change

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

[niklasl]

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

[TallTed]

Suggested change

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

[lisp]

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

[TallTed]

@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.

[lisp]

i did see the previous suggestion.

[TallTed]

@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.