Is it possible somehow to also show the blank nodes in the visual graph?
I noticed that in the visualization config queries there is a filter using isIRI(...) which makes sure that by default only IRIs are visualized. However removing that filter does not help at all - blank nodes are still not visible, which is a major limitation on the ability to visually expand/navigate the graph.
Even if blank nodes are not useful identifiers, they are necessary to navigate the graph and it's not always feasible to convert them to IRIs.
Visual graph shows only IRIs with their local name or label. Bnodes by themselves are not meaningful.
But you can construct with SPARQL IRIs from your BNodes' data (using the IRI function to create IRI from whatever string you like). These are virtual nodes that do not exist actually, but exist for visualization.
Customizing visual graphs with your own queries is described here:
https://graphdb.ontotext.com/documentation/9.9/free/devhub/custom-graph-views.html
Related
I am currently working with GraphDB to visualize some data that has a graph nature. I have imported the RDF data into graphDB and actually the graph is pretty nice. The only downside is that every single node is orange.
I was wondering then, if graphDB has some mechanism whereby the color of some nodes could be changed based upon a semantic relationship between them. For example:
<Berners_Lee> <created> <web> .
<Berners_Lee> <works_as_a> <teacher>
If I were to load this onto graphDB all nodes would appear by default in orange. Is there any way I can specify that nodes that are pointed by relationship created appear in blue?
I hope everything is clear. Any help would be much appreciated.
The colors are generated automatically and differentiate the types in one graph, which is their main purpose. Also we do not handle properly the case with multiple types for a node, but we have it in mind. The problem with your data is that all of the subject predicates and objects have no type (which makes them the same type). Here is a small example, based on your data which will produce the desired effect.
<Berners_Lee><created><www>;
<works_as_a><teacher>;
a <Person>.
<teacher> a <Occupation>.
Here's what I have (using a Mac):
An ontology was created in Protege (v5), incorporating some classes
from established ontologies.
All classes were given the same Base URI.
HermiT, FacT++, Pellet, and Ontop plugin reasoners were used to test the ontology in Protege, and no errors or messages were returned.
Protege's Ontop plugin (v1.8) was used to map the classes to
postgres RDBS column headers (table_column) and exported the R2RML
mapping file.
The Ontop CLI was used to materialize triples through a
jdbc postgres connection the ontology in turtle format, according to
the R2RML .ttl mappings file.
Here's where my interactions with GraphDB (v8.2) start:
The GraphDB repository was created with an OWL2-RL profile with the 'read only' unchecked.
All ontology and materialized data triples were uploaded to GraphDB through graphdb-import folder in turtle format. All options checked on upload, and the same Base URI was provided.
The Class Hierarchy diagram suggests that the imported triples are properly structured.
The Class Relationship circular network graph shows reasonable
relationships between the largest 10 classes.
The Domain-Range graph shows a number of in-going and out-going connections to nodes/individuals with predicates.
SPARQL queries appear to return expected values.
Here's my problem: When I enter the Visual Graph, I don't see anything. When I search and select a value that should have nodes, all I see is the single node with a message "This node has no visible connections."
What does this mean and where can I start troubleshooting? Or is the Visual Graph buggy?
Is there a layout or an option to avoid grouping nodes to overlap eachother?
I'm getting a graph with standalone and grouped nodes, but the combinations are dependent on dynamic data. So i can not place them on my one, or would like to avoid it.
All layouts i have tried do not take care of the grouping nodes and place their sub nodes together.
For example 'circle' creates one circle of all nodes, not a circle per group.
The goal would be to create something like "http://js.cytoscape.org/demos/5b192c88616af2f75344/", but there the nodes are placed manualy..
I have seen the example "http://js.cytoscape.org/demos/59e38e9f20e25a293e44/" which seems to work as required but it is using an extension. First of all i would like to find a built in solution.
Your requirement for a non-extension solution is erroneous.
Only basic, small KB layouts are included in Cytoscape.js itself, and it makes no functional difference whether a layout is included by default or not: They are both extensions -- some are included by default, some are not.
CoSE Bilkent is the best compound node layout algorithm for graphs/networks -- bar none. You can alternatively use CoSE, which is included by default. CoSE is a more basic version of the algorithm, optimised for speed at the expense of visual results in some cases.
There is a note on the cytoscape.js website that says:
"Note that a collection is immutible by default, meaning that the set of elements within a collection can not be changed. The API returns a new collection with different elements when necessary, instead of mutating the existing collection. This allows the developer to safely use set theory operations on collections, use collections functionally, and so on."
Does this mean it is not really suitable to use in the creation of online 'network editor' ie. where the user can interact to add and delete nodes and edges to the existing graph?
If I understand the note above it would mean that adding a new node would mean reconstructing the whole graph from scratch (but with the new node) and then presumably performing a complete redraw. Is this correct?
A collection is a set of elements; the set merely points to all the individual elements. You can think of it like an array of elements: The array just holds the elements. Different arrays/sets can have different, similar, overlapping elements, etc.
Cytoscape.js is very suitable for the purpose you mention. There are already projects that have live, collaborative editors (similar to google docs, online office, etc but for graphs). For example, a simple one that I created is codenamed "Factoid" for biological processes. Though I really think it ought to have a better, more accurate name -- you can still look through the code for a live collaboration example with Cytoscape.js. Because you can listen to events easily, it's relatively straightforward to send diffs (or even just events) back and forth between the server and the client.
Adding an element is inexpensive: It just adds the single element and redraws if opportune. It's even cheaper with cy.batch() for modifying lots of elements in a row.
I recently came across the working draft for SPARQL 1.1 Federation Extensions and wondered whether this was already possible using Named Graphs (not to detract from the usefulness of the aforementioned draft).
My understanding of Named Graphs is a little hazy, save that the only thing I have gleamed from reading the specs comprises rules around the merger, non merger in relation to other graphs at query time. Since this doesn't fully satisfy my understanding, my question is as follows:
Given the following query:
SELECT ?something
FROM NAMED <http://www.vw.co.uk/models/used>
FROM NAMED <http://www.autotrader.co.uk/cars/used>
WHERE {
...
}
Is it reasonable to assume that a query processor/endpoint could or should in the context of the named graphs do the following:
Check is the named graph exists locally
If it doesn't then perform the following operation (in the case of the above query, I will use the second named graph)
GET /sparql/?query=EncodedQuery HTTP/1.1
Host: www.autotrader.co.uk
User-agent: my-sparql-client/0.1
Where the EncodedQuery only includes the second named graph in the FROM NAMED clause and the WHERE clause is amended accordingly with respect to GRAPH clauses (e.g if a GRAPH <http://www.vw.co.uk/models/used> {...} is being used).
Only if it can't perform the above, then do any of the following:
GET /cars/used HTTP/1.1
Host: www.autotrader.co.uk
or
LOAD <http://www.autotrader.co.uk/cars/used>
Return appropriate search results.
Obviously there might be some additional considerations around OFFSET's and LIMIT's
I also remember reading somewhere a long time ago in galaxy far far away, that the default graph of any SPARQL endpoint should be a named graph according to the following convention:
For: http://www.vw.co.uk/sparql/ there should be a named graph of: http://www.vw.co.uk that represents the default graph and so by the above logic, it should already be possible to federate SPARQL endpoints using named graphs.
The reason I ask is that I want to start promoting federation across the domains in the above example, without having to wait around for the standard, making sure that I won't do something that is out of kilter or incompatible with something else in the future.
Named graph and URLs used in federated queries (using SERVICE or FROM) are two different things. The latter point to SPARQL endpoints, the named graphs are within a triple store and have the main function of separating different data sets. This, in turn, can be useful to both improve performance and represent knowledge, such as representing what is the source of a set of statements.
For instance, you might have two data sources both stating that ?movie has-rating ?x and you might want to know which source is stating which rating, in this case you can use two named graphs associated to the two sources (e.g., http://www.example.com/rotten-tomatoes and http://www.example.com/imdb). If you're storing both data sets in the same triple store, probably you will want to use NGs, and remote endpoints are a different thing. Furthermore, the URL of a named graph can be used with vocabularies like VoID to describe a dataset as a whole (eg, the data set name, where and when the triples are imported from, who is the maintainer, user licence). This is another reason to partition your triple store into NGs.
That said, your mechanism to bind NGs to endpoint URLs might be implemented as an option, but I don't think it's a good idea to have it as mandatory, since managing remote endpoint URLs and NGs separately can be more useful.
Moreover, the real challenge in federated queries is to offer endpoint-transparent queries, making the query engine smart enough to analyse the query and understand how to split it and perform partial queries on the right endpoints (and join the results later, in an efficient way). There is a lot of research being done on that, one of the most significant results (as far as I know) is FedX, which has been used to implement several query distribution optimisations (example).
Last thing to add, I vaguely remember the convention that you mention about $url, $url/sparql. There are a couple of approaches around (e.g., LOD cloud). That said, in most nowadays triple stores (e.g., Virtuoso), queries that don't specify a named graph (don't use GRAPH) work in a way different than falling into a default graph case, they actually query the union of all named graphs in the store, which is usually much more useful (when you don't know where something is stated, or you want to integrate cross-graph data).