Refactor prefix names

[pchampin]

It would be nice if, when I edit the prefix in a PREFIX clause, all pnames in the query were updated accordingly...

[wouterbeek]

@pchampin this is a nice idea! I have a question though as to what should happen in scenario's such as these:

1. The user adds <https://a/x> inside a where clause.
2. The user defines IRI prefix https://a/ with alias a.
3. The IRI in the where clause (step 1) automatically changes to a:x.
4. The user changes the IRI prefix associated with the alias a to https://b/.

What should happen to a:x after step 4? Should it now abbreviate a different IRI (i.e., https://b/x), or should it be automatically replaced with https://a/x?

[pchampin]

Actually, what you describe is quite different from what I had in mind, but it is a nice idea too :-)

My request was about changing the prefix in the PREFIX clause. Consider the following query:

PREFIX a: <http://example.org/ns/>
SELECT * {
  ?x a a:Foo ; a:bar "baz" .
}

If I change the first line to:

PREFIX b: <http://example.org/ns/>

then the third line would automatically become

  ?x a b:Foo ; b:bar "baz" .

Changing the iri in the PREFIX clause is much trickier, as indeed the intent of the user is harder to decide. I would not automate anything in this case.

Transforming IRIs into PNAMEs, when a matching PREFIX clause is added, does sound like a nice feature, though.

[wouterbeek]

@pchampin Thanks for clarifying! I indeed mixed up the alias prefix (a) with the IRI prefix it abbreviates (http://example.org/ns/).

The problem with your suggestion is that it is irreversible in some cases. Specifically, if an alias prefix is renamed into another alias prefix (legal in SPARQL), then undoing this change to the prefix declaration will not undo the change to the rest of the query.

In the following example, renaming alias a to b actually changes the where clause, because a:x changes to b:x. Because there are now multiple prefix declarations for b, the last one is used, effectively changing the content of the where clause.

prefix a: <https://a/>
prefix b: <https://b/>
select * { a:x ?p b:x }

[pchampin]

Nicely spotted. You are right, this automation can be destructive in that case... :-/ That being said, YASGUI has an 'undo' operation, so I would not consider this as too bad. Plus, changing a: to b: in this particular example is rather pathological. There is no much point in preventing people from shooting themselves in the foot when they are trying that hard ;-)

[wouterbeek]

@pchampin I agree that the example I gave fits well within the shooting-yourself-in-the-foot range :-)

Notice that undoing the change that I describe in my example cannot be undone (that's the irreversible part). After the change the query looks like this:

prefix b: <https://a/>
prefix b: <https://b/>
select * { b:x ?p b:x }

If you now change the first b back to a the where clause cannot be mapped back to its original.

[pchampin]

I'm assuming that, to have a functional 'undo', Yasgui is storing the successive states of the textarea. Otherwise, other operations would be irreversible, e.g. 'select all' followed by 'delete'... So undo should work in that case as well, shouldn't it?

On 15 March 2017 at 20:18, Wouter Beek notifications@github.com wrote:

@pchampin https://github.com/pchampin I agree that the example I gave fits well within the shooting-yourself-in-the-foot range :-)

Notice that undoing the change that I describe in my example cannot be undone (that's the irreversible part). After the change the query looks like this:

prefix b: https://a/prefix b: https://b/ select * { b:x ?p b:x }

If you now change the first b back to a the where clause cannot be mapped back to its original.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OpenTriply/YASGUI.YASQE/issues/91#issuecomment-286850654, or mute the thread https://github.com/notifications/unsubscribe-auth/AASl5ApAUKtxspb_ILznd4LNdc9en2KJks5rmDmYgaJpZM4KtcUp .

[wouterbeek]

I'm still a bit worried that this feature can introduce behavior not anticipated by the user. As @pchampin points out, the user is always able to use 'undo' functionality to go back to an earlier state. The problem however is that the user might not be aware that by editing prefix declarations parts of the query can be (inadvertently) changed. I'm closing this for now...