Yes absolutely, that was the same problem that I was talking about. Data entry
of relationship instances is not as easy as it should.
Holger
> On 30 Jan 2024, at 6:39 pm, 'Branson, GaBriella C' via TopBraid Suite Users
> wrote:
>
> I don’t mind the process for creating reifiable properties
I don’t mind the process for creating reifiable properties in the ontology or
for my business user entering the data – I like that part.
I was meaning that the UI for a business user - when entering instance data for
a new relationship - is slightly cumbersome. Take for example entering a data
On creating reifications …
Perhaps a UI function added to the Modify button for a property to “Add
reification properties” a bit like “Declare inverse property” would be a start?
It could create the node shape pointing to the property and then users just add
whatever properties they want to
It worked, but I can see it in the source code :
j.2:editor ;
j.2:viewer ;
but not in the Users Panel but when I add uri.add(edg + 'dataSteward',
tbs.userURI('Test User')); this one I can see in the users Panel.
Why is that ?
Br,
Kasia
On Tuesday, January 30, 2024 at 2:44:29 PM UTC+1
Hi Holger,
as for this ?subject and ?class 2 it was my mistake. The query is correct
with ?subject.
I'll check the hours and create a ticket :)
I have one more question. How to add teamwork: editor and viewer.
let id = tbs.createAssetCollection({
typeLabel: "Glossary",
name: "Test
I don't see why it would ever write to some imported graph - the
graph.transaction clearly targets just the given graphURI.
It does however also collect unused classes from imported graphs, because the
select query walks across those.
BTW note that with
SELECT ?subject
Sure,
let graphURI = 'urn:x-evn-master:test';
graph.withDataGraph(graphURI, () => {
let usedURIs = graph.withDataGraph(graphURI + '.tch', () => {
return graph.select(`
SELECT DISTINCT ?uri
WHERE {
?t ?o ?uri .
FILTER isIRI(?uri)
Could you paste the code that you have right now so that I can see the full
context?
Thanks
Holger
> On 30 Jan 2024, at 11:58 am, Kasia Kryczka wrote:
>
> Hi Holger,
>
>
> Unfortunately, the solution does not give the expected results.
>
> It appears that when we add the history of
Hi Holger,
Unfortunately, the solution does not give the expected results.
It appears that when we add the history of changes to all the includes, the
history is saved in the included ontology and not in the collection we are
in.
Could you please advise whether this script can be adapted