Re: [topbraid-users] sparql query to get all objects

[Kasia Kryczka]

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) .
}`).bindings.map(b => b.uri.uri);
});
console.log('Found ' + usedURIs.length);
// console.log(usedURIs);

 let orphans = graph.withDataGraph(dataset.withImports(graphURI), () =>
graph.select(`SELECT ?subject
  WHERE {{?class a owl:Class.  
BIND(?class as ?subject)
  }
UNION
{SELECT ?class2
   WHERE {{?instances a ?class.
BIND(?instances as ?subject)
}}}
  FILTER (?subject != "")
  FILTER isIRI(?subject).
  FILTER((?subject != owl:Thing) &&(?subject != owl:Nothing ))
}`))
.bindings
.map(b => b.subject)
  .filter(subject => !usedURIs.includes(subject.uri));
orphans.forEach((orphan) => {
console.log('Orphan is ' + orphan.uri);
 let triples = graph.withDataGraph(dataset.withImports(graphURI), 
() => graph.triples(orphan));
graph.transaction(graphURI + '.tch', 'Create dummy change 
for ' + orphan.uri, () => {
let uuid = graph.eval('STRUUID()');
let change = graph.namedNode('urn:x-change:' + uuid);
console.log('Change: ' + change.uri);
 console.log(change.uri);
 console.log(orphans)
  graph.update(`
PREFIX dcterms: 
PREFIX sioc: 
prefix rdf: 
prefix rdfs: 
INSERT {
<${change.uri}> rdf:type teamwork:Change ;
rdfs:comment "Dummy change entry for ${orphan.uri}";
dcterms:created ?now ;
sioc:has_creator  ;
teamwork:status   teamwork:Committed .
}
WHERE {
BIND (NOW() AS ?now) .
}`, {
$change : change
});
triples.forEach(triple => {
triple.change = change;
graph.update(`
INSERT {
<${change.uri}> teamwork:added [
teamwork:object $object ;
teamwork:predicate  $predicate ;
teamwork:subject$subject ;
]
} WHERE {}`, triple);

});
 })
})
 return orphans; 
});


Br,

Kasia
On Tuesday, January 30, 2024 at 12:02:17 PM UTC+1 Holger Knublauch wrote:

> 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 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 so that the 
> history of includes is saved in the collection we are in, or whether this 
> is not possible?
>
> Br,
>
> Kasia
> On Wednesday, January 10, 2024 at 12:59:52 PM UTC+1 Kasia Kryczka wrote:
>
>> Hi Holger,
>>
>> This is great :)
>>
>> Thank you,
>>
>> Br,
>>
>> Kasia
>>
>> On Monday, January 8, 2024 at 2:08:02 PM UTC+1 Holger Knublauch wrote:
>>
>>> Ok in that case, use something like
>>>
>>> let triples = graph.withDataGraph(dataset.withImports(graphURI), () => 
>>> graph.triples(orphan));
>>>
>>> (You will likely want to filter out owl:Thing and all kinds of other 
>>> classes that will be listed.)
>>>
>>> Holger
>>>
>>>
>>> On 8 Jan 2024, at 2:03 pm, Kasia Kryczka  wrote:
>>>
>>> Hi Holger,
>>>
>>> I got a request to create a dummy change history comment for all 
>>> owl:Class both defined locally and those which are included from all 
>>> imports. 
>>> These   owl:Thing and owl:Nothing do not need to have a dummy comment 
>>> but I have much more included classes from imports.
>>>
>>> Br,
>>>
>>> Kasia
>>>
>>> On Monday, January 8, 2024 at 1:45:49 PM UTC+1 Holger Knublauch wrote:
>>>
 Ok thanks, I better see what you're trying to do now. My previous 
 "hint" was not helpful.

 I ran the script in my test setup and think there is a mismatch between 
 the use of imported graphs:

 When you collect the orphans it will walk into the subgraphs, which in 
 my case found imported classes including owl:Thing and owl:Nothing. I 
 don't 
 think you really want to have change history entries for those.

 let orphans = graph.withDataGraph(dataset.withImports(graphURI)
>
>
 But then when you ask for triples, you're 

Re: [EXTERNAL] [topbraid-users] Reifiable by

[David Price]

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 reifiy to the shape. 

I guess could alternatively prompt user for a property name and a datatype and 
create the first refied property in the same interaction. They additional 
properties could be added to that same shape.

Cheers,
David

> On 30 Jan 2024, at 06:23, Holger Knublauch  wrote:
> 
> Hi GaBriella,
> 
> on the UI perspective, I could not agree more. Using intermediate objects is 
> indeed not well supported right now.
> 
> For example,
> 
>   ex:Person1
>   ex:memberOf [
>   a ex:Membership ;
>   ex:organization ex:Organization1 ;
>   ex:startDate "2005-04-12"^^xsd:date ;
>   ex:endDate "2009-11-08"^^xsd:date ;
>   ] .
> 
> currently requires creating that Membership instance, then going into it to 
> fill in the dates.
> 
> And querying often requires using path expressions such as
> 
>   ?person ex:memberOf/ex:organization ?org .
> 
> The situation is complicated as there are variations of this, e.g.
> 
>   ex:Person1Membership1
>   a ex:Membership ;
>   ex:member ex:Person1 ;
>   ex:organization ex:Organization1 ;
>   ex:startDate "2005-04-12"^^xsd:date ;
>   ex:endDate "2009-11-08"^^xsd:date .
> 
> I have some initial thoughts about better supporting editing blank nodes, but 
> none of that is fully fleshed out yet.
> 
> For these relationships, maybe a start would be to introduce some kind of 
> dash namespace extensions to
> annotate the "intermediate" objects, so that a UI can pick up a suitable 
> widget such as a tabular viewer and editor.
> 
> I wonder if anyone has input or similar requirements.
> 
> Is my assumption right that in many of these relationships, there is at most 
> a handful of properties (such as startDate
> and endDate), allowing tabular input and rendering?
> 
> Holger
> 
> 
>> On 29 Jan 2024, at 11:20 pm, 'Branson, GaBriella C' via TopBraid Suite Users 
>>  wrote:
>> 
>> Thank you. I will consider creating relationship objects instead. From a UI 
>> perspective (for the use case I was trying to solve for) I feel it is more 
>> straightforward to enter reifiable data over creating a new relationship 
>> object à saving the form à and then clicking into the new object to add the 
>> associated data.
>>  
>> Thanks again. I always appreciate learning best practices and 
>> recommendations to improve my modeling.
>>  
>> GaBriella Branson
>> Interagency Wildland Fire - Knowledge Manager
>> 
>>  
>> From: topbraid-users@googlegroups.com 
>>  > > On Behalf Of Holger Knublauch
>> Sent: Monday, January 29, 2024 12:39 PM
>> To: 'Bohms, H.M. (Michel)' via TopBraid Suite Users 
>> mailto:topbraid-users@googlegroups.com>>
>> Subject: [EXTERNAL] Re: [topbraid-users] Reifiable by
>>  
>>  
>> 
>>  This email has been received from outside of DOI - Use caution before 
>> clicking on links, opening attachments, or responding.  
>> 
>>  
>> 
>> Yes, only one level is supported. 
>>  
>> The general alternative to using reification is to introduce relationship 
>> objects, lifting the reification info into the main ontology. Some people 
>> argue that reification should not be used when it is really the 
>> representation of a relationship. Instead, it should only be used for cases 
>> like provenance of triples and other true metadata.
>>  
>> Holger
>>  
>>  
>> 
>> 
>> On 29 Jan 2024, at 8:24 pm, 'GaBriella Branson' via TopBraid Suite Users 
>> mailto:topbraid-users@googlegroups.com>> 
>> wrote:
>>  
>> Hello, 
>>  
>> Is there a limit to how "deep" reifiable statements can go?
>>  
>> I have a class with a property that has a node shape it is reifiable by. 
>> Within the node shape I would like to add another layer making one of my 
>> properties reifiable by yet another node shape. It does not appear that the 
>> shape within the shape is working.
>>  
>> First "layer" on the class: (this one works)
>> 
>> And this is the layer (a node shape on a node shape) that is not working:
>> 
>>  
>> Thanks in advance for any clarification you may have to explain what I 
>> should be expecting.
>>  
>> -- 
>> The topics of this mailing list include TopBraid EDG and related 
>> technologies such as SHACL.
>> To post to this group, send email to topbraid-users@googlegroups.com 
>> 
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "TopBraid Suite Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to 

Re: [topbraid-users] sparql query to get all objects

[Kasia Kryczka]

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 Holger Knublauch wrote:

> On 30 Jan 2024, at 2:41 pm, Kasia Kryczka  wrote:
>
> 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 Glossary v4",
> description: "this is a test glossary"
> });
> let edg = 'http://edg.topbraid.solutions/model/';
> let uri = graph.namedNode(tbs.assetCollectionURI(id));
> graph.transaction(uri, 'Initializing asset collection ' + id, () => {
> uri.add(edg + 'subjectArea', graph.namedNode(
> 'urn:x-tb-governance:Test'));
> *uri.add(teamwork + 'editor', tbs.userURI('test'));*
> *uri.add(teamwork + 'viewer', tbs.userURI('test'));*
> });
>
>
> Safest to use the full URI of that property, e.g. 'http://topbraid
> .org/teamwork#editor'
>
> HTH
> Holger
>
>
>  
>
>
>
>
> Br,
>
> Kasia
>
> On Tuesday, January 30, 2024 at 2:18:11 PM UTC+1 Holger Knublauch wrote:
>
>> 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
>> WHERE {
>> {
>> ?class a owl:Class. 
>> BIND (?class as ?subject)
>> }
>> UNION
>> {
>> SELECT ?class2
>> WHERE {
>> {
>> ?instances a ?class.
>> BIND(?instances as ?subject)
>> }
>> }
>> }
>> FILTER (?subject != "")
>> FILTER isIRI(?subject).
>> FILTER((?subject != owl:Thing) && (?subject != owl:Nothing ))
>> }
>>
>> the second branch of the UNION never returns any bindings for ?subject, 
>> as the SELECT only returns ?class2.
>> Also the FILTER (?subject != "") is unnecessary.
>>
>> Overall I don't think that continuing such complex topics via email works 
>> well. I think you should check if professional services
>> hours can be used for this.
>>
>> Regards,
>> Holger
>>
>>
>> On 30 Jan 2024, at 1:04 pm, Kasia Kryczka  wrote:
>>
>> 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) .
>> }`).bindings.map(b => b.uri.uri);
>> });
>> console.log('Found ' + usedURIs.length);
>> // console.log(usedURIs);
>>
>>  let orphans = graph.withDataGraph(dataset.withImports(graphURI), () =>
>> graph.select(`SELECT ?subject
>>   WHERE {{?class a owl:Class.  
>> BIND(?class as ?subject)
>>   }
>> UNION
>> {SELECT ?class2
>>WHERE {{?instances a ?class.
>> BIND(?instances as ?subject)
>> }}}
>>   FILTER (?subject != "")
>>   FILTER isIRI(?subject).
>>   FILTER((?subject != owl:Thing) &&(?subject != owl:Nothing ))
>> }`))
>> .bindings
>> .map(b => b.subject)
>>   .filter(subject => !usedURIs.includes(subject.uri));
>> orphans.forEach((orphan) => {
>> console.log('Orphan is ' + orphan.uri);
>>  let triples = graph.withDataGraph(dataset.withImports(graphURI), 
>> () => graph.triples(orphan));
>> graph.transaction(graphURI + '.tch', 'Create dummy change 
>> for ' + orphan.uri, () => {
>> let uuid = graph.eval('STRUUID()');
>> let change = graph.namedNode('urn:x-change:' + uuid);
>> console.log('Change: ' + change.uri);
>>  console.log(change.uri);
>>  console.log(orphans)
>>   graph.update(`
>> PREFIX dcterms: 
>> PREFIX sioc: 
>> prefix rdf: 
>> prefix rdfs: 
>> INSERT {
>> <${change.uri}> rdf:type teamwork:Change ;
>> rdfs:comment "Dummy change entry for 
>> ${orphan.uri}";
>> dcterms:created ?now ;
>> sioc:has_creator  ;
>> teamwork:status   teamwork:Committed .
>> }
>> WHERE {
>> BIND (NOW() AS ?now) .
>> }`, {
>> $change : change
>> });
>> triples.forEach(triple => {
>> triple.change = change;
>> graph.update(`
>> INSERT {
>>

Re: [topbraid-users] sparql query to get all objects

[Kasia Kryczka]

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 Glossary v4",
description: "this is a test glossary"
});
let edg = 'http://edg.topbraid.solutions/model/';
let uri = graph.namedNode(tbs.assetCollectionURI(id));
graph.transaction(uri, 'Initializing asset collection ' + id, () => {
uri.add(edg + 'subjectArea', graph.namedNode('urn:x-tb-governance:Test'
));
*uri.add(teamwork + 'editor', tbs.userURI('test'));*
*uri.add(teamwork + 'viewer', tbs.userURI('test'));*
});
 




Br,

Kasia

On Tuesday, January 30, 2024 at 2:18:11 PM UTC+1 Holger Knublauch wrote:

> 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
> WHERE {
> {
> ?class a owl:Class. 
> BIND (?class as ?subject)
> }
> UNION
> {
> SELECT ?class2
> WHERE {
> {
> ?instances a ?class.
> BIND(?instances as ?subject)
> }
> }
> }
> FILTER (?subject != "")
> FILTER isIRI(?subject).
> FILTER((?subject != owl:Thing) && (?subject != owl:Nothing ))
> }
>
> the second branch of the UNION never returns any bindings for ?subject, as 
> the SELECT only returns ?class2.
> Also the FILTER (?subject != "") is unnecessary.
>
> Overall I don't think that continuing such complex topics via email works 
> well. I think you should check if professional services
> hours can be used for this.
>
> Regards,
> Holger
>
>
> On 30 Jan 2024, at 1:04 pm, Kasia Kryczka  wrote:
>
> 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) .
> }`).bindings.map(b => b.uri.uri);
> });
> console.log('Found ' + usedURIs.length);
> // console.log(usedURIs);
>
>  let orphans = graph.withDataGraph(dataset.withImports(graphURI), () =>
> graph.select(`SELECT ?subject
>   WHERE {{?class a owl:Class.  
> BIND(?class as ?subject)
>   }
> UNION
> {SELECT ?class2
>WHERE {{?instances a ?class.
> BIND(?instances as ?subject)
> }}}
>   FILTER (?subject != "")
>   FILTER isIRI(?subject).
>   FILTER((?subject != owl:Thing) &&(?subject != owl:Nothing ))
> }`))
> .bindings
> .map(b => b.subject)
>   .filter(subject => !usedURIs.includes(subject.uri));
> orphans.forEach((orphan) => {
> console.log('Orphan is ' + orphan.uri);
>  let triples = graph.withDataGraph(dataset.withImports(graphURI), 
> () => graph.triples(orphan));
> graph.transaction(graphURI + '.tch', 'Create dummy change 
> for ' + orphan.uri, () => {
> let uuid = graph.eval('STRUUID()');
> let change = graph.namedNode('urn:x-change:' + uuid);
> console.log('Change: ' + change.uri);
>  console.log(change.uri);
>  console.log(orphans)
>   graph.update(`
> PREFIX dcterms: 
> PREFIX sioc: 
> prefix rdf: 
> prefix rdfs: 
> INSERT {
> <${change.uri}> rdf:type teamwork:Change ;
> rdfs:comment "Dummy change entry for 
> ${orphan.uri}";
> dcterms:created ?now ;
> sioc:has_creator  ;
> teamwork:status   teamwork:Committed .
> }
> WHERE {
> BIND (NOW() AS ?now) .
> }`, {
> $change : change
> });
> triples.forEach(triple => {
> triple.change = change;
> graph.update(`
> INSERT {
> <${change.uri}> teamwork:added [
> teamwork:object $object ;
> teamwork:predicate  $predicate ;
> teamwork:subject$subject ;
> ]
> } WHERE {}`, triple);
>
> });
>  })
> })
>  return orphans; 
> });
>
>
> Br,
>
> Kasia
> On Tuesday, January 30, 2024 at 12:02:17 PM UTC+1 Holger Knublauch wrote:
>
>> 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,
>>
>>
>> 

Re: [topbraid-users] sparql query to get all objects

[Holger Knublauch]

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
WHERE {
{
?class a owl:Class.  
BIND (?class as ?subject)
}
UNION
{
SELECT ?class2
WHERE {
{
?instances a ?class.
BIND(?instances as ?subject)
}
}
}
FILTER (?subject != "")
FILTER isIRI(?subject).
FILTER((?subject != owl:Thing) && (?subject != owl:Nothing ))
}

the second branch of the UNION never returns any bindings for ?subject, as the 
SELECT only returns ?class2.
Also the FILTER (?subject != "") is unnecessary.

Overall I don't think that continuing such complex topics via email works well. 
I think you should check if professional services
hours can be used for this.

Regards,
Holger


> On 30 Jan 2024, at 1:04 pm, Kasia Kryczka  wrote:
> 
> 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) .
> }`).bindings.map(b => b.uri.uri);
> });
> console.log('Found ' + usedURIs.length);
> // console.log(usedURIs);
> 
>  let orphans = graph.withDataGraph(dataset.withImports(graphURI), () =>
> graph.select(`SELECT ?subject
>   WHERE {{?class a owl:Class.  
> BIND(?class as ?subject)
>   }
> UNION
> {SELECT ?class2
>WHERE {{?instances a ?class.
> BIND(?instances as ?subject)
> }}}
>   FILTER (?subject != "")
>   FILTER isIRI(?subject).
>   FILTER((?subject != owl:Thing) &&(?subject != owl:Nothing ))
> }`))
> .bindings
> .map(b => b.subject)
>   .filter(subject => !usedURIs.includes(subject.uri));
> orphans.forEach((orphan) => {
> console.log('Orphan is ' + orphan.uri);
>  let triples = graph.withDataGraph(dataset.withImports(graphURI), () 
> => graph.triples(orphan));
> graph.transaction(graphURI + '.tch', 'Create dummy change for 
> ' + orphan.uri, () => {
> let uuid = graph.eval('STRUUID()');
> let change = graph.namedNode('urn:x-change:' + uuid);
> console.log('Change: ' + change.uri);
>  console.log(change.uri);
>  console.log(orphans)
>   graph.update(`
> PREFIX dcterms: 
> PREFIX sioc: 
> prefix rdf: 
> prefix rdfs: 
> INSERT {
> <${change.uri}> rdf:type teamwork:Change ;
> rdfs:comment "Dummy change entry for ${orphan.uri}";
> dcterms:created ?now ;
> sioc:has_creator  ;
> teamwork:status   teamwork:Committed .
> }
> WHERE {
> BIND (NOW() AS ?now) .
> }`, {
> $change : change
> });
> triples.forEach(triple => {
> triple.change = change;
> graph.update(`
> INSERT {
> <${change.uri}> teamwork:added [
> teamwork:object $object ;
> teamwork:predicate  $predicate ;
> teamwork:subject$subject ;
> ]
> } WHERE {}`, triple);
> 
> });
>  })
> })
>  return orphans; 
> });
> 
> 
> Br,
> 
> Kasia
> On Tuesday, January 30, 2024 at 12:02:17 PM UTC+1 Holger Knublauch wrote:
>> 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 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 so that the 
>>> history of includes is saved in the collection we are in, or whether this 
>>> is not possible?
>>> 
>>> Br,
>>> 
>>> Kasia
>>> On Wednesday, January 10, 2024 at 12:59:52 PM UTC+1 

Re: [topbraid-users] sparql query to get all objects

[Kasia Kryczka]

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 so that the 
history of includes is saved in the collection we are in, or whether this 
is not possible?

Br,

Kasia
On Wednesday, January 10, 2024 at 12:59:52 PM UTC+1 Kasia Kryczka wrote:

> Hi Holger,
>
> This is great :)
>
> Thank you,
>
> Br,
>
> Kasia
>
> On Monday, January 8, 2024 at 2:08:02 PM UTC+1 Holger Knublauch wrote:
>
>> Ok in that case, use something like
>>
>> let triples = graph.withDataGraph(dataset.withImports(graphURI), () => 
>> graph.triples(orphan));
>>
>> (You will likely want to filter out owl:Thing and all kinds of other 
>> classes that will be listed.)
>>
>> Holger
>>
>>
>> On 8 Jan 2024, at 2:03 pm, Kasia Kryczka  wrote:
>>
>> Hi Holger,
>>
>> I got a request to create a dummy change history comment for all 
>> owl:Class both defined locally and those which are included from all 
>> imports. 
>> These   owl:Thing and owl:Nothing do not need to have a dummy comment but 
>> I have much more included classes from imports.
>>
>> Br,
>>
>> Kasia
>>
>> On Monday, January 8, 2024 at 1:45:49 PM UTC+1 Holger Knublauch wrote:
>>
>>> Ok thanks, I better see what you're trying to do now. My previous "hint" 
>>> was not helpful.
>>>
>>> I ran the script in my test setup and think there is a mismatch between 
>>> the use of imported graphs:
>>>
>>> When you collect the orphans it will walk into the subgraphs, which in 
>>> my case found imported classes including owl:Thing and owl:Nothing. I don't 
>>> think you really want to have change history entries for those.
>>>
>>> let orphans = graph.withDataGraph(dataset.withImports(graphURI)


>>> But then when you ask for triples, you're only getting the locally 
>>> defined triples:
>>>
>>>   let triples = graph.triples(orphan, null, null);


>>> Shouldn't both do the same thing and use imported graphs consistently?
>>>
>>> Why did you want to use dataset.withImports in the first case?
>>>
>>> In my local tests I can see a dummy change history entry created just 
>>> fine, assuming the owl:Class is defined locally.
>>>
>>> Also, to double-check, you really want to only find newly defined 
>>> owl:Classes and not their instances?
>>>
>>> Holger
>>>
>>>
>>> On 8 Jan 2024, at 1:23 pm, Kasia Kryczka  wrote:
>>>
>>> Hi Holger, 
>>>
>>> Unfortunately, it doesn't work. 
>>> I get the comment but nothing gets added. The record is empty.  
>>> When i look at the console I see correct "orphans" and I changed so the 
>>>  usedURIs  should be a match when filtering but the result is the same. 
>>>
>>> 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) .
>>> }`).bindings.map(b => b.uri.uri);
>>> });
>>> console.log('Found ' + usedURIs.length);
>>> // console.log(usedURIs);
>>>
>>> Am I missing sth ?
>>>
>>> Br,
>>>
>>> Kasia
>>>
>>> On Friday, January 5, 2024 at 3:56:26 PM UTC+1 Holger Knublauch wrote:
>>>

 On 5 Jan 2024, at 3:51 pm, Kasia Kryczka  wrote:

 Hi Holger, 


 I used a different thing  as I need to add a change history to all 
 these objects: I used the following :


 let graphURI = 'urn:x-evn-master:test';
 graph.withDataGraph(graphURI, () => {
 let usedURIs = graph.withDataGraph(graphURI + '.tch', () => {
 return graph.select(`
 SELECT DISTINCT ?uri
 WHERE {
 ?t teamwork:subject|teamwork:predicate|teamwork:object 
 ?uri .
 FILTER isIRI(?uri) .
 }`).bindings.map(b => b.uri.uri);
 });

 console.log('Found ' + usedURIs.length);
 let orphans = graph.withDataGraph(dataset.withImports(graphURI), 
 () => 
 graph.select(`SELECT ?subject  WHERE { ?subject a owl:Class. 
  FILTER isIRI(?subject) }`))
 .bindings
 .map(b => b.subject)
   .filter(subject => !usedURIs.includes(subject.uri));
 
 orphans.forEach((orphan) => {
 console.log('Orphan is ' + orphan.uri);
 let triples = graph.triples(orphan, null, null);
 graph.transaction(graphURI + '.tch', 'Create dummy change for ' 
 + orphan.uri, () => {
 let uuid = graph.eval('STRUUID()');
 let change = graph.namedNode('urn:x-change:' + uuid);
 console.log('Change: ' + change.uri);
 graph.update(`
 PREFIX dcterms: 

Re: [topbraid-users] sparql query to get all objects

[Holger Knublauch]

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 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 so that the 
> history of includes is saved in the collection we are in, or whether this is 
> not possible?
> 
> Br,
> 
> Kasia
> On Wednesday, January 10, 2024 at 12:59:52 PM UTC+1 Kasia Kryczka wrote:
>> Hi Holger,
>> 
>> This is great :)
>> 
>> Thank you,
>> 
>> Br,
>> 
>> Kasia
>> 
>> On Monday, January 8, 2024 at 2:08:02 PM UTC+1 Holger Knublauch wrote:
>>> Ok in that case, use something like
>>> 
>>> let triples = graph.withDataGraph(dataset.withImports(graphURI), () => 
>>> graph.triples(orphan));
>>> 
>>> (You will likely want to filter out owl:Thing and all kinds of other 
>>> classes that will be listed.)
>>> 
>>> Holger
>>> 
>>> 
>>> 
 On 8 Jan 2024, at 2:03 pm, Kasia Kryczka > wrote:
 
>>> 
 Hi Holger,
 
 I got a request to create a dummy change history comment for all owl:Class 
 both defined locally and those which are included from all imports. 
 These   owl:Thing and owl:Nothing do not need to have a dummy comment but 
 I have much more included classes from imports.
 
 Br,
 
 Kasia
 
 On Monday, January 8, 2024 at 1:45:49 PM UTC+1 Holger Knublauch wrote:
> Ok thanks, I better see what you're trying to do now. My previous "hint" 
> was not helpful.
> 
> I ran the script in my test setup and think there is a mismatch between 
> the use of imported graphs:
> 
> When you collect the orphans it will walk into the subgraphs, which in my 
> case found imported classes including owl:Thing and owl:Nothing. I don't 
> think you really want to have change history entries for those.
> 
 let orphans = graph.withDataGraph(dataset.withImports(graphURI)
> 
> But then when you ask for triples, you're only getting the locally 
> defined triples:
> 
   let triples = graph.triples(orphan, null, null);
> 
> 
> Shouldn't both do the same thing and use imported graphs consistently?
> 
> Why did you want to use dataset.withImports in the first case?
> 
> In my local tests I can see a dummy change history entry created just 
> fine, assuming the owl:Class is defined locally.
> 
> Also, to double-check, you really want to only find newly defined 
> owl:Classes and not their instances?
> 
> Holger
> 
> 
> 
>> On 8 Jan 2024, at 1:23 pm, Kasia Kryczka > wrote:
>> 
> 
>> Hi Holger, 
>> 
>> Unfortunately, it doesn't work. 
>> I get the comment but nothing gets added. The record is empty.  
>> When i look at the console I see correct "orphans" and I changed so the  
>> usedURIs  should be a match when filtering but the result is the same. 
>> 
>> 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) .
>> }`).bindings.map(b => b.uri.uri);
>> });
>> console.log('Found ' + usedURIs.length);
>> // console.log(usedURIs);
>> 
>> Am I missing sth ?
>> 
>> Br,
>> 
>> Kasia
>> 
>> On Friday, January 5, 2024 at 3:56:26 PM UTC+1 Holger Knublauch wrote:
>>> 
 On 5 Jan 2024, at 3:51 pm, Kasia Kryczka gmail.com 
 > wrote:
 
 Hi Holger, 
 
 
 I used a different thing  as I need to add a change history to all 
 these objects: I used the following :
 
 
 let graphURI = 'urn:x-evn-master:test';
 graph.withDataGraph(graphURI, () => {
 let usedURIs = graph.withDataGraph(graphURI + '.tch', () => {
 return graph.select(`
 SELECT DISTINCT ?uri
 WHERE {
 ?t teamwork:subject|teamwork:predicate|teamwork:object 
 ?uri .
 FILTER isIRI(?uri) .
 }`).bindings.map(b => b.uri.uri);
 });
 
 console.log('Found ' + usedURIs.length);
 let orphans = graph.withDataGraph(dataset.withImports(graphURI), 
 () => 
 graph.select(`SELECT ?subject  WHERE { ?subject a owl:Class.  
 FILTER isIRI(?subject) }`))
 .bindings
 .map(b => b.subject)
  

RE: [EXTERNAL] [topbraid-users] Reifiable by

['Branson, GaBriella C' via TopBraid Suite Users]

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 
value rule in the glossary. If the data value rule does not already exist, a 
user has to use the plus sign to add it. In the new pop-up they only get the 
Label and ID fields initially (unless other properties required). After 
creating the shell of the data value rule I have to save the glossary term and 
then click back into the data value rule to enter any supporting data. It feels 
like extra steps when if it is a reifiable value I simply have to click on the 
little plus sign next to the relationship value and begin adding the additional 
data. Does that make sense?

GaBriella

From: topbraid-users@googlegroups.com  On 
Behalf Of David Price
Sent: Tuesday, January 30, 2024 6:54 AM
To: topbraid-users@googlegroups.com
Subject: Re: [EXTERNAL] [topbraid-users] Reifiable by

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 reifiy to the shape.

I guess could alternatively prompt user for a property name and a datatype and 
create the first refied property in the same interaction. They additional 
properties could be added to that same shape.

Cheers,
David


On 30 Jan 2024, at 06:23, Holger Knublauch 
mailto:hol...@topquadrant.com>> wrote:

Hi GaBriella,

on the UI perspective, I could not agree more. Using intermediate objects is 
indeed not well supported right now.

For example,

   ex:Person1
  ex:memberOf [
  a ex:Membership ;
  ex:organization ex:Organization1 ;
  ex:startDate "2005-04-12"^^xsd:date ;
  ex:endDate "2009-11-08"^^xsd:date ;
  ] .

currently requires creating that Membership instance, then going into it to 
fill in the dates.

And querying often requires using path expressions such as

   ?person ex:memberOf/ex:organization ?org .

The situation is complicated as there are variations of this, e.g.

   ex:Person1Membership1
  a ex:Membership ;
  ex:member ex:Person1 ;
  ex:organization ex:Organization1 ;
   ex:startDate "2005-04-12"^^xsd:date ;
   ex:endDate "2009-11-08"^^xsd:date .

I have some initial thoughts about better supporting editing blank nodes, but 
none of that is fully fleshed out yet.

For these relationships, maybe a start would be to introduce some kind of dash 
namespace extensions to
annotate the "intermediate" objects, so that a UI can pick up a suitable widget 
such as a tabular viewer and editor.

I wonder if anyone has input or similar requirements.

Is my assumption right that in many of these relationships, there is at most a 
handful of properties (such as startDate
and endDate), allowing tabular input and rendering?

Holger



On 29 Jan 2024, at 11:20 pm, 'Branson, GaBriella C' via TopBraid Suite Users 
mailto:topbraid-users@googlegroups.com>> wrote:

Thank you. I will consider creating relationship objects instead. From a UI 
perspective (for the use case I was trying to solve for) I feel it is more 
straightforward to enter reifiable data over creating a new relationship object 
--> saving the form --> and then clicking into the new object to add the 
associated data.

Thanks again. I always appreciate learning best practices and recommendations 
to improve my modeling.

GaBriella Branson
Interagency Wildland Fire - Knowledge Manager


From: topbraid-users@googlegroups.com 
mailto:topbraid-users@googlegroups.com>> On 
Behalf Of Holger Knublauch
Sent: Monday, January 29, 2024 12:39 PM
To: 'Bohms, H.M. (Michel)' via TopBraid Suite Users 
mailto:topbraid-users@googlegroups.com>>
Subject: [EXTERNAL] Re: [topbraid-users] Reifiable by




 This email has been received from outside of DOI - Use caution before clicking 
on links, opening attachments, or responding.


Yes, only one level is supported.

The general alternative to using reification is to introduce relationship 
objects, lifting the reification info into the main ontology. Some people argue 
that reification should not be used when it is really the representation of a 
relationship. Instead, it should only be used for cases like provenance of 
triples and other true metadata.

Holger





On 29 Jan 2024, at 8:24 pm, 'GaBriella Branson' via TopBraid Suite Users 
mailto:topbraid-users@googlegroups.com>> wrote:

Hello,

Is 

Re: [EXTERNAL] [topbraid-users] Reifiable by

[Holger Knublauch]

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 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 value rule in the glossary. If the data value rule does not already 
> exist, a user has to use the plus sign to add it. In the new pop-up they only 
> get the Label and ID fields initially (unless other properties required). 
> After creating the shell of the data value rule I have to save the glossary 
> term and then click back into the data value rule to enter any supporting 
> data. It feels like extra steps when if it is a reifiable value I simply have 
> to click on the little plus sign next to the relationship value and begin 
> adding the additional data. Does that make sense?
>  
> GaBriella
>  
> From: topbraid-users@googlegroups.com  On 
> Behalf Of David Price
> Sent: Tuesday, January 30, 2024 6:54 AM
> To: topbraid-users@googlegroups.com
> Subject: Re: [EXTERNAL] [topbraid-users] Reifiable by
>  
> 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 reifiy to the shape. 
>  
> I guess could alternatively prompt user for a property name and a datatype 
> and create the first refied property in the same interaction. They additional 
> properties could be added to that same shape.
>  
> Cheers,
> David
> 
> 
> On 30 Jan 2024, at 06:23, Holger Knublauch  > wrote:
>  
> Hi GaBriella,
>  
> on the UI perspective, I could not agree more. Using intermediate objects is 
> indeed not well supported right now.
>  
> For example,
>  
>ex:Person1
>   ex:memberOf [
>   a ex:Membership ;
>   ex:organization ex:Organization1 ;
>   ex:startDate "2005-04-12"^^xsd:date ;
>   ex:endDate "2009-11-08"^^xsd:date ;
>   ] .
>  
> currently requires creating that Membership instance, then going into it to 
> fill in the dates.
>  
> And querying often requires using path expressions such as
>  
>?person ex:memberOf/ex:organization ?org .
>  
> The situation is complicated as there are variations of this, e.g.
>  
>ex:Person1Membership1
>   a ex:Membership ;
>   ex:member ex:Person1 ;
>   ex:organization ex:Organization1 ;
>ex:startDate "2005-04-12"^^xsd:date ;
>ex:endDate "2009-11-08"^^xsd:date .
>  
> I have some initial thoughts about better supporting editing blank nodes, but 
> none of that is fully fleshed out yet.
>  
> For these relationships, maybe a start would be to introduce some kind of 
> dash namespace extensions to
> annotate the "intermediate" objects, so that a UI can pick up a suitable 
> widget such as a tabular viewer and editor.
>  
> I wonder if anyone has input or similar requirements.
>  
> Is my assumption right that in many of these relationships, there is at most 
> a handful of properties (such as startDate
> and endDate), allowing tabular input and rendering?
>  
> Holger
>  
> 
> 
> On 29 Jan 2024, at 11:20 pm, 'Branson, GaBriella C' via TopBraid Suite Users 
> mailto:topbraid-users@googlegroups.com>> 
> wrote:
>  
> Thank you. I will consider creating relationship objects instead. From a UI 
> perspective (for the use case I was trying to solve for) I feel it is more 
> straightforward to enter reifiable data over creating a new relationship 
> object à saving the form à and then clicking into the new object to add the 
> associated data.
>  
> Thanks again. I always appreciate learning best practices and recommendations 
> to improve my modeling.
>  
> GaBriella Branson
> Interagency Wildland Fire - Knowledge Manager
> 
>  
> From: topbraid-users@googlegroups.com 
>   > On Behalf Of Holger Knublauch
> Sent: Monday, January 29, 2024 12:39 PM
> To: 'Bohms, H.M. (Michel)' via TopBraid Suite Users 
> mailto:topbraid-users@googlegroups.com>>
> Subject: [EXTERNAL] Re: [topbraid-users] Reifiable by
>  
>  
> 
>  This email has been received from outside of DOI - Use caution before 
> clicking on links, opening attachments, or responding.  
> 
>  
> 
> Yes, only one