Blank nodes

[dbooth-boston]

They are an important convenience for RDF
authors, but they cause insidious downstream complications.
They have subtle, confusing semantics. (As Nathan Rixham
once aptly put it, a blank node is "a name that is not
a name".) Blank nodes are special second-class citizens
in RDF. They cannot be used as predicates, and they are not
stable identifiers. A blank node label cannot be used in
a follow-up SPARQL query to refer to the same node, which
is justifiably viewed as completely broken by RDF newbies.
Blank nodes also cause duplicate triples (non-lean) when the
same data is loaded more than once, which can easily happen
when data is merged from different sources. And they cause
difficulties with canonicalization.

"A problem we have with blank nodes that might make us banish them is
the impossibility to use them in reified statements."
https://lists.w3.org/Archives/Public/semantic-web/2018Nov/0092.html

IDEA: Allow expressions as first-class entities

"Allowing expressions to be predicate arguments eliminates most cases
where blank nodes are required. In bio-ontologies, we have large numbers
of simple EL expressions that create huge numbers of blank nodes that
complicate SPARQL queries. Similarly, for representing equations like
E=mc^2, it's blank nodes or some kind of awful (from a programmer-pov)
unnecessary IDs."
https://lists.w3.org/Archives/Public/semantic-web/2018Nov/0045.html

IDEA: Separate existential quantifier (blank node) logic from RDF

"I'm starting to believe an idea of separating the existential quantifier
(blank node) logic from RDF itself to a separate semantic extension on
top of RDF should be explored. As evidenced by this discussion it is
difficult to understand and talk about. If separate, it could be
expanded by negation to have the full power of FOL as Pat suggested. If
such separation was possible and made the basic operations (merges,
canonicalization) on RDF data sets easier to reason about and implement,
it would be of quite beneficial."
https://lists.w3.org/Archives/Public/semantic-web/2018Nov/0172.html

IDEA: Add explicit scope mechanism for blank nodes

"Bnodes introduced to encode
structures like n-ary relational assertions, or lists, or some
complicated piece of OWL syntax, should have a very narrow scope
corresponding to the exact boundaries of those structures, and
hence should be ‘invisible’ from outside (which is why it is fine
to make them vanish in a higher-level syntax using [ ] or ( ).) . . . .
imagine a variant of NTriples in which a subset of
triples can be enclosed in brackets, say [ ] (or something else
if these are already taken) to indicate that any bnode ID in a
triple inside the bracket is local to those triples".
https://lists.w3.org/Archives/Public/semantic-web/2018Nov/0218.html

"A better system, which would allow for more elaborate structures, would be to have convention of labelled scope brackets of the form [ID ]"
https://lists.w3.org/Archives/Public/semantic-web/2018Dec/att-0018/00-part
https://lists.w3.org/Archives/Public/semantic-web/2018Dec/0018.html

IDEA: Define equality and hash functions on types

"For a common approach to addresses maybe a group like Schema org could
publish ==() and hash() functions on their
https://schema.org/PostalAddress page, possibly open sourced. In the
interim they could nominate an existing service like
https://smartystreets.com/, which is an address validation API I've just
discovered, there seem to be several. At a later stage they could publish a
fuzzy matching function there too."
https://lists.w3.org/Archives/Public/semantic-web/2018Dec/0001.html

[william-vw]

Personally, I like the idea of having expressions avoid the need for blank nodes. Note that there could be a semantic layer on top of RDF to support such constructs, without needing to adapt the triple-based data model - perhaps this could be tied in with one of the big ideas (?) But that kind of solution would still involve blank nodes behind-the-scenes, of course.

[dbooth-boston]

As more background, TriG currently allows blank node labels to span multiple graphs within the same document: "BlankNodes sharing the same label in differently labeled graph statements are considered to be the same BlankNode."
https://www.w3.org/TR/trig/#terms-blanks-nodes

[afs]

One of the practical difficulties of bnodes is use in structures; RDF lists, use in values for quantity+unit, because this is fragile. Lists can be broken in some way, or values having two units. Checking is "whole graph", not at the level of input stream when feedback is more useful. With guaranteed correct data, systems can store and handle in optimal form.

Scoping to small sections of the document, like () in Turtle is an interesting possibility as it closes the checkpoint.

Something for N-triples is needed as well, but also for Turtle because determining pretty printing is the same as checking and expensive on large data (larger than RAM). A solution which allows streaming the graph out is needed (experience from both Turtle and RDF/XML output - users like pretty but at scale have to accept a reduced form).

[rnavarropiris]

In support of: IDEA: Separate existential quantifier (blank node) logic from RDF

Assuming P<GI<NP, the creation and verification of a digital signature of an arbitrary RDF graph cannot be done in polynomial time.

Carroll, Jeremy J. "Signing RDF graphs." International Semantic Web Conference. Springer, Berlin, Heidelberg, 2003.

RDF needs to be processable in polynomial time, otherwise critical (business) use cases are nearly impossible if 100 % compliance with the RDF spec is expected.

@jeremycarroll: any further insights on this matter?

[dbooth-boston]

I think Aidan Hogan and co-authors have done the most research on blank nodes more recently:

• Aidan Hogan, Marcelo Arenas, Alejandro Mallea and Axel Polleres. "Everything You Always Wanted to Know About Blank Nodes". In the Journal of Web Semantics 27: pp. 42–69, 2014.
• Aidan Hogan. "Canonical Forms for Isomorphic and Equivalent RDF Graphs: Algorithms for Leaning and Labelling Blank Nodes". In ACM Transactions on the Web 11(4): 22:1-22:62, 2017.

I do not know a github handle for Aidan, but I will email him to see if I can get his attention on this. I spoke to him by phone earlier today and he is super busy with teaching right now, but intends to follow up in the next couple of days.

[afs]

There is a risk of "selection bias" . People who like what there is or who are "getting on with stuff" don't write papers for journals!

From https://lists.w3.org/Archives/Public/semantic-web/2018Nov/0170.html

IMO this is a good example that bnodes actually are foremost: structure.

From https://lists.w3.org/Archives/Public/semantic-web/2018Nov/0053.html

> They have subtle, confusing semantics.
I find them very simple, thanks.

[kidehen]

We shouldn't be banning stuff that exists in the existing RDF standard just because a specific programmer or end-user profile struggles with its essence and/or utility.

A Blank Node is how RDF (a Language) delivers the functionality of an Indefinite Pronoun.

[rnavarropiris]

@kidehen

So you are saying that "cannot be done in polynomial time" is a struggle of "a specific programmer or end-user"?

It's not about banning blank nodes, it's about separating them into an on-top layer, so that the core layer can be properly supported & widespread.

Blank nodes should be limited to use cases actually requiring them (e.g. OWL vocabularies) but only as an optional opt-in feature.

RDF is not a language, it is "a framework for representing information in the Web", so I'm not sure of the necessity of indefinite pronouns at is core. It would be helpful for the discussion if you could elaborate on that.

[kidehen]

@rnavarropiris ,

So you are saying that "cannot be done in polynomial time" is a struggle of "a specific programmer or end-user"?

That wasn't the point of anything I said.

Blank nodes should be limited to use cases actually requiring them (e.g. OWL vocabularies) but only as an optional opt-in feature.

I don't know how I or anyone else has indicated otherwise re. blank nodes i.e., they are supposed to be used when required. Use them where a pronoun would be applied in a structured sentence.

RDF is not a language, it is "a framework for representing information in the Web", so I'm not sure of the necessity of indefinite pronouns at is core. It would be helpful for the discussion if you could elaborate on that.

RDF is an Abstract Language.

You can create RDF sentences using a variety of notations and serialize for persistent storage to a variety of document types.

RDF has nothing to do with the Web in its most basic sense i.e., it is a framework that makes systematic use of signs, syntax, and semantics for encoding and decoding information.

The subject, predicate, and object roles of an RDF sentence are basically a rendition of "parts of speech" in natural language.

An HTTP-based Web comes into play when you apply Linked Data principles to RDF sentence construction, along the following lines:

1. Identify things using HTTP URIs
2. Describe things using subject, predicate, and object structured sentences where the subject, predicate, and object (optionally) are identified using an HTTP URI

Related

• Simple Linked Data Tutorial -- that demonstrates the relationship between RDF (the Language) and the notion of a Semantic Web
• Linguistics and RDF
• Natural Language & Data
• Examples demonstrating the importance of Blank Nodes based on RDF renditions of Conceptual Graph Examples -- from various John F. Sowa examples (I craft these every time he presents a puzzle)

[HughGlaser]

Notwithstanding a lot of this comment, I want to pick up on one part:

Blank nodes should be limited to use cases actually requiring them (e.g. OWL vocabularies) but only as an optional opt-in feature.

I don't know how I or anyone else has indicated otherwise re. blank nodes i.e., they are supposed to be used when required. Use them where a pronoun would be applied in a structured sentence.

I want to challenge the final sentence of this strongly.
We might use "this", "that", "it", "she" etc. as pronouns extensively.
It is deeply unhelpful if, when representing the same knowledge in RDF, we choose to use blank nodes.
For me, the big thing about RDF is that it can have globally useful IDs, so I and others can make statements about resources.
It (sic) is the same reason we have nouns in natural languages. But in RDF you can't point at things with your finger, or easily use a pronoun that is understood to refer to an earlier ID (although context might help).
You say "they are supposed to be used when required" - that is fine - I think the problem is that we (that is all of us!) may not agree on the requirements.
My requirement says they should (only) be used in a context where I can't easily or even when I can't logically specify a well-founded ID.

[kidehen]

@HughGlaser ,

I want to challenge the final sentence of this strongly.
We might use "this", "that", "it", "she" etc. as pronouns extensively.
It is deeply unhelpful if, when representing the same knowledge in RDF, we choose to use blank nodes.

To be crystal clear on this matter, regarding my fundamental point:
I am simply stating that Blank Nodes should be used where the RDF content creator deems appropriate. Basically, it shouldn't be removed from the existing standard.

A Blank Node brings Indefinite Pronoun functionality (and power) to RDF sentence construction.

I've [provided examples] (http://kingsley.idehen.net/public_home/kidehen/Public/Linked%20Data%20Documents/Tutorials/conceptual-graphs-to-turtle-examples/), as I always do.

  <> 
  a schema:CreativeWork, schema:WebPage ;
  schema:description "Translating Conceptual Graph Notation: [Black]<-(Attr)<-[Cat: Yojo]->(On)->[Mat]->(Attr)->[Red] to RDF-Turtle" ;
  schema:about 
  
  [ a <#Cat> ; 
    schema:name "Yojo" ;
	schema:identifier <#thisYojo> ;
	schema:image <https://thumb1.shutterstock.com/display_pic_with_logo/3291197/497469223/stock-vector-black-cat-lying-on-the-red-mat-497469223.jpg> ;
	schema:color [ <#rgbCode> "#000000"^^xsd:hexBinary ;
	           schema:name "Black"
			 ] ;
	<#on> [
		   a <http://www.productontology.org/id/Mat> ;
		   schema:identifier <#thisMat> ;
	       schema:color [ <#rgbCode> "#FF0000"^^xsd:hexBinary ;
		              schema:name "Red"
					]
		  ] 
  ] .
  
 <#on>
 a owl:ObjectProperty ;
 schema:name "on" ;
 schema:description "two perceived items in vertical juxtapostion." ;
 rdfs:domain owl:Thing ; 
 rdfs:range owl:Thing . 

I hope I've clarified my position which simply boils down to leave RDF as is based on its ability to deal with complex "horses for courses" matters regarding structured data representation. Prematurely deprecating existing functionality on the basis of style or the usual "make it simpler" subjective argument aren't recommended.

Related

• Yojo the Cat example
• Conceptual Graphs by John F. Sowa

[HughGlaser]

@kidehen

Yeah, I'm pretty sure we have a strong agreement on a lot of this.
(Sorry, I should have been clearer on that in my post.)

I see no need to actually change RDF.
What I would like to see is an evolution of the way RDF is used.

I accept that there is stuff that some people want to say that needs existential quantification.
This is what I meant when I said to use them "when I can't logically specify a well-founded ID".
In my case, I never have the need to do that - that's of course because of the sort of systems we build. Which is because I am working with facts, not knowledge.
And my observation is that the developers that @dbooth-boston is talking about are unlikely to want that, even if they understand the nuances of it.
I think that what we want is RDF as the go-to for representing facts - it is already a possibility for KR stuff, but KR developers are not the middle 33% of developers (are they even 3%?).

So I want to see the use of blank nodes discouraged, rather than where they are used as what often seems the go-to answer to not being bothered to actually say what you want in the RDF.

Mind you, for your example, I don't see which of the blank nodes you have could not have an ID.
It may be that there was some RDF that you used to construct the above RDF, but the RDF you give is exactly the situation where I would discourage the use of blank nodes.
Because:
a) I can't really add to the knowledge - how would I say that the cat is Siamese, for example, or the mat is made of cotton.
b) I can't "disagree", and say that the mat looks grey to me.
And you as publisher can't do that in the future either, so it really doesn't make for a very maintainable bit of knowledge.
Best

[draggett]

On 19 Dec 2018, at 15:46, Hugh Glaser ***@***.***> wrote: We might use "this", "that", "it", "she" etc. as pronouns extensively. It is deeply unhelpful if, when representing the same knowledge in RDF, we choose to use blank nodes.

In natural language, we have some words with a widely agreed meaning - these are words you can look up in a dictionary. We also have names that can only be resolved in context, e.g. my friends know me as Dave, but there are lots of other people called Dave. In yet other cases you are given a description rather than a name, e.g. the third door on the left. RDF should allow for the same flexibility. Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett W3C Data Activity Lead & W3C champion for the Web of things