first test with the new Spoggy with minimal tools
with two graphs : one form navigation, the other of creating/editing graphs/ttl files
static , no webpack → can be hosted on github-pages so it could also be on a POD
Only had a quick play on my tablet, but it looks nice. The visual UI is intuitive and very smooth, no unpleasant surprises!
I haven’t thought about use cases really - I’ve been learning how to use d3js and Sveltejs. I’ve got a simple d3-force svelte component working here. Just the layout so far, next is to add interactivity (for now you can only hover over a node - no click and drag yet). It’s based on a d3 example that I’m aiming to recreate, the Force-Directed Graph:
Would it be possible to have a file browser on the side and then when you navigate to a file show the visualization in one polymer element, the turtle in another, etc? Maybe have one element that just does the file navigation and have that broadcast a pointer to the data to the others when it gets a file? Or have a right click on the navigator for the file type, then open that type in a separate window which is open on that file until the user closes it. And just have the elements (including the file navigator element) in separate windows that are moveable and resizeable?
thxs
I’ve made a first version of what could be that browser like the one on https://scenaristeur.github.io/spoggy-simple/?source=https://smag0.solid.community/profile/card#me when you click on ‘Universal Browser’
It host a texteditor, to see the data created with the graph, as json or ttl, and can send it to POD or save it as a local file. It can import .ttl & .json, and explore a POD. But do you think the text “editor” must be always available ?
A separate window is not what I planned as I want it to be used in mobile environnement / smartphone, but this could detect if environnement is a smartphone or not and adapt the modal / window
Oh yeah, small screens. But I think it should be like opening ‘tabs’ in Chrome, where you can have multiple open but only effectively see one at a time on a really small screen, but more than one on a bigger screen.
The broadcast or shared data pointer thing would be good if you want to edit from one window and have the changes show up in another. I think you could close the text editor element if you wanted to, and then go back to the navigator, right click on the file and choose editor if you want it back again. That seems intuitive to me, anyway.
Keep your requests coming. I have some ideas, but want to work with others too. I’m some way from building anything useful, so keen to see how spoggy evolves.
For what they are worth my ideas are in two areas:
providing multiple ways of viewing and interacting with data, including not just visualising it but creating and editing. So both side by side different visualisations, and alternate (tabbed as @anon36056958 wants), with the state of data instantly reflected in all views (eg selection, filtering). So network (as spoggy above), graphs of different types, tables etc.
intuitive easy ways of acquiring and interacting with data, that are intuitive and fun to use.
I think it would be good to build a Sparql Web Pages engine into it, piece by piece. Hopefully that doesn’t sound too crazy
Maybe at least at the beginning, some of the swp constructs, instead of being in the rdf itself, could be implied by or associated with the container the file is in, or the owl class in the rdf.
I’m not really sure how it fits together with forms, and what’s being done with solid-ui, it’s just the the example in the swp user guide looks so compelling.
SWP was developed under the working name UISPIN. The name UISPIN is still sometimes used in the context of the RDF namespaces, in parts of the TopBraid implementation, and in old blog entries. From a technology point of view, the name UISPIN represents the close relationship to [SPIN](http://spinrdf.org), while the name SPARQL Web Pages is more descriptive of what the technology has to offer, and is therefore the preferred name in publications.
From SPIN to SHACL
In July 2017, the W3C has ratified the [Shapes Constraint Language (SHACL)](https://www.w3.org/TR/shacl/) as an official W3C Recommendation. SHACL was strongly influenced by [SPIN](http://spinrdf.org) and can be regarded as its legitimate successor. This document explains how the two languages relate and shows how basically every SPIN feature has a direct equivalent in SHACL, while SHACL improves over the features explored by SPIN.
Using the ui-ontology would not make something dependent on html. But on the other hand I don’t think the ontology allows enough detail or specifics to exactly specify the UI, so users would depend on implementations of it that they can’t control.
2nd edit (sorry):
Ok, maybe the answer is improvements to the ui ontology, like maybe a class that allows you to specify html if you want to.
3rd edit (sorry again!)
But the thing with SWP is that it lets you embed Sparql in with the html very specifically, like this:
Is the same thing possible with forms/ui-ontology?
Interesting, that’s very like sveltejs, here’s an extract from inside an <svg> tag in my network example (see above link to see the full force):
{#each nodes as point}
<circle cx='{d3xScale(point.x)}' cy='{d3yScale(point.y)}' r='5'><title>{point.id}</title></circle>
{/each}
Do you know how the SWP tags get processed? I’m wondering if they are run through a preprocessor to generate a client side bundle, or if they require server side processing.
Sveltejs compiles everything to JavaScript, so you can create a static site, no server side magic needed.
“In order to fulfill its requests, a SWP server will operate on a collection of SWP files that are registered with it. The server will pre-load all files containing .ui. in their name and combine them into a (virtual) union graph called ui:graph . This graph will be used at execution time to identify which visualizations are available for a given context.”
, then…
