Re: a quick remark about blank nodes

Nathan, Pat,

Fascinating discussion.

On 3 Mar 2011, at 11:00, Nathan wrote:
> Indeed, I'd suggest this is the core issue, the core problem with blank nodes in the community, is that the community already has the notion of named-g-box, and for blank nodes not be scoped at this level creates unexpected functionality.

Exactly!

> It appears to me, that we can "fix" the issue the community has, in a backwards and forwards compatible way, by having blank node identifiers scoped at g-box level, and g-text level where no g-box is known. This would mean no change in the triple only world views, and fix the main issues in quad/ng world views.

Yes!!! Huge +1.

Incidentally, this is how I have always read RDF Semantics. Everything it says is about how to interpret a single g-snap. In particular, it says which entailments are valid given a single g-snap. For that, it's irrelevant whether any of its nodes (blank or not) also occur in triples in another g-snap.

I guess people like me who learned RDF and named graphs as a package find it quite natural to think of an RDF graph just as the state of a g-box that has a name and hence identity and defines a scope for blank nodes and for entailment.

I often find myself saying things like: “Look, triples don't just float around in space, they occur in a graph, and it's irrelevant if there's an owl:sameAs triple somewhere in some other graph, no one forces you to merge them...” That's not about blank nodes, but it is also about scope of entailments.

I guess there are two items here that could be turned into issues:

1. Scope of blank nodes. If we nail down a definition of g-box, then a single paragraph in RDF Concepts and RDF Semantics that scopes blank nodes to a g-box would go a long way, without any downside that's obvious to me.

2. Blank nodes as existential quantifiers or simple names. Once the scoping issue is solved, it should be possible to explore a simplified RDF Semantics that treats them as simple names, a la SPARQL. This pushes the boundaries of the charter, so it's less clear that this is a good idea.

Best,
Richard


> 
> Best,
> 
> Nathan
> 
>