The original presentation is available at https://www.gordondunsire.com/pubs/pres/DeeperDiveNomen.pptx; it doesn't have any of the PDF conversion glitches and is easier to read.
Slide 4 shows that the same string used as an appellation of two different entities constitutes two distinct RDF statements which must be reified with distinct IRIs. This comes from the IFLA Library Reference Model (LRM) which incorporates the earlier model for authority data (Functional Requirements for Authority Data, or FRAD).
The rest of the presentation shows that it is only necessary to reify an appellation statement if something needs to be said about the statement, such as a reference source that justifies the statement or a source authority file or scheme. Reification is also necessary if something needs to be said about the nomen string, such as its context of use; the string itself cannot be used as the subject of an RDF statement.
If nothing needs to be said about the appellation statement or its nomen string, reification can be avoided by using only the nomen string as the object of an appellation statement.
This results in a standard RDA/LRM appellation statement of the form <entityA has appellation "nomen string">. It is a collapse of the graph <nomen1 has nomen string "nomen string"; is appellation of entityA>.
RDA accommodates the semantics by declaring canonical, datatype, and object versions of its element sets. The canonical property "has appellation" has no declared range, so either a nomen string or a reified nomen is acceptable as the object of an appellation statement. The datatype property expects a string, specifically a nomen string; the object property expects a nomen IRI.
Your example is a little confusing. In RDA/RDF turtle:
Graph 1:
library:A60 rdaad:P50291 "Tolstoy"@en . // "has surname" datatype; nomen string object/value; => (domain) library:A60 is a Person
Graph 2:
library:A60 rdaao:P50291 library:N1234 . // "has surname" object; nomen IRI object/value; => library:A60 (domain) is a Person; => (inverse) library:N1234 rdano:P80176 library:A60
library:N1234 rdand:P80068 "Tolstoy"@en; // "has nomen string" datatype, string object/value; => (domain) library:N1234 is a Nomen
rdano:P80176 library:A60 . // "is surname of" object, person IRI object/value; => (range) library:A60 is a person
Graph 1 is a collapse of Graph 2; Graph 2 is an expansion of Graph 1.
Graph 2 is only required if you want to, say, record the scheme which assigns the surname string to the person; for example
library:N1234 rdand:P80069 "Name authority file" . // "has scheme of nomen"
There are a couple of interesting additional points about the example:
The RDA property "has surname" is a pre-LRM, original Toolkit element. It reflects a Western focus that originated in the Anglo-American Cataloguing Rules; it does not reflect the international focus of the official Toolkit, but is retained in the Toolkit to assist local and legacy practices in moving forward.
The assignment of a language tag or attribute to a nomen string is currently under discussion by the BCM Review Group which maintains the LRM. However, it has been agreed for some years now that nomen strings for persons do not have a language attribute. In the example, "Tolstoy" is better treated as being derived from the original Cyrillic script using a specific transliteration system, rather than as a "translation" into English. Best of all is to base name values on the forms that appear in manifestation statements of responsibility and other sources, and natively, if not naively, bring the variants together as nomens and nomen strings of the same author/subject person. See the VIAF entry for "Tolstoy, Leo, graf, 1828-1910" for this and further issues, such as the treatment of patronyms.
RDA eschews the use of blank nodes. The element sets and associated instructions and guidance follow best practices for linked open data and assume that the "unit of metadata" is the atomic "subject-property-object" RDF statement from which more complex description sets can be assembled. Best use of the Toolkit and the guarantee of predetermined levels of interoperability between different local bibliographic agencies are impaired by blank nodes. For example, a blank node will typically be replaced by a locally-minted IRI when ingested into a triple-store or processed by a semantic metadata application. These local IRIs must then be mapped to achieve global interoperability, which is somewhat burdensome, etc. This is the basis of the reference to BIBFRAME within the presentation.
I hope this is useful :-)
------------------------------
Gordon Dunsire
------------------------------