Refering to the example used in: Stardog Studio: RDF* edge properties in visualization
The viz does only show 2 (Class; URI) out of the 4 edge properties:
I am using 7.6.4
Could anyone shed some light here? I have upgraded to the latest version and still have the same issue. Thanks in advance!
Thanks for reporting this; we have confirmed that this is a bug. I've created an issue for it internally, and will update when we release the fix.
Hi Annee,
it looks like the bug has been addressed ( * Cannot see literal nodes for edge properties in visualizations (VET-1299)
Unfortunately, running the referenced example from the tutorial using server v 7.7.3 and explorer v 3.1.0 still produces the same issue. Can you reproduce this on your end as well?
Thanks,
Oliver
Hi Oliver,
Explorer does not currently support showing literals as nodes on the graph. This is the case for both literals in regular triples and in edge properties. If you want to see the datatype properties of a given node in Explorer, you can right-click the node and select "See Details".
Best,
Annee
Sorry, Annee, I was refering to Stardog Studio and not to Explorer, my mistake.
However, it is in Explorer 3.1.0 where I still have the issue.
The result set
gets visualized as:
Am I doing something wrong here?
What query do you have in the text editor above the visualization? I am not able to reproduce it with the following:
I did run a SELECT query:
SELECT * WHERE {?s ?p ?o}
Then I just use the "visualize" button to produce the folowing:
# Expand From IRIs
CONSTRUCT {
?iri ?predicate ?object .
?object a ?object_type .
?object <tag:stardog:studio:label> ?object_label_0 .
?object rdfs:label ?object_label_1 .
?object <http://purl.org/dc/elements/1.1/title> ?object_label_2 .
?subject ?predicate_2 ?iri .
?subject a ?subject_type .
?subject <tag:stardog:studio:label> ?subject_label_0 .
?subject rdfs:label ?subject_label_1 .
?subject <http://purl.org/dc/elements/1.1/title> ?subject_label_2 .
} WHERE {
VALUES (?iri) {
(<http://properties/Alice>)
(<http://properties/worksFor>)
(<http://properties/ACME>)
(<http://properties/role>)
(<http://properties/CEO>)
(<http://properties/source>)
(<http://example.com/news>)
(<http://properties/probability>)
(<http://properties/since>)
}
{
?iri ?predicate ?object .
OPTIONAL { ?object a ?object_type . }
OPTIONAL { ?object <tag:stardog:studio:label> ?object_label_0 . }
OPTIONAL { ?object rdfs:label ?object_label_1 . }
OPTIONAL { ?object <http://purl.org/dc/elements/1.1/title> ?object_label_2 . }
}
UNION {
?subject ?predicate_2 ?iri .
OPTIONAL { ?subject a ?subject_type . }
OPTIONAL { ?subject <tag:stardog:studio:label> ?subject_label_0 . }
OPTIONAL { ?subject rdfs:label ?subject_label_1 . }
OPTIONAL { ?subject <http://purl.org/dc/elements/1.1/title> ?subject_label_2 . }
}
}
LIMIT 1000
In this case, the literal nodes are not shown.
However, if I use a CONSTRUCT query along the lines of what you have suggested, the literal nodes are indeed shown:
CONSTRUCT {?s ?p ?o} WHERE {?s ?p ?o}
So I should probably always use my own CONSTRUCT rather than the "automated" mechanism for visualizing results from a SELECT query, right?
The current query that the "Visualize" button produces does not include searching across edge properties, so yes, you would need to modify the provided CONSTRUCT query, or write a new one to include that data. Here's an example where I've extended the existing query:
CONSTRUCT {
?iri ?predicate ?object .
?object a ?object_type .
?object <tag:stardog:studio:label> ?object_label_0 .
?object rdfs:label ?object_label_1 .
?object <http://purl.org/dc/elements/1.1/title> ?object_label_2 .
?subject ?predicate_2 ?iri .
?subject a ?subject_type .
?subject <tag:stardog:studio:label> ?subject_label_0 .
?subject rdfs:label ?subject_label_1 .
?subject <http://purl.org/dc/elements/1.1/title> ?subject_label_2 .
# triples for edge properties
<< ?iri ?edge_predicate ?edge_object >> ?predicate_3 ?object .
<< ?edge_subject ?edge_predicate ?iri >> ?predicate_4 ?object .
} WHERE {
VALUES (?iri) {
(your...)
(iris...)
}
{
?iri ?predicate ?object .
OPTIONAL { ?object a ?object_type . }
OPTIONAL { ?object <tag:stardog:studio:label> ?object_label_0 . }
OPTIONAL { ?object rdfs:label ?object_label_1 . }
OPTIONAL { ?object <http://purl.org/dc/elements/1.1/title> ?object_label_2 . }
}
UNION {
?subject ?predicate_2 ?iri .
OPTIONAL { ?subject a ?subject_type . }
OPTIONAL { ?subject <tag:stardog:studio:label> ?subject_label_0 . }
OPTIONAL { ?subject rdfs:label ?subject_label_1 . }
OPTIONAL { ?subject <http://purl.org/dc/elements/1.1/title> ?subject_label_2 . }
}
# query for edge properties
UNION {
<< ?iri ?edge_predicate ?edge_object >> ?predicate_3 ?object .
OPTIONAL { ?object a ?object_type . }
OPTIONAL { ?object <tag:stardog:studio:label> ?object_label_0 . }
OPTIONAL { ?object rdfs:label ?object_label_1 . }
OPTIONAL { ?object <http://purl.org/dc/elements/1.1/title> ?object_label_2 . }
}
UNION {
<< ?edge_subject ?edge_predicate ?iri >> ?predicate_4 ?object .
OPTIONAL { ?object a ?object_type . }
OPTIONAL { ?object <tag:stardog:studio:label> ?object_label_0 . }
OPTIONAL { ?object rdfs:label ?object_label_1 . }
OPTIONAL { ?object <http://purl.org/dc/elements/1.1/title> ?object_label_2 . }
}
}
Thanks, Annee. That solves the issue for me.
Appreciate the support!