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?

Yes.

> 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.

Best,
Richard



> 
> 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