Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Features 12-2023 #70

Open
BenjaminHofstetter opened this issue Dec 5, 2023 · 1 comment
Open

Features 12-2023 #70

BenjaminHofstetter opened this issue Dec 5, 2023 · 1 comment

Comments

@BenjaminHofstetter
Copy link
Collaborator

Things to think of:

  • Prefix handling
  • SELECT: rendering of huge results is slow
  • CONSTRUCT: my process -> copy the result and go to https://sketch.zazuko.com/ even there is vscode-rdf-sketch
  • Windows relative path problem with rq files
  • Write access
  • Oxigraph count optional variable problem
  • Oxigraph Variable Binding order
@vhorvath
Copy link

I was also thinking about PREFIX handling myself. I really like the extension, however it is inconvenient that PREFIXes must be repeated across cells in a notebook even though the same context is being used.

My current workaround

I currently use a keyboard shortcut to collapse the long series of prefixes in a cell: CTRL+K+[ to define the collapsible region. The only problem is that if another line is to be added to the region and that falls outside the predefined region, then the collapsible region needs to be redefined, and the collapsible regions don't copy/paste.

Idea 1: Context management

It would be great to implement a mechanism to delegate PREFIXes (or other repeated content) into contexts that could be utilized across other cells. I was thinking about adding special comment sections, see blow.

# <global>
PREFIX ...
PREFIX ...
# </global>

This could also be combined with the host definition via comment, like so:

# <global endpoint="./relative/path/file.ttl">
PREFIX ...
PREFIX ...
# </global>

Using XML style notation could allow for utilizing an existing language and its features to define contexts, and to include additional features as the extension evolves. Existing syntax for in cell endpoint definition could be preserved for compatibility.

Users could create cells to define contexts and upon execution they would be stored globally.

Recall of contexts in other cell:

# <global/>
# <other_context/>

The downside to this approach is that the recall of a context is opaque. We can't readily inspect what's in it at the time of recall. A collapsible view could be added to the cell's output section, that is collapsed by default but expanded on request to inspect the actual query as it was submitted to the endpoint. This view could feature a copy button so that the full query could be extracted.

Idea 2: Collapsible prefixes

Alternatively, (auto) collapse/expand feature could be implemented in the editor for the PREFIXes (similarly to the mechanism of Apache Fuseki) this way the delegation into a global context could be avoided, but cells could be a bit more succinct, and collapse could be enabled for 5 or more subsequent PREFIXes.

Downside to this approach is that the PREFIXes are hidden and definitions must be repeated, and if they need change across many cells, it is harder to update them all at once.

Could lend a hand with the implementation if specifications can be defined.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants