Re: B-scopes

On 19 Nov 2012, at 21:16, Pierre-Antoine Champin wrote:
>>> * I would rephrase the definition of "fresh" as follows
>>> [[In a given scope, a **fresh blank node** is a blank node with a blank node identifier that is new and unique within that scope.]]
>> So you define “freshness” with respect to a particular scope, rather than just requiring the node to be new in “some scope”.
> Well, to be fresh, a blank node has to have an indentifier new and
> unique *in the scope* where you add it, right?


> As I read your definition, it can be called fresh even if it is
> currently used in the scope in which I intend to add it,
> as long as it is new and unique *in some scope* in the universe (which
> is trivially always true).

Well, fine. So s/some/its/

A fresh blank node is a blank node with a blank node identifier that is new and unique within its scope.

That should make clear enough that the blank node is expected to be in the scope where the identifier is new.

>> I prefer the current version because 1) there's existing use of the phrase “fresh blank node” out there that doesn't make reference to a particular scope;
> I would argue that they do refer to a particular scope, even if implicitly.

I would argue that they do implicitly refer to some scope, but not to a particular one.

>> and 2) sometimes it can be useful to simply require that a blank node be “fresh”, without requiring a particular scope (Example: ":a :b :c." entails ":a :b _:x.". This is true if _:x is fresh, whatever the scope).
> It was fresh in the scope of your 1st character string. And it's not
> fresh anymore in the scope of your 2nd one,
> so it is definitely not fresh "whatever the scope".

I didn't say that _:x is fresh "whatever the scope". I said that the entailment is true whatever the scope of _:x, as long as _:x is fresh.

>>> * I would move the definition of **merge** inside the note, as it is not so much a definition than a logical consequence of the definition of "copying into a scope"
>> I'd prefer to keep it as a normative definition that establishes a technical term that can be used elsewhere.
> Fair enough. My concern is that, at that point, I was wondering: "why
> are we defining a list of graph operations in a section dedicated to
> blank nodes?...". Reading it again, I understood how "copying into
> scope" fit in the picture, but "merge" still seemed farfetched.

Fair enough. The merge definition may end up in the subsection that defines graph isomorphism. That's a question perhaps best answered when ISSUE-106 (Concepts/Semantics relationship) and ISSUE-111 (dataset operations) are clearer, which will probably be sometime after the next WD.


> I have nothing better to propose, though, so I guess I can live with that.
>  pa
>> Best,
>> Richard

Received on Tuesday, 20 November 2012 10:11:44 UTC