NamedNode

See

• https://github.com/rdfjs/representation-task-force/issues/50
• https://github.com/rdfjs/representation-task-force/wiki/Meeting-2016-03-11
• https://github.com/rdfjs/representation-task-force/wiki/Meeting-2016-03-18
• https://lists.w3.org/Archives/Public/public-rdfjs/2015Dec/0003.html - typing named nodes/blank nodes/literals

Arguments for NamedNode (instead of IRI)

Pros

• Matches BlankNode notation
• Avoids cognitive overloading of the term -- IRI is an existing standard, with its own spec etc
• NamedNode contains an IRI
• existing specs and libraries: RDF-Interfaces, RDFLib.js, RDF-Ext
• somehow similar naming - owl:NamedIndividual
• if cases exist where a node has one or more IRIs and a value naming it IRI doesn't make sense - aka. smusing (merging) nodes
• if daft changes to use .iri instad of .value IRI.iri looks awkward
• if draft allows non IRI values for IRI, NamedNode can cause less confusion

Cons

• Previous vote decided to go with IRI, so this would be a change/reversal
• Potentially less clear to developers new to RDF (IRI is a known/understandable concept, NamedNode potentially less so. However, this goes for BlankNode as well, and other RDF concepts)
• IRI is shorter
• ruby and python use URI/IRI terminology

Other options

• Python uses URIRef instead of named node or URI. Possibly an alternative option, IRIRef? (talk to Tim, etc)

A usage-based argument for 'IRI'

Summary: We are manipulating a concrete manifestation of a triple, not the conceptual relation the triple represents. Hence, we are dealing with IRIs, not named nodes.

Author: @RubenVerborgh

Guiding: example

dbpedia:Barack_Obama owl:sameAs wikidata:Q76.

Conjecture 1: there exists a one-to-many relationship from named node to IRI

In the above triple, dbpedia:Barack_Obama is an IRI. The named node is the thing this IRI points to. Similarly, wikidata:Q76 is an IRI. The named node is the thing this IRI points to.

In fact, both named nodes are the same thing; they both represent the entity Barack Obama, which happens to be identified with different IRIs here.

Hence, there is a one-to-many relationship from named node to IRI.

Conjecture 2: what we want to refer to are IRIs, not the named nodes

In the implementation model we propose, the "thing" that can be a subject, predicate, or object of a triple has a one-to-one relation to IRI.

Therefore, it is not possible that our "thing" is a named node, because if it were, it would have a one-to-many relation to IRI.

Therefore, what we are manipulating are instead the IRIs themselves. We manipulate one specific identifier of a named node.

We wrap them in an object for convenience (.equals methods etc.), and have the .value part point to the actual string. This is simply because it is not desired to overload the JavaScript String prototype; the thing in our implementation would in fact just be a string (which is all an IRI is).

Conclusion 1: we really want to talk about IRIs

What we are manipulating are IRIs, not named nodes.

I.e., the example triple is represented in memory as S P O., not as S P S..

Conclusion 2: the actual misnomer is "blank node"

The argument that the usage of "blank node" means we should also use "named node" is false: it is in fact the other way round.

Similarly to how named nodes can be identified by multiple IRIs, blank nodes could be identified by multiple labels (some of which could be named!).

Therefore, what we call BlankNode is actually a blank node label, because we only refer to one of the identifiers, not just a single one. I'm not arguing to change the name, just that we should be aware of this. Because saying that the thing should be called NamedNode in analogy to BlankNode is a fallacy if BlankNode itself is a misnomer, which I believe it actually is.