"Official stance is Subject can be a Literal"

[multimeric]

Clearly this dilemma is known to the maintainers, but I don't think there is any issue about it yet:

rdflib/rdflib/graph.py

Lines 324 to 328 in 53405b7

	# RDFLib official stance is Subject can be a Literal
	# If this ever changes, this part will be one of the first lines to modify.
	_SubjectType: te.TypeAlias = Union[IdentifiedNode, Literal, Variable]
	_PredicateType: te.TypeAlias = Union[IdentifiedNode, Variable]
	_ObjectType: te.TypeAlias = Union[IdentifiedNode, Literal, Variable]

This is fairly frustrating to work with, as I need to do lots of subclass checking whenever I work with subject triples.

Here is the relevant part of the RDF spec:

An RDF triple consists of three components:
• the subject, which is an IRI or a blank node
• the predicate, which is an IRI
• the object, which is an IRI, a literal or a blank node

[ajnelson-nist]

I can recall having discussed this somewhere among the Issues and PRs, but I can't recall where. What I recall is that there is some historic reason, I think pertaining to a serialization format, that permitted subjects to be Literals.

I also recall a plan was made to specialize Graph into a "RDF 1.1 Graph" class that narrowed Literal out of _SubjectType.

I can't remember that historic reason, unfortunately. It isn't part of RDF 1.0, as the Triples section agrees enough with the RDF 1.1 spec part you quoted.

I'm vaguely remembering it was Notation3 that allowed this, but I don't see the grammar rules at a glance to confirm this or not.

[gjhiggins]

I'm vaguely remembering it was Notation3 that allowed this, but I don't see the grammar rules at a glance to confirm this or not.

Notation3 grammar rules are currently here: https://github.com/w3c/N3/blob/master/grammar/n3.g4.

subject : expression;
expression: path;
path: pathItem ('!' path | '^' path)?;
pathItem : iri | blankNode | quickVar | collection |
           blankNodePropertyList | iriPropertyList |
           literal | formula;

FWIW, the code for the earliest version of RDFLib of which I have the source¹ (0.9 of 2002-06-11) uses the following check:

    def check_subject(self, s):
        if not (isinstance(s, URIRef) or isinstance(s, BNode)):
            raise exception.SubjectTypeError(s)

Which implies that the extension of the scope came later and is intentional - likely support for and integration with SWAP's extensive use of Notation3 as @ajnelson-nist suggested.

In terms of support for Notation3, RDFLib's store must be able to handle (e.g.) Notation3 string-processing rules such as:

{ "asdfghjkl" string:endsWith "jkl" } log:implies { :test1 a :success }.

{ "asdfghjkl" string:endsWith "jkk" } log:implies { :test2 a :FAILURE }.

Necessitating the binding of a Literal as the first node of a triple. I suspect it may be instructive to note that RDFLib's Notation3 parser was cloned from SWAP's notation3.py Python implementation.²

¹ This dates to a couple of months prior to the publication of the W3C's first working draft of Resource Description Framework (RDF): Concepts and Abstract Data Model)

² SWAP's notation3.py, RDFLib's notation3.py - note the common authorship includes some guy called Tim Berners-Lee.