Re: B-scopes

Richard,

I globally agree with your answer,
except for the "fresh blank node" definition, on which I'm still not convinced.
See below.

On Mon, Nov 19, 2012 at 9:32 PM, Richard Cyganiak <richard@cyganiak.de> wrote:
> Hi Pierre-Antoine,
>
> Updated version, same place:
> http://www.w3.org/2011/rdf-wg/wiki/User:Rcygania2/B-Scopes
>
> Details inline.
>
> On 19 Nov 2012, at 18:32, Pierre-Antoine Champin wrote:
>> * I would put "scope" in bold face when it is first used (in the definition of b-node) rather than in the following paragraph; especially because it gives the impression at first sight that scopes are defined by documents. The following sentence explains that there may be other kinds of scopes, but stil...
>
> I see what you mean. But the bold instance of the word is the anchor where other occurrences of the word link to, and therefore I'd like to keep it in the same paragraph as the rest of the “definition”. So instead of moving the anchor, I tried to add a new initial sentence with a more explicit definition to the paragraph, also in the hope of  appeasing Antoine, who complained about the lack of a proper definition. Result:
>
> [[
> A '''scope''' is the context in which a blank node identifier refers to a particular blank node. The same identifier in a different scope refers to a different blank node. Every RDF document forms its own, self-contained scope. The handling of scopes outside of RDF documents (for example, in RDF stores) is implementation-dependent. Other specifications MAY impose additional scoping rules.
>
> '''Blank node equality''': Two blank nodes are equal if and only if their blank node identifiers are equal and they are in the same scope.
> ]]

ok

>
> I'm not sure that I like this better than the previous version, which simply omitted the first two sentences. It now says pretty much the same in more words, and now relies on the bad C-word: “context”.

I share your suspicion for the C-word in general, but it does not
bother me too much here :)

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

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

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

>
>> * In order to keep a nice "definition" style to the whole, I would
>
> You just ended mid-sentence here, did you

Obviously... sorry about that :-(

>> * At the end of the paragraph about "copying into a scope", I would explicitly state that parsing and serializing are two typical cases of copying a graph into a new scope.
>
> A list of typical cases would be informative, and therefore best kept in a Note. I tweaked one accordingly:
>
> [[
> Note: Blank node identifiers are not required to be globally unique, and therefore may have to be re-allocated when RDF documents are parsed or serialized, or when RDF data otherwise crosses a system boundary. This boundary-crossing is formalized as “copying graphs between blank node scopes”.
> ]]

works for me

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

I have nothing better to propose, though, so I guess I can live with that.

  pa

>
> Best,
> Richard

Received on Monday, 19 November 2012 21:17:15 UTC