Add canonical Turtle for RDF-recognized XSD datatypes (`ns/rdf-xsd.ttl`) #64

domel · 2025-09-08T15:46:29Z

This PR adds ns/rdf-xsd.ttl, an informational, machine-readable Turtle file that declares the XML Schema datatypes which RDF gives special recognition (per RDF Concepts). The goal is to provide a canonical source for tools and datasets that today rely on ad-hoc “xsd vocabularies”.

A new file: ns/rdf-xsd.ttl with:

An owl:Ontology header (title, date, short description).
For each included XSD datatype:
a rdfs:Datatype
rdfs:isDefinedBy <http://www.w3.org/2001/XMLSchema#>
rdfs:label (human-readable name)
A brief informative comment describing value/lexical space.

A small number of RDFS subclass statements that reflect well-known XSD 1.1 derivation relationships, e.g.:
xsd:integer rdfs:subClassOf xsd:decimal

Numeric tower: byte ⊑ short ⊑ int ⊑ long ⊑ integer ⊑ decimal
Unsigned chain and bounds: unsignedByte ⊑ unsignedShort ⊑ unsignedInt ⊑ unsignedLong ⊑ nonNegativeInteger
Sign-restricted chains: positiveInteger ⊑ nonNegativeInteger, negativeInteger ⊑ nonPositiveInteger
String tokenization chain: normalizedString ⊑ string, token ⊑ normalizedString, language ⊑ token, Name ⊑ token, NCName ⊑ Name, NMTOKEN ⊑ token
Temporal/duration refinements: dateTimeStamp ⊑ dateTime, yearMonthDuration ⊑ duration, dayTimeDuration ⊑ duration

Datatypes covered:
string, boolean, decimal, integer, double, float, date, time, dateTime, dateTimeStamp, gYear, gMonth, gDay, gYearMonth, gMonthDay, duration, yearMonthDuration, dayTimeDuration, byte, short, int, long, unsignedByte, unsignedShort, unsignedInt, unsignedLong, positiveInteger, nonNegativeInteger, negativeInteger, nonPositiveInteger, hexBinary, base64Binary, anyURI, language, normalizedString, token, NMTOKEN, Name, NCName.

Facets covered:
length, minLength, maxLength, pattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minExclusive, minInclusive, totalDigits, fractionDigits, Assertions, explicitTimezone.

domel · 2025-09-08T16:00:11Z

At this stage, the repository contains rdf-xsd.ttl as a minimum plan, i.e., only the canonical list of datatypes, a few subclass relationships, labels, and brief comments.

I have two open questions for the group before moving further:

Constraining facets as RDF properties?
Should we include the constraining facets defined in XSD 1.1 Datatypes (e.g., xsd:maxInclusive, xsd:minExclusive, etc.) as rdf:Property declarations in the Turtle file?
Example:
```
xsd:maxInclusive a rdf:Property ;
    rdfs:label "max inclusive" ;
    rdfs:comment "The inclusive upper bound of an ordered datatype." .
```

Use of facets for datatype restrictions?
If we do declare these facets, should we also apply them to model the restricted datatypes directly in Turtle using owl:onDatatype + owl:withRestrictions?
Example:

 xsd:int a rdfs:Datatype ;
     rdfs:label "int" ;
     owl:onDatatype xsd:long ;
     rdfs:subClassOf rdfs:Datatype ;
     owl:withRestrictions (
         [ xsd:maxInclusive 2147483647 ]
         [ xsd:minInclusive -2147483648 ]
     ) .

Feedback on whether this is in scope for rdf-xsd.ttl would be very helpful before proceeding.

niklasl · 2025-09-08T16:29:01Z

I think this looks very good!

I would also support adding the constraint properties themselves. I cannot argue for defining OWL restrictions on these as in-scope for the WG though (but if straightforward, I would not object to it as a courtesy). Could a maintenance group add this later on if asked for?

domel · 2025-09-09T11:40:38Z

Now the Turtle file has facets.

TallTed · 2025-09-12T20:58:31Z

Please confirm that I've inferred correctly, that ⊑ means rdfs:subClassOf?

I think it's worth including this — or the correct meaning of that ⊑ symbol — before the Numeric tower and subsequent bullet points. And maybe adding ⊑ decimal to the current tower.

domel · 2025-09-13T08:34:50Z

@TallTed Yes, ⊑ is intended to denote rdfs:subClassOf. Thanks for pointing this out. I agree it would be good to clarify this explicitly before the numeric tower.

As for the numeric tower itself, both xsd:decimal and xsd:integer are already included correctly in rdf-xsd.ttl. The PR description may have been a bit imprecise. I will update it to avoid confusion.

afs · 2025-09-13T11:28:57Z

Numeric tower: byte ⊑ short ⊑ int ⊑ long ⊑ integer ⊑ decimal

XSD calls the relationship "derived" types.

TallTed

I've not closely read the whole PR. Some of the suggestions here are more questions, and may impact multiple lines on which I've not specifically commented. Another review is likely, after these are acted upon.

ns/rdf-xsd.ttl

afs · 2025-09-17T21:45:31Z

ns/rdf-xsd.ttl

+  rdfs:label "NCName" ;
+  rdfs:comment "XML 'non-colonized' names matching the NCName production (i.e., Name without the colon). Derived from xsd:Name." .
+
+xsd:length a rdf:Property ;


Constraining facets as RDF properties?

I would say these over complicate this file as are not needed.

Properties are an RDF feature; isn't the URI xsd:length etc minting URIs in someone else's namespace?

RDF Concepts does not mention facets.

owl:onDatatype + owl:withRestrictions?

Too much OWL for this base RDF file.

This seems to be SHACL!

I would say these over complicate this file as are not needed.

Questionably "not needed". We cannot assume that future readers have any foundation that we have not built for them!

Then you agree with my point! (NB in referring to "Constraining facets as RDF properties?")

Facets are not mentioned as part of RDF Datatypes. They are an XML Schema way to derive datatypes.

We cannot assume that future readers have any foundation that we have not built for them!

We build on other standards. "Future readers" are not coming with zero-context to this file. This file is exact details - the reader is mostly likely someone - or a machine - that wants exact details to add to their knowledge.

I agree with the others in this thread that facets can indeed be useful. In practice, they are often employed together with OWL when defining constraints. At the moment this is something of a grey area, and including them would close that gap. And of course, I always prefer the “better more than less” approach, if someone does not want to use them, they can simply ignore them.

We cannot assume that future readers have any foundation that we have not built for them!

We build on other standards. "Future readers" are not coming with zero-context to this file.

Foundation building can certainly include pointers to existing standards upon which we build our standards — but we cannot assume that future readers have already found such existing standards, and so omit our pointers!

(I think we're in agreement, even if we're not quite communicating what we've agreed.)

ns/rdf-xsd.ttl

afs · 2025-09-28T15:47:11Z

Suggestion: split this into two PRs, for the datatypes definitions, so that can proceed; and for the facets.

would close that gap [with OWL].

The introduction of facet vocabulary only happened in this PR. Facets deserves an issue and WG discussion because it is a new feature. It also would presumably need tests, leading to an implementation report, and clarity about the relationship with OWL (i.e. text in RDF Schema).

Do they form part of D-entailment?
What about SPARQL?

if someone does not want to use them, they can simply ignore them.

I don't see it like that. It is the nature of these namespace documents that it is very hard to remove defined terms. Therefore, we should be sure that the terms are the right ones, with the right definitions.

domel · 2025-09-28T22:22:51Z

I’m in favor of splitting this into two PRs: one that contains only the XSD datatype definitions (so that work can proceed now), and a second, focused PR for facets. If @niklasl agrees, we can do exactly that.

D-entailment. Facets would not be part of D-entailment. RDF 1.2’s D-entailment hinges on recognized datatypes; facets are an XML Schema mechanism for deriving datatypes and should remain outside RDF’s entailment regime unless the WG explicitly decides otherwise. Any facet vocabulary we add should therefore be clearly marked as informative with no normative semantic consequences for RDF entailment.

SPARQL. Likewise, there is no effect on SPARQL semantics. SPARQL does not treat facets as built-in operators or properties; tools might reference such IRIs for documentation or code generation, but there would be no change to SPARQL evaluation or algebra.

Why a (non-normative) facet vocabulary still helps. My working assumption, shared, I believe, with @niklasl in earlier exchanges, is that facets appear in predicate position in RDF graphs (e.g., within OWL 2 datatype restrictions) and are therefore reasonably modeled as rdf:Property for documentation and discoverability purposes. In practice, people already use them this way; see, for example, this discussion: #64 (comment)

afs · 2025-09-29T16:47:21Z

Why a (non-normative) facet vocabulary still helps.

I would have thought this file was normative.

ektrah · 2025-09-29T17:26:21Z

If IRIs of the form http://www.w3.org/2001/XMLSchema#xxx must first have their semantics defined for use in RDF, another option would be to maintain them in a registry like the rdf: and rdfs: vocabularies. This would allow even other specifications to "unlock" xsd: terms for use in RDF by adding them to registry. The rdf-xsd.ttl file would simply be the machine-readable version of the registry.

domel · 2025-09-29T19:06:46Z

@ektrah https://w3c.github.io/rdf-schema/spec/#ch_datatypes
https://w3c.github.io/rdf-concepts/spec/#xsd-datatypes

domel · 2025-09-29T19:16:26Z

Why a (non-normative) facet vocabulary still helps.

I would have though this file was normative.

I would very much prefer this file to be normative. However, if we are unable to reach a clear shared position in the near term, a non-normative facet vocabulary is still a meaningful improvement over the status quo: it gives implementers and content authors a stable reference while we continue the discussion. Non-normative status need not be permanent; we can iterate with issues, tests, and implementations, and once consensus emerges, promote it to normative in a subsequent revision. In short, normative is ideal; if that’s not yet achievable, publishing a non-normative vocabulary is better than publishing nothing.

TallTed · 2025-09-29T19:24:25Z

ns/rdf-xsd.ttl

+  rdfs:isDefinedBy <https://www.w3.org/TR/xmlschema11-2/#date> ;
  rdfs:label "date" ;
-  rdfs:comment "Calendar dates as top-open day intervals. Lexical form: YYYY-MM-DD with optional timezone." .
+  rdfs:comment "Calendar dates as top-open day intervals. Lexical form: YYYY-MM-DD with optional timezone. Timezone lexical forms: 'Z' or an offset of the form ±hh:mm with 00 ≤ mm ≤ 59 and |offset| ≤ 14:00 (e.g., '2025-09-27Z', '2025-09-27+02:00')." .


Is there any default treatment of dates that omit the timezone?

Is there a reason behind omitting such a date in the examples?

I don't understand, in the old and new files, there is the same fragment rdfs:comment "Calendar dates as top-open day intervals. Lexical form: YYYY-MM-DD with optional timezone. Timezone lexical forms: 'Z' or an offset of the form ±hh:mm with 00 ≤ mm ≤ 59 and |offset| ≤ 14:00 (e.g., '2025-09-27Z', '2025-09-27+02:00')." .

TallTed · 2025-09-29T19:26:21Z

ns/rdf-xsd.ttl

+xsd:time a rdfs:Datatype ;
+  rdfs:isDefinedBy <https://www.w3.org/TR/xmlschema11-2/#time> ;
+  rdfs:label "time" ;
+  rdfs:comment "Times that recur each day or occur on some day. Lexical form: hh:mm:ss(.s+)? with optional timezone. Timezone lexical forms: 'Z' or ±hh:mm with |offset| ≤ 14:00 (e.g., '23:59:59Z', '08:15:30.5-05:00')." .


Is there any default treatment of times that omit the timezone?

Is there a reason behind omitting such a time in the examples?

TallTed · 2025-09-29T19:26:53Z

ns/rdf-xsd.ttl

+xsd:dateTime a rdfs:Datatype ;
+  rdfs:isDefinedBy <https://www.w3.org/TR/xmlschema11-2/#dateTime> ;
+  rdfs:label "dateTime" ;
+  rdfs:comment "Instants of time, optionally with timezone. Lexical form: YYYY-MM-DDThh:mm:ss(.s+)? with optional timezone. Values with different explicit offsets can be equal as instants. Timezone lexical forms: 'Z' or ±hh:mm with |offset| ≤ 14:00 (e.g., '2025-09-27T14:03:00+02:00')." .


Is there any default treatment of datetimes that omit the timezone?

Is there a reason behind omitting such a datetime in the examples?

TallTed · 2025-09-29T19:29:19Z

ns/rdf-xsd.ttl

+xsd:double a rdfs:Datatype ;
+  rdfs:isDefinedBy <https://www.w3.org/TR/xmlschema11-2/#double> ;
+  rdfs:label "double" ;
+  rdfs:comment "IEEE 754 64-bit floating-point. Lexical forms use decimal or scientific notation with optional leading sign and exponent; special tokens 'INF', '+INF', '-INF', and 'NaN' are permitted; '+0' and '-0' are distinct lexical forms. Mapping from lexical forms to values is specific to this datatype and its precision. Lexical form (regex-style): (\\+|-)?([0-9]+(\\.[0-9]*)?|\\.[0-9]+)([Ee](\\+|-)?[0-9]+)? |(\\+|-)?INF|NaN." .


I cannot mentally process this regex for the lexical form. Can we provide an informative more human-friendly version, leaving the regex to be the normative version? (and same for similar datatypes?)

The regex comes from the XSD 1.1 Dataset spec. I'm not sure if it's possible to capture all the nuances in an informal description.

TallTed · 2025-09-29T19:30:44Z

ns/rdf-xsd.ttl

+  rdfs:subClassOf xsd:dateTime ;
+  rdfs:isDefinedBy <https://www.w3.org/TR/xmlschema11-2/#dateTimeStamp> ;
+  rdfs:label "dateTimeStamp" ;
+  rdfs:comment "dateTime with a required explicit timezone offset. Lexical form: YYYY-MM-DDThh:mm:ss(.s+)?(Z|±hh:mm); the timezone offset is mandatory." .


Is there a reason behind the omission of examples here and following (and earlier, if I failed to notice some were missing)?

Consistency

domel · 2025-10-03T11:16:36Z

OK. I (temporarily) removed facets. I think we are ready to merge. @TallTed, can you remove the blocking?

TallTed

I think the only way to remove the block is to Approve, but please note that I have not carefully reviewed the changes.

domel · 2025-10-03T20:52:38Z

Understood, thanks for flagging. To unblock progress, I propose we approve this PR now with the explicit caveat that the review was not exhaustive. We can then follow up with a series of smaller, focused PRs that will be easier to review and track.

afs · 2025-10-06T08:21:11Z

I think the only way to remove the block is to Approve

You should be able to re-request a review. This sets it to "awaiting" (the orange dot).

pfps · 2025-10-09T16:52:45Z

A small number of RDFS subclass axioms that reflect well-known XSD 1.1 derivation relationships, e.g.:
xsd:integer rdfs:subClassOf xsd:decimal

These are not RDFS axioms, i.e., they are not RDFS-entailed from the empty graph. I don't believe that there is any indication in the file nor in any WG document that they are axioms, but the claim above needs to be removed.

niklasl · 2025-10-09T17:09:24Z

A small number of RDFS subclass axioms that reflect well-known XSD 1.1 derivation relationships, e.g.:
xsd:integer rdfs:subClassOf xsd:decimal

These are not RDFS axioms, i.e., they are not RDFS-entailed from the empty graph. I don't believe that there is any indication in the file nor in any WG document that they are axioms, but the claim above needs to be removed.

@pfps That's true. By remove the claim, do you mean edit the description in this PR? Or is it enough that we agree here in the comment section?

niklasl · 2025-10-09T17:15:01Z

Also, I'm not sure how to go from recognizing these to "import" (owl:imports) this resource. Ideally an RDF serialization of this document would be served when negotiating on http://www.w3.org/2001/XMLSchema#, but that may be administratively unrealistic. For that reason, I would like for it (which I presume can end up under http://www.w3.org/ns/rdf-xsd) to be linked to from http://www.w3.org/2000/01/rdf-schema# using rdfs:seeAlso—so tools can at least "follow the 'scent' with their noses".

pfps · 2025-10-09T17:46:18Z

I think that the "axiom" bit should be scrubbed from the description, or at least modified.

domel added 2 commits September 8, 2025 17:37

add rdf-xsd.ttl to ns dir

af50c90

wrong prefix

6615b48

domel requested review from afs, gkellogg and niklasl September 8, 2025 16:00

add facets as properties

8c12b1b

domel marked this pull request as ready for review September 9, 2025 11:40

TallTed suggested changes Sep 17, 2025

View reviewed changes

afs reviewed Sep 17, 2025

View reviewed changes

ns/rdf-xsd.ttl Outdated Show resolved Hide resolved

afs reviewed Sep 20, 2025

View reviewed changes

ns/rdf-xsd.ttl Outdated Show resolved Hide resolved

pfps mentioned this pull request Sep 25, 2025

Updated RDFS vocabularies for RDF 1.2 w3c/rdf-concepts#119

Closed

clarifying some rdfs:comment

b8a7753

domel requested review from TallTed and afs September 27, 2025 12:30

afs reviewed Sep 28, 2025

View reviewed changes

ns/rdf-xsd.ttl Outdated Show resolved Hide resolved

isDefinedBy edited/added

bc5cf6c

domel requested a review from afs September 28, 2025 15:32

TallTed reviewed Sep 29, 2025

View reviewed changes

remove facets

49346a2

TallTed approved these changes Oct 3, 2025

View reviewed changes

afs removed the request for review from gkellogg October 6, 2025 08:24

afs approved these changes Oct 6, 2025

View reviewed changes

domel requested a review from TallTed October 6, 2025 11:44

domel merged commit 15ac8d0 into main Oct 6, 2025
1 check passed

domel mentioned this pull request Oct 9, 2025

Declare XSD 1.1 facets as rdf:Property and annotate them #66

Open

4 tasks

Add canonical Turtle for RDF-recognized XSD datatypes (ns/rdf-xsd.ttl) #64

Add canonical Turtle for RDF-recognized XSD datatypes (ns/rdf-xsd.ttl) #64

Uh oh!

Conversation

domel commented Sep 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

domel commented Sep 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

niklasl commented Sep 8, 2025

Uh oh!

domel commented Sep 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TallTed commented Sep 12, 2025

Uh oh!

domel commented Sep 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

afs commented Sep 13, 2025

Uh oh!

TallTed left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

afs Sep 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

afs commented Sep 28, 2025

Uh oh!

domel commented Sep 28, 2025

Uh oh!

afs commented Sep 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ektrah commented Sep 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

domel commented Sep 29, 2025

Uh oh!

domel commented Sep 29, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

domel commented Oct 3, 2025

Uh oh!

TallTed left a comment

Choose a reason for hiding this comment

Add canonical Turtle for RDF-recognized XSD datatypes (`ns/rdf-xsd.ttl`) #64

Add canonical Turtle for RDF-recognized XSD datatypes (`ns/rdf-xsd.ttl`) #64

domel commented Sep 8, 2025 •

edited

Loading

domel commented Sep 8, 2025 •

edited

Loading

domel commented Sep 9, 2025 •

edited

Loading

domel commented Sep 13, 2025 •

edited

Loading

afs Sep 17, 2025 •

edited

Loading

afs commented Sep 29, 2025 •

edited

Loading

ektrah commented Sep 29, 2025 •

edited

Loading