Definition of "RDF term" (and other terms) should be exported

[pchampin]

Reviewing w3c/rdf-semantics#74, it occurred to me that the defined term "RDF term" is not accessible from outside this document, which is a problem (RDF semantics, and probably other specs, need to reference it).

There are probably other definitions in this spec that need to be exported. I'll try to make a list of them, and a PR.

[afs]

I've been using the form:

   <a data-cite="RDF12-CONCEPTS#dfn-rdf-term">RDF term</a>

and we have a lot of cross-document links already.

I'd like to see the major terminology exported so RDF ideas can be referenced easily. The question is how much of the terminology.

It isn't helpful to export every definition but having major things like "graph", "dataset", "triple", "RDF term" would be good.

[pchampin]

We have a lot of terms that are only defined and used in informative sections. I don't think those need to be exported.
More specifically, all the terms in the list below are used in normative sections, and most of them are defined in normative sections. This is a long list, and we may want to be more selective, but it would make it easier for everyone to be systematic about this.

• concrete RDF syntax → defined in 1.9 (informative) but used in several normative sections
• full conformance
• classic conformance
• rdf string
• rdf graph
• asserted
• rdf triple
• rdf term
• node
• literal
• lexical form
• datatype iri
• language tag
• language
• base direction
• language-tagged string
• directional language-tagged string
• literal value
• literal term equality
• blank node
• blank node identifier → defined in a note, but used in 3.8 (and useful for concrete syntaxes)
• triple term
• subject
• predicate
• object
• rdf dataset
• default graph
• named graph
• graph name
• quad
• datatype
• lexical space
• lexical-to-value mapping
• value space
• RDF-compatible XSD types
• rdf:HTML
• rdf:XMLLiteral
• rdf:JSON

[afs]

systematic

+1!

A quick scan:

node -- used in the general graph sense - maybe not useful to be exported
blank node identifier -- too detailed?
quad -- informal and in a non-normative section - the RDF data model does not have quads.
object -- we have to be careful with this common word!

and property/RDF property isn't in the list.

[csarven]

Preaching to the choir, but "any resource of significance should be given a URI" and described in RDF, especially if the terms are intended to be used unambiguously. URIs should be self-described by the URI owner.

I've mentioned the work on Spec Terms to this WG back in 2022. If the WG is open to expressing the RDF specs using RDF at the source, I'd be happy to volunteer to make this happen. This can be based on either the Respec source or the generated HTML (pre-publication), depending on the group's preference.

---

A bare-bones example URI for the concept "RDF triple" ( https://www.w3.org/TR/rdf12-concepts/#dfn-rdf-term ) would be (formatted for readability):

<div about="#dfn-rdf-triple"
     property="skos:definition" typeof="skos:Concept">

  <p>An <dfn id="dfn-rdf-triple" property="skos:prefLabel">RDF triple</dfn>
    (usually called "<span property="skos:altLabel">triple</span>")
    is a 3-tuple (<var>s</var>, <var>p</var>, <var>o</var>) with the following characteristics:</p>

  <ul>
    <li><var>s</var> is an
      <a href="#dfn-iri" rel="rdfs:seeAlso"><abbr title="Internationalized Resource Identifier">IRI</abbr></a> or a
      <a href="#dfn-blank-node" rel="rdfs:seeAlso">blank node</a>.</li>

    <li><var>p</var> is an
      <a href="#dfn-iri"><abbr title="Internationalized Resource Identifier">IRI</abbr></a>.</li>

    <li><var>o</var> is an
      <a href="#dfn-iri"><abbr title="Internationalized Resource Identifier">IRI</abbr></a>, a
      <a href="#dfn-blank-node">blank node</a>, a
      <a href="#dfn-literal" rel="rdfs:seeAlso">literal</a>, or a
      <a href="#dfn-triple-term" rel="rdfs:seeAlso">triple term</a>.</li>
  </ul>
</div>

in Turtle that'd be (formatted for readability):

<https://www.w3.org/TR/rdf12-concepts/#dfn-rdf-term>
  a skos:Concept ;
  skos:prefLabel "RDF triple"@en ;
  skos:altLabel "triple"@en ;
  skos:definition """An RDF triple (usually called \"triple\")
    is a 3-tuple (s, p, o) with the following characteristics:

    s is an IRI or a blank node.
    p is an IRI.
    o is an IRI, a blank node, a literal, or a triple term."""@en ;
  rdfs:seeAlso <#dfn-blank-node>, <#dfn-iri>, <#dfn-literal>, <#dfn-triple-term> .

---

Why bother or why not? Both are fair questions, aside from the group "eating its own cooking" :)

See also an example graph visualisation of several specs:

https://solidproject.org/TR/?graph=https://solidproject.org/TR/protocol&graph=https://solidproject.org/TR/notifications-protocol&graph=https://solidproject.org/TR/wac&graph=https://solidproject.org/ED/qa

Here are live SPARQL query examples (pulled directly from the specs at the source!) that gather significant resources across the specs, such as requirements, advisements, concepts, citations, requirements and test cases, audience, classes of products, contributors, changelog:

https://lists.w3.org/Archives/Public/public-solid/2024Jun/0002.html
https://lists.w3.org/Archives/Public/public-solid/2024Jun/0007.html
https://lists.w3.org/Archives/Public/public-solid/2024Jun/0011.html

[pchampin]

and property/RDF property isn't in the list.

because it is already exported :)

[pchampin]

@csarven I sympathize with the idea, but I would keep the two things (exporting definitions for respec / annotating definitions with RDFa) in separate PRs... Also, I think the latter could be done more incrementally (and not necessarily before CR).