Re: [topbraid-users] Asserting inverse properties (skos:topConceptOf)

[Steve Ray]

OK, fair enough. I did think that you were saying that was a case where you
needed an explicit inverse relation.

Steve




On Wed, Apr 17, 2024 at 9:35 AM David Price  wrote:

> Sure Steve, that’s exactly what I was talking about …  I guess I did not
> word my reply very weill if it was confusing to you or anyone else.
>
> Cheers,
> David
>
> On 17 Apr 2024, at 14:21, Steve Ray  wrote:
>
> Actually, David, you don't need the explicit inverse even for cardinality
> constraints. Here's a snippet from a standard I'm working on:
>
> sh:property [
> sh:path [
> sh:inversePath s223:observes ;
> ] ;
> rdfs:comment "An instance of s223:Property must not be observed (set) by
> more than one entity." ;
> sh:maxCount 1 ;
> sh:message "s223: An instance of s223:Property must not be observed (set)
> by more than one entity." ;
> ] ;
>
> Steve
>
>
>
>
> On Wed, Apr 17, 2024 at 4:36 AM David Price 
> wrote:
>
>>
>>
>> On 17 Apr 2024, at 09:18, Holger Knublauch 
>> wrote:
>>
>> Hi Dan,
>>
>> yes this can be achieved through a dash:ChangeScript, see
>> https://archive.topquadrant.com/doc/latest/ext/points.html#change-and-commit-scripts
>>
>> Basically, such scripts are triggered after every change and may perform
>> additional changes. In this case, whenever a skos:hasTopConcept gets
>> asserted, it would need to assert the corresponding inverse triple. And the
>> same for deleting triples. To work consistently, it would need to operate
>> in both directions.
>>
>> Note that in contrast to ChangeScripts, inference rules such as sh:values
>> rules are only computed on demand and not persisted. They are only computed
>> to populate the user interface, for example when you look at the narrower
>> concepts that render as inverse of skos:broader triples. We only store
>> these in one direction, and do so intentionally because having an inverse
>> triple is just adding extra costs and drive up the maintenance burden as it
>> is easy to get into situations where the two directions become out of
>> synch. Therefore we strongly discourage using explicit inverse triples,
>> instead preferring sh:inversePath declarations.
>>
>>
>> Holger is 100% right on the “discourage using explicit inverse triples”
>> idea. They are nearly impossible to keep synch’d and we have recent
>> customer situations where we had to “undo” that mistake as part of a data
>> model V2 and related data migration.
>>
>> In my personal opinion, introducing inverse properties with OWL was a
>> major mistake, and it got unfortunately propagated into SKOS too. As RDF
>> triples are symmetric between subjects and objects, and graphs can be
>> walked in both directions equally.
>>
>>
>> From a modeller’s perspective the main “good” reason to include inverse
>> properties in SHACL it is so that the reverse property can have cardinality
>> constraints. That need does pop up, so almost all data modelling
>> languages/standards support the idea of inverse relations with cardinality.
>> It’s not specific to RDF-land.
>>
>> Cheers,
>> David
>>
>> Do you have downstream tools that require these explicit inverse triples?
>>
>>
>> Holger
>>
>>
>> On 16 Apr 2024, at 8:03 PM, Dan Segal  wrote:
>>
>> Is there a way to assert an inverse property into the source code of a
>> concept?
>>
>> For example, where we have:
>>
>> *conceptScheme skos:hasTopConcept concept*
>>
>> we want to assert:
>>
>> *concept skos:topConceptOf conceptScheme*
>>
>> Since *skos:topConceptOf* is defined as the inverse of *skos:hasTopConcept,
>> *the relationship displays in the form view.   However, we want to
>> assert the statement so that the triple *concept skos:topConceptOf
>> conceptScheme* is written to the RDF.
>>
>> Have tried a property rule, as well executing inference rules.  Neither
>> results in the inverse relationship being written to RDF.
>>
>> Thank you
>>
>>
>>
>>
>>
>>
>>
>> --
>> 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 topbraid-users+unsubscr...@googlegroups.com.
>> To view this discussion on the 

Re: [topbraid-users] Asserting inverse properties (skos:topConceptOf)

[Steve Ray]

Actually, David, you don't need the explicit inverse even for cardinality
constraints. Here's a snippet from a standard I'm working on:

sh:property [
sh:path [
sh:inversePath s223:observes ;
] ;
rdfs:comment "An instance of s223:Property must not be observed (set) by
more than one entity." ;
sh:maxCount 1 ;
sh:message "s223: An instance of s223:Property must not be observed (set)
by more than one entity." ;
] ;

Steve




On Wed, Apr 17, 2024 at 4:36 AM David Price  wrote:

>
>
> On 17 Apr 2024, at 09:18, Holger Knublauch  wrote:
>
> Hi Dan,
>
> yes this can be achieved through a dash:ChangeScript, see
> https://archive.topquadrant.com/doc/latest/ext/points.html#change-and-commit-scripts
>
> Basically, such scripts are triggered after every change and may perform
> additional changes. In this case, whenever a skos:hasTopConcept gets
> asserted, it would need to assert the corresponding inverse triple. And the
> same for deleting triples. To work consistently, it would need to operate
> in both directions.
>
> Note that in contrast to ChangeScripts, inference rules such as sh:values
> rules are only computed on demand and not persisted. They are only computed
> to populate the user interface, for example when you look at the narrower
> concepts that render as inverse of skos:broader triples. We only store
> these in one direction, and do so intentionally because having an inverse
> triple is just adding extra costs and drive up the maintenance burden as it
> is easy to get into situations where the two directions become out of
> synch. Therefore we strongly discourage using explicit inverse triples,
> instead preferring sh:inversePath declarations.
>
>
> Holger is 100% right on the “discourage using explicit inverse triples”
> idea. They are nearly impossible to keep synch’d and we have recent
> customer situations where we had to “undo” that mistake as part of a data
> model V2 and related data migration.
>
> In my personal opinion, introducing inverse properties with OWL was a
> major mistake, and it got unfortunately propagated into SKOS too. As RDF
> triples are symmetric between subjects and objects, and graphs can be
> walked in both directions equally.
>
>
> From a modeller’s perspective the main “good” reason to include inverse
> properties in SHACL it is so that the reverse property can have cardinality
> constraints. That need does pop up, so almost all data modelling
> languages/standards support the idea of inverse relations with cardinality.
> It’s not specific to RDF-land.
>
> Cheers,
> David
>
> Do you have downstream tools that require these explicit inverse triples?
>
>
> Holger
>
>
> On 16 Apr 2024, at 8:03 PM, Dan Segal  wrote:
>
> Is there a way to assert an inverse property into the source code of a
> concept?
>
> For example, where we have:
>
> *conceptScheme skos:hasTopConcept concept*
>
> we want to assert:
>
> *concept skos:topConceptOf conceptScheme*
>
> Since *skos:topConceptOf* is defined as the inverse of *skos:hasTopConcept,
> *the relationship displays in the form view.   However, we want to assert
> the statement so that the triple *concept skos:topConceptOf conceptScheme*
> is written to the RDF.
>
> Have tried a property rule, as well executing inference rules.  Neither
> results in the inverse relationship being written to RDF.
>
> Thank you
>
>
>
>
>
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/c4724215-481a-4c08-960b-7c29ffb16169n%40googlegroups.com
> 
> .
>
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/67C9D2F5-C581-4F8E-AB40-CEB3A897DCBB%40topquadrant.com
> 
> .
>
>
> --
> 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 

Re: [topbraid-users] Files only available from Studio

[Steve Ray]

I do have one request, since you are going to be building this new external
project anyway, and that is to upgrade your copy of QUDT to the latest
release. It is much improved. Feel free to send us feedback if there are
aspects that conflict with EDG in any manner.

Steve




On Mon, Mar 11, 2024 at 9:41 AM Holger Knublauch 
wrote:

> Ok, and with the custom "External" project, you could just maintain your
> own copy and replace it in one go?
>
> Holger
>
>
> On 11 Mar 2024, at 1:35 pm, Matt Goldberg  wrote:
>
> I suppose it technically could, but it might require exporting the graph
> first to make edits and it would require manually deleting each file
> individually every time there was an upgrade instead of just pushing a
> project.
>
> On Mon, Mar 11, 2024, 8:46 AM Holger Knublauch 
> wrote:
>
>> Ok, I am on it. One question (to everyone) though: it seems that the Base
>> URI Management page can already be used to delete individual files, even
>> from system projects. Why cannot that be used, followed by project upload,
>> to install custom versions of these graphs?
>>
>> Holger
>>
>>
>> On 10 Mar 2024, at 3:34 pm, Steveraysteveray 
>> wrote:
>>
>> I think moving QUDT into the dedicated project would be a great idea.
>>
>>
>> - Steve
>>
>> On Mar 10, 2024, at 8:50 AM, Holger Knublauch 
>> wrote:
>>
>> 
>>
>> On 9 Mar 2024, at 7:34 pm, steveray...@gmail.com <
>> steveraysteve...@gmail.com> wrote:
>>
>> Actually, QUDT only has the major version (currently 2.1) in the graph
>> URIs, and that hasn't changed in a few years. Furthermore, the individual
>> Units, QuantityKinds, etc. do not have a version in their URIs, so there
>> are still problems with collisions between the built-in units and loading a
>> more recent release.
>>
>>
>> I guess such collisions are not the fault of the namespace developers.
>> There is no need to change the URIs of all resources with each version.
>> Programming languages/APIs also don't do that as this would break things
>> all the time. Instead, users need to be clear about which version they
>> "compile against".
>>
>> Anyway, I have recorded a development ticket to look into moving these
>> external graphs into a dedicated workspace project, and that project could
>> then be deleted and replaced via project upload. I just need to identify
>> which graphs we are talking about. Maybe QUDT should also be moved into
>> that new project.
>>
>> The timing is good (now-or-never) as we are just about to finish our work
>> on TopBraid 8 which will have various other changes to the workspace anyway.
>>
>> Holger
>>
>>
>>
>> On Saturday, March 9, 2024 at 10:26:15 AM UTC-5 David Price wrote:
>>
>>> QUDT releases have version numbers in the URIs for their named graphs.
>>> So customers can load and use any release they want into EDG.
>>>
>>> We have a ticket in our services team to upgrade the DC and DC Terms
>>> collections, so hopefully the situation there will improve for the 8.0
>>> release. Turns out many public ontologies used then for class definitions,
>>> etc.
>>>
>>> Holger - I like option 1) very much. Different ontologies, annotations,
>>> etc are considered “common” in different industries and a “separate
>>> project” approach would even allow us to deliver, for example, an EDG Life
>>> Sciences vs EDG Finance project with tailored common graphs pre-included in
>>> the future.
>>>
>>> Cheers,
>>> David
>>>
>>> UK +44 (0) 7788 561308 <+44%207788%20561308>
>>> US +1 (336) 283-0808 <(336)%20283-0808>‬
>>>
>>> On 9 Mar 2024, at 11:36, Holger Knublauch 
>>> wrote:
>>>
>>> Ok thanks, Matt. I can certainly understand these problems with the
>>> pre-bundled files. I guess for QUDT we may have convinced you (before) to
>>> switch to asset collections, as this allows you to use different versions
>>> as they come out.
>>>
>>> But for the other bundled files such as dcterms the situation is not as
>>> easy. I just tried terms and indeed I see the warnings that you mention.
>>> This is not ideal and I wonder how to address this. Any solution that
>>> requires patching existing files is fragile. I guess you have found the
>>> work-around to add the missing triples already.
>>>
>>> To me this still sounds better than having to edit graphs that
>>> technically do not contain those extra triples. And even if you try to
>>> bypass the lack of the file editing through SPARQL injection or ADS, it
>>> still sounds fragile, error prone and would not work in cases like Data
>>> Platform where multiple copies exist in a network. And having to redo these
>>> changes after each TopBraid update is also not ideal.
>>>
>>> So what would be better solutions:
>>>
>>> 1) We could move all these external graphs into a separated project that
>>> users can delete/replace.
>>>
>>> 2) We could try to include modernized versions that better interact with
>>> SHACL. But in the case of dcterms, would people really want to see all
>>> these extra root classes under owl:Thing? Should they go under
>>> 

Re: [topbraid-users] Adding graphs to the Search the EDG Lucene index

[Steve Ray]

The added benefit of doing what Holger suggests is that you can keep up to
date with the monthly updates of QUDT at
https://github.com/qudt/qudt-public-repo/releases.
To avoid the confusion of duplicate URIs, though, you need to go into the
workspace and delete or rename the built-in QUDT files.

Steve




On Mon, Jan 22, 2024 at 8:50 AM Holger Knublauch 
wrote:

> Hi Matt,
>
> no, the infrastructure of Search the EDG is set up to operate on asset
> collections only. You would need to copy the content from QUDT into an
> Ontology and use that instead of the files.
>
> Holger
>
>
> On 22 Jan 2024, at 2:40 pm, Matt Goldberg  wrote:
>
> Hello-
>
> I'm wondering if it's possible to include graphs in the Lucene index that
> powers Search the EDG that are not Asset Collection graphs. For example,
> suppose I wanted to enable users to search the QUDT Units and Quantity
> Kinds graphs included with EDG.
>
> Thanks!
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/5f0d0817-e269-44fd-bb41-08a744d620fbn%40googlegroups.com
> 
> .
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/D5331E6B-5FBB-41F4-B202-03991AFF89B1%40topquadrant.com
> 
> .
>

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep86GdgpXKxUXmvmEssK3qj%3D9daQxF2J%2B7%2BtsX4pM-VPrfg%40mail.gmail.com.

Re: [topbraid-users] Composer EOL?

[Steve Ray]

One thing I really miss in EDG Studio is the ability to create (and
rearrange) a Graph View that shows instances in my data files with
occasional displays of rdf:types. I use such generated diagrams extensively
whenever presenting my work. Happy to show some examples if you like.

Steve




On Wed, Dec 6, 2023 at 8:12 AM Holger Knublauch 
wrote:

>
>
> On 6 Dec 2023, at 1:55 pm, Matt Goldberg  wrote:
>
> I'd be really disappointed if that were true. Composer is (in my opinion)
> by far the best general purpose RDF power user tool out there. EDG is
> great, but Composer is much better for quickly opening up files, inspecting
> them, and making edits at a low level. It's also much easier to deal with
> files in Git with Composer than with Studio.
>
>
> Thanks for your feedback. Leaving aside TBC for now, what are the
> obstacles to using Studio with Git right now? When you save files from
> Studio, they are also written with the sorted TTL writer. In fact I am
> entirely using Studio for all edits that I make to our own ontologies such
> as dash.
>
> For making edits at low level, note that the Source Code panel of Studio
> has a button to see and edit the whole graph at once. What else is TBC
> doing better?
>
> Holger
>
>
> I really wouldn't want to rely on Studio or have to go back to using
> Protege for tasks like that.
>
> On Wednesday, December 6, 2023 at 5:56:44 AM UTC-5 Bohms, H.M. (Michel)
> wrote:
>
>> In the same line: transition options incl. pricing would be very welcome,
>>
>> michel
>>
>>
>>
>> *From:* topbrai...@googlegroups.com  *On
>> Behalf Of *Jan Campschroer
>> *Sent:* woensdag 6 december 2023 11:46
>> *To:* TopBraid Suite Users 
>> *Subject:* [topbraid-users] Composer EOL?
>>
>>
>>
>> I heard the whisper that TB Composer is end of life? Is there some formal
>> communication about this?
>>
>>
>>
>> Grz Jan
>>
>> --
>> The topics of this mailing list include TopBraid EDG and related
>> technologies such as SHACL.
>> To post to this group, send email to topbrai...@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 topbraid-user...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/topbraid-users/de98f211-1b86-4c6a-983d-73382c62e32en%40googlegroups.com
>> 
>> .
>>
>> This message may contain information that is not intended for you. If you
>> are not the addressee or if this message was sent to you by mistake, you
>> are requested to inform the sender and delete the message. TNO accepts no
>> liability for the content of this e-mail, for the manner in which you use
>> it and for damage of any kind resulting from the risks inherent to the
>> electronic transmission of messages.
>>
>>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/6348f836-0f08-4fbc-a56a-ba1c5979eca8n%40googlegroups.com
> 
> .
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/7A5AA147-C011-4D04-AF9D-62629F39529E%40topquadrant.com
> 
> .
>

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Re: [topbraid-users] Does sh:severity sh:Info not work with SPARQLConstraints in a NodeShape?

[Steve Ray]

Thanks for the push in the right direction. I ran into problems attaching
it to MyClass using sh:node, but it worked properly by defining a shape and
using sh:targetClass.

It kept the other constraint as a violation, and my new constraint as
sh:Info.


Steve




On Thu, Jul 13, 2023 at 4:42 PM Holger Knublauch 
wrote:

> Have you tried attaching the sh:severity to the surrounding shape/class?
> That should do it. If you don’t want to put it into the class itself, you
> could create an in-between node shape and link it to the class using
> sh:node.
>
> Holger
>
>
> On 13 Jul 2023, at 9:33 pm, Steve Ray  wrote:
>
> I am successfully using sh:Info inside PropertyShapes with
> SPARQLConstraints, but the particular constraint I'm working on is for any
> property, so I am using a NodeShape.
>
> I have tried specifying sh:Info, but TBC-ME keeps showing my violating
> SPARQLConstraint as a full-on violation rather than an sh:Info.
>
> Sample code pattern:
> ex:MyClass
> sh:sparql [
> a sh:SPARQLConstraint ;
> sh:message "My message" ;
> sh:severity sh:Info ;
> sh:prefixes <http://relevantURI <http://relevanturi/>> ;
> sh:select """
> SELECT $this ...
> WHERE {
> ...
> """ ;
> ] ;
>
> MyClass is defined elsewhere as a sh:NodeShape
> MyClass has several SPARQLConstraints, so I want this one to be sh:Info
> and the other one to be the default (sh:Violation).
>
> What am I doing wrong?
>
> Steve
>
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CAGUep85YJy_CkvWGWcpfi9YeTMXCLrBuvrJbO8o-BkXJH7%2B18w%40mail.gmail.com
> <https://groups.google.com/d/msgid/topbraid-users/CAGUep85YJy_CkvWGWcpfi9YeTMXCLrBuvrJbO8o-BkXJH7%2B18w%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/28CDEB5F-51C7-4C69-9580-F26965355028%40topquadrant.com
> <https://groups.google.com/d/msgid/topbraid-users/28CDEB5F-51C7-4C69-9580-F26965355028%40topquadrant.com?utm_medium=email_source=footer>
> .
>

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep87zdSmOogoBgotAbf3z87aV3trRXhXbr5NZyzXyf%2BS5%2Bw%40mail.gmail.com.

[topbraid-users] Does sh:severity sh:Info not work with SPARQLConstraints in a NodeShape?

[Steve Ray]

I am successfully using sh:Info inside PropertyShapes with
SPARQLConstraints, but the particular constraint I'm working on is for any
property, so I am using a NodeShape.

I have tried specifying sh:Info, but TBC-ME keeps showing my violating
SPARQLConstraint as a full-on violation rather than an sh:Info.

Sample code pattern:
ex:MyClass
sh:sparql [
a sh:SPARQLConstraint ;
sh:message "My message" ;
sh:severity sh:Info ;
sh:prefixes  ;
sh:select """
SELECT $this ...
WHERE {
...
""" ;
] ;

MyClass is defined elsewhere as a sh:NodeShape
MyClass has several SPARQLConstraints, so I want this one to be sh:Info and
the other one to be the default (sh:Violation).

What am I doing wrong?

Steve

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep85YJy_CkvWGWcpfi9YeTMXCLrBuvrJbO8o-BkXJH7%2B18w%40mail.gmail.com.

Re: [topbraid-users] Iterative SHACL reasoning

[Steve Ray]

Thanks for the fast response. My question, though, is the following:

Given rules with sh:order of 1,2,3, in an iterative environment, do I get:
(Next iteration marked with /)

1, / 1, / 1, 2, / 1, / 1, 2, 3 / ...

or

1, 2, 3, / 1, 2, 3, / 1, 2, 3...

Steve




On Fri, May 26, 2023 at 10:06 AM Holger Knublauch 
wrote:

>
>
> On 26 May 2023, at 2:59 pm, Steve Ray  wrote:
>
> I note that in the SHACL AF spec (2021) it states, with regard to the use
> of sh:order:
>
> *Note that this algorithm only covers a single "iteration" over all rules,
> without prescribing the behavior if the same rule needs to be applied
> multiple times after other rules have fired.*
>
> My question is, how does TBC handle rule order during iterative reasoning?
> Let's suppose I have a set of rules I want to run iteratively to
> completion, and after that, run a second set of rules iteratively to
> completion. Back in the SPIN days, I defined "waves" to accomplish this.
>
>
> The official spec didn't want to go into these details, but the TopBraid
> iteration will also loop until a fixpoint was reached. Rule order is then
> used in each round.
>
> In TopBraid EDG, the Inferences panel has a setting to enable this
> iterative process.
>
> Holger
>
>
>
> Any advice?
>
> Steve
>
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CAGUep85C7L4LxQnTp9h%3D6rS3SWUVxQC4yNnKxUx9%3D25cBomjjQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/topbraid-users/CAGUep85C7L4LxQnTp9h%3D6rS3SWUVxQC4yNnKxUx9%3D25cBomjjQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/F29B2186-E9BD-4A95-B6D5-9B1ADCCFC135%40topquadrant.com
> <https://groups.google.com/d/msgid/topbraid-users/F29B2186-E9BD-4A95-B6D5-9B1ADCCFC135%40topquadrant.com?utm_medium=email_source=footer>
> .
>

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep87wxhSNH6g81TuMx8zvEjBX-GFcjX4VMVoRzFt92fH74w%40mail.gmail.com.

[topbraid-users] Iterative SHACL reasoning

[Steve Ray]

I note that in the SHACL AF spec (2021) it states, with regard to the use
of sh:order:

*Note that this algorithm only covers a single "iteration" over all rules,
without prescribing the behavior if the same rule needs to be applied
multiple times after other rules have fired.*

My question is, how does TBC handle rule order during iterative reasoning?
Let's suppose I have a set of rules I want to run iteratively to
completion, and after that, run a second set of rules iteratively to
completion. Back in the SPIN days, I defined "waves" to accomplish this.

Any advice?

Steve

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep85C7L4LxQnTp9h%3D6rS3SWUVxQC4yNnKxUx9%3D25cBomjjQ%40mail.gmail.com.

Re: [topbraid-users] Some questions about EDG Studio vs. TBC-ME

[Steve Ray]

All my rules are of the form:

sh:rule [
a sh:TripleRule ;
sh:object [ ...
sh:predicate ...
sh:subject ...
]

or

sh:rule [
a sh:SPARQLRule ;
sh:construct """...
]

I see how to replace the TripleRule syntax with

sh:property [
sh:path ...
sh:values [

for the SPARQL, what's the syntax? I didn't see an example in the spec.
Is it:

sh:property [
sh:path ...
sh:values [ sh:rule [ a sh:SPARQLRule ...

Regardless, the sh:rule use represents our one departure from the official
SHACL spec. , so I need to be cognizant that some people are using
pySHACL or other implementations).

Also, we often want to view the graph without any inference - representing
a "compact" form for data exchange, to be expanded through inferencing at
the receiving end.
Can the automatic inferencing be turned on or off in both TBC-ME and EDG?


P.S. Regarding my original questions, I still don't understand what
controls the Expand Node/Show Neighborhood choice for instances. In my
tests, some instance relations are showing up but most are not.


Steve




On Thu, Jun 30, 2022 at 10:08 AM Holger Knublauch 
wrote:

> Out of interest, can some of your inferences be expressed using sh:values
> rules? In EDG (and Studio) those would be shown directly on forms and
> executed continuously (without being asserted). Note that if you want to
> express your rules in SPARQL you can also still do that in sh:values rules.
>
> Holger
>
>
>
> On 29 Jun 2022, at 9:39 am, Steve Ray  wrote:
>
> Hi,
> I'm gingerly testing out moving over to EDG Studio, and am having trouble
> recreating some of the things I used to do in TBC-ME. Are they possible in
> Studio, and if so, how?
>
> 1. Run the SHACL reasoner iteratively until no new triples are generated.
> (The only way I have found to do this is to repeatedly press the "Execute
> rules" button myself. Ouch)
>
> 2. Run the SHACL reasoner but not assert the results. I really liked the
> "purple display" of the inferred triples in TBC-ME, which made it simple
> for me to see what I had created vs. what was inferred. Is there some
> alternative way to distinguish the two in Studio?
>
> 3. Anything approximating the "Graph" view for instances.
>
> Thanks!
>
> Steve
>
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CAGUep86CKrorYwmtqtr2UA5R2yT8URba7WGpU3CsCME3d8Sg0w%40mail.gmail.com
> <https://groups.google.com/d/msgid/topbraid-users/CAGUep86CKrorYwmtqtr2UA5R2yT8URba7WGpU3CsCME3d8Sg0w%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/1B066EE8-EFFD-43E4-B802-A42DF566065F%40topquadrant.com
> <https://groups.google.com/d/msgid/topbraid-users/1B066EE8-EFFD-43E4-B802-A42DF566065F%40topquadrant.com?utm_medium=email_source=footer>
> .
>

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep86wC7pORwufBgEVH99A%3D8%3DNQzT%3D_tNUCguh4fW9sPhqWg%40mail.gmail.com.

Re: [topbraid-users] Some questions about EDG Studio vs. TBC-ME

[Steve Ray]

Thanks, David! Very helpful.
The Inferences Panel really helps. Not quite as intuitive as the purple
highlights in TBC-ME, but workable.

The only thing that isn't working now is within the EDG Diagram, when I am
displaying an *instance*, to ask it to draw all the associated *instances*.
The only way I can get close is by manually dragging each associated
instance from the Form panel into the EDG Diagram. (Choosing "Include
inherited properties" seems to affect the way classes are displayed, but
not instances). Am I missing something?

Steve




On Wed, Jun 29, 2022 at 9:57 AM David Price  wrote:

> Hi Steve,
>
> On 29 Jun 2022, at 14:39, Steve Ray  wrote:
>
> Hi,
> I'm gingerly testing out moving over to EDG Studio, and am having trouble
> recreating some of the things I used to do in TBC-ME. Are they possible in
> Studio, and if so, how?
>
> 1. Run the SHACL reasoner iteratively until no new triples are generated.
> (The only way I have found to do this is to repeatedly press the "Execute
> rules" button myself. Ouch)
>
>
> Use gear drop-down in Inferences Panel. Same as TBC.,
>
>
> 2. Run the SHACL reasoner but not assert the results. I really liked the
> "purple display" of the inferred triples in TBC-ME, which made it simple
> for me to see what I had created vs. what was inferred. Is there some
> alternative way to distinguish the two in Studio?
>
>
> This is how Inferences Panel works now. Then use ! to assert them.
> Transform can also run rules and auto-asserts but then lets you roll back.
>
>
> 3. Anything approximating the "Graph" view for instances.
>
>
> Show EDG Diagram from Explore menu.
>
> Cheers,
> David
>
>
> Thanks!
>
> Steve
>
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CAGUep86CKrorYwmtqtr2UA5R2yT8URba7WGpU3CsCME3d8Sg0w%40mail.gmail.com
> <https://groups.google.com/d/msgid/topbraid-users/CAGUep86CKrorYwmtqtr2UA5R2yT8URba7WGpU3CsCME3d8Sg0w%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/D151DBE3-6D7C-4BDB-B2A7-E2BE834FBA4B%40topquadrant.com
> <https://groups.google.com/d/msgid/topbraid-users/D151DBE3-6D7C-4BDB-B2A7-E2BE834FBA4B%40topquadrant.com?utm_medium=email_source=footer>
> .
>

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep86_TEns40YeimO74wAU6Y0KBO%2Bi6EJfekxnRcdrwPKtrg%40mail.gmail.com.

[topbraid-users] Some questions about EDG Studio vs. TBC-ME

[Steve Ray]

Hi,
I'm gingerly testing out moving over to EDG Studio, and am having trouble
recreating some of the things I used to do in TBC-ME. Are they possible in
Studio, and if so, how?

1. Run the SHACL reasoner iteratively until no new triples are generated.
(The only way I have found to do this is to repeatedly press the "Execute
rules" button myself. Ouch)

2. Run the SHACL reasoner but not assert the results. I really liked the
"purple display" of the inferred triples in TBC-ME, which made it simple
for me to see what I had created vs. what was inferred. Is there some
alternative way to distinguish the two in Studio?

3. Anything approximating the "Graph" view for instances.

Thanks!

Steve

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep86CKrorYwmtqtr2UA5R2yT8URba7WGpU3CsCME3d8Sg0w%40mail.gmail.com.

Re: [topbraid-users] IO.serializeRDF

[Steve Ray]

Holger, in case it helps, here's the service I defined.


qudt:TurtleSnippet

  rdf:type dash:ResourceService ;

  dash:js """function collectTriples(subject, triples) {

graph.triples(subject, null, null, true).forEach(t => {

triples.push(t);

if(t.object.isBlankNode()) {

collectTriples(t.object, triples);

}

})

}


let triples = [];

collectTriples(focusNode, triples);

IO.serializeRDF(triples);""" ;

  dash:responseContentType "text/turtle" ;

  rdfs:label "Turtle Snippet" ;

.



Steve




On Thu, Jun 23, 2022 at 7:05 PM Holger Knublauch 
wrote:

>
> On 2022-06-24 12:36 am, Steve Ray wrote:
>
> Hi,
> I have until recently been successfully using IO.serializeRDF in a
> dash:ResourceService. I'm running TBC-ME 7.0 for reasons I will explain
> below.
> However, I'm now getting an error message when I call it. My current
> hypothesis:
> 1. The EDG collection that contains my code used to also include a graph
> "DASH Data Shapes Vocabulary", but the last time I rebuilt my workspace,
> that graph mysteriously no longer appears in the available graphs to
> include. Is it possible that IO.serializeRDF is thus not visible?
>
> To check whether dash is really not imported you could run a query such as
>
> SELECT DISTINCT ?g { ?x owl:imports ?g }
>
> in the SPARQL query panel. Under normal circumstances there is always some
> subgraph in your EDG graphs that will owl:import dash.
>
> Even if not, IO.serializeRDF should be there. I checked that it was
> introduced with TB 7.0.0.
>
> What error message do you get when you invoke it?
>
> In a possibly related problem, I also no longer see
> teamwork.topbraidlive.org in my TBC-ME workspace in versions higher than
> 7.0, and my SWP scripts depended on it. Hence, until I figure out how to
> adapt, I am stuck running 7.0 for my services.
>
> Yeah, TBC 7.1 had been further simplified and decoupled from EDG. If
> you're a typical TBC user that has used TBC for a long time, there is
> really no reason to upgrade to that version.
>
> For the latest features such as ADS improvements, EDG Studio is a much
> better choice as it evolves alongside the EDG product. However that
> requires a different license altogether.
>
> Holger
>
>
> Help, please!
>
>
> Steve
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CAGUep87iDuzZ2P1%3DYn05XKDaXAfAZKxz5mv4amsBfOZ%3DRfX1Fw%40mail.gmail.com
> <https://groups.google.com/d/msgid/topbraid-users/CAGUep87iDuzZ2P1%3DYn05XKDaXAfAZKxz5mv4amsBfOZ%3DRfX1Fw%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/642c2262-9d60-a8d6-91a7-8a50112115e6%40topquadrant.com
> <https://groups.google.com/d/msgid/topbraid-users/642c2262-9d60-a8d6-91a7-8a50112115e6%40topquadrant.com?utm_medium=email_source=footer>
> .
>

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep84HKBsFSfUErmeajjuT53JY7h3hc5E8nQ%3DiActv5rfvWA%40mail.gmail.com.

Re: [topbraid-users] IO.serializeRDF

[Steve Ray]

Holger,
Here's the error message I receive (I'm using Postman to send the web
service request)

Cannot evaluate Script:org.topbraid.core.servlet.HttpErrorException: Failed
service request /qudt_owl_schema/qudt/TurtleSnippet/URI/
http://qudt.org/schema/qudt/Unit: TypeError: (intermediate
value).serializeRDF is not a function

I have attached a json file containing the results of the owl:imports query
you suggested. You will see I added a few extra EDG graphs in the hope of
bringing in io.serializeRDF. I don't see any dash graph, except for the
GraphQL one.

Finally, I also just did a recursive search of my workspace to see if I
could find any occurrence of "serializeRDF" that yielded zero hits. Where
does the function definition reside?

Steve




On Thu, Jun 23, 2022 at 7:05 PM Holger Knublauch 
wrote:

>
> On 2022-06-24 12:36 am, Steve Ray wrote:
>
> Hi,
> I have until recently been successfully using IO.serializeRDF in a
> dash:ResourceService. I'm running TBC-ME 7.0 for reasons I will explain
> below.
> However, I'm now getting an error message when I call it. My current
> hypothesis:
> 1. The EDG collection that contains my code used to also include a graph
> "DASH Data Shapes Vocabulary", but the last time I rebuilt my workspace,
> that graph mysteriously no longer appears in the available graphs to
> include. Is it possible that IO.serializeRDF is thus not visible?
>
> To check whether dash is really not imported you could run a query such as
>
> SELECT DISTINCT ?g { ?x owl:imports ?g }
>
> in the SPARQL query panel. Under normal circumstances there is always some
> subgraph in your EDG graphs that will owl:import dash.
>
> Even if not, IO.serializeRDF should be there. I checked that it was
> introduced with TB 7.0.0.
>
> What error message do you get when you invoke it?
>
> In a possibly related problem, I also no longer see
> teamwork.topbraidlive.org in my TBC-ME workspace in versions higher than
> 7.0, and my SWP scripts depended on it. Hence, until I figure out how to
> adapt, I am stuck running 7.0 for my services.
>
> Yeah, TBC 7.1 had been further simplified and decoupled from EDG. If
> you're a typical TBC user that has used TBC for a long time, there is
> really no reason to upgrade to that version.
>
> For the latest features such as ADS improvements, EDG Studio is a much
> better choice as it evolves alongside the EDG product. However that
> requires a different license altogether.
>
> Holger
>
>
> Help, please!
>
>
> Steve
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CAGUep87iDuzZ2P1%3DYn05XKDaXAfAZKxz5mv4amsBfOZ%3DRfX1Fw%40mail.gmail.com
> <https://groups.google.com/d/msgid/topbraid-users/CAGUep87iDuzZ2P1%3DYn05XKDaXAfAZKxz5mv4amsBfOZ%3DRfX1Fw%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/642c2262-9d60-a8d6-91a7-8a50112115e6%40topquadrant.com
> <https://groups.google.com/d/msgid/topbraid-users/642c2262-9d60-a8d6-91a7-8a50112115e6%40topquadrant.com?utm_medium=email_source=footer>
> .
>

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep87fSTNaJ8vZTcPhJ4s_j%3DAqcLFM0T42ZXbKMVigjLnJgQ%40mail.gmail.com.


export.json
Description: application/json

Re: [topbraid-users] Confirming a slight disappointment

[Steve Ray]

Ah, very clever! I didn't think of using the sh:path side instead.

Steve




On Tue, Mar 1, 2022 at 1:14 PM Holger Knublauch 
wrote:

> Yes your observation is correct. In this case you can formulate it the
> other way around, with the expression as sh:path and hasDomain as
> sh:equals. Or, of course, use SPARQL directly.
>
> But a SHACL 1.1 WG will almost certainly generalise this to allow paths in
> both places. (And it would rename the property to sh:equalProperty because
> many users misinterpret the name).
>
> Holger
>
>
>
> On 2 Mar 2022, at 4:47 am, Steve Ray  wrote:
>
> I was trying to use sh:equals in a property shape as follows:
>
>sh:property [
>sh:path s223:hasDomain ;
>sh:class s223:Domain ;
>sh:maxCount 1 ;
>sh:minCount 1 ;
>sh:equals ( s223:isContainedIn s223:hasDomain ) ;
>  ] ;
>
> ...and discovered to my disappointment that I cannot use a property path
> as the value of sh:equals. I do see that the SHACL spec says it must be an
> IRI, but it seems so natural to be able to validate using a property path
> here. Was there a reason it is limited to an IRI?
>
> Steve
>
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CAGUep85b3A-j%3DfjJSYNUpjbSsr9Ge4ffNO5DqcNuBJv4HBmn1Q%40mail.gmail.com
> <https://groups.google.com/d/msgid/topbraid-users/CAGUep85b3A-j%3DfjJSYNUpjbSsr9Ge4ffNO5DqcNuBJv4HBmn1Q%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/D63F9A4D-B965-4DA2-BCAD-9D195E19AD3D%40topquadrant.com
> <https://groups.google.com/d/msgid/topbraid-users/D63F9A4D-B965-4DA2-BCAD-9D195E19AD3D%40topquadrant.com?utm_medium=email_source=footer>
> .
>

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep87Aa66kSprDxnHUaioeDOmHMqaWUMk2gOmgjb5NdL%3DfdQ%40mail.gmail.com.

[topbraid-users] Confirming a slight disappointment

[Steve Ray]

I was trying to use sh:equals in a property shape as follows:

   sh:property [
   sh:path s223:hasDomain ;
   sh:class s223:Domain ;
   sh:maxCount 1 ;
   sh:minCount 1 ;
   sh:equals ( s223:isContainedIn s223:hasDomain ) ;
 ] ;

...and discovered to my disappointment that I cannot use a property path as
the value of sh:equals. I do see that the SHACL spec says it must be an
IRI, but it seems so natural to be able to validate using a property path
here. Was there a reason it is limited to an IRI?

Steve

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep85b3A-j%3DfjJSYNUpjbSsr9Ge4ffNO5DqcNuBJv4HBmn1Q%40mail.gmail.com.

[topbraid-users] Trying out moving to EDG Studio

[Steve Ray]

With 7.1 I can no longer run my SWA scripts to generate Web pages, so I am
gingerly stepping into experimenting with EDG Studio. A few questions:

After getting Studio running, I uploaded the projects that I think I need,
using the Server Administration button. Previously, the local EDG
server/TBL server could see everything in the TBC workspace. Is this the
right first step? Alternatively, should I be doing this with the Files
button in EDG?

Next problem: I tried a simple command from a terminal window as follows,
and got an authentication error:
curl -X GET -G
http://localhost:8083/tbl/service/qudt_owl_schema/qudt/listAllDefinitions
No user is logged in%

I'm logged in to the Studio UI as Administrator. Do I need to provide
credentials in the curl call? Is the call still to ...tbl/service...?

Is there any documentation for migrating SWA services to Studio? I didn't
see anything specific to Studio for SWA.

Thanks,
Steve

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep86NdDG%3DHXG-HTw3JWfMnRokVzomJvHacRzSZjYte63dfw%40mail.gmail.com.

Re: [topbraid-users] The Manage-Delete and Manage-Clear menu options have disappeared

[Steve Ray]

That setting is indeed set.
[image: image.png]
That was the issue, because I just tried setting it on my new collection
and the options again disappeared. Somehow, I had been trying to configure
things so that users with view only permissions could not make changes to
the ontology. I suppose that is already enforced by virtue of the view role?


Steve




On Thu, Dec 16, 2021 at 1:21 PM Taryn Madey  wrote:

> There is a setting for read-only on the manage tab. If checked then those
> options are removed. The collection should also be read-only in the editor.
> Is this the issue?
>
> On Thu, Dec 16, 2021 at 4:11 PM Steve Ray  wrote:
>
>> Yes, the menu options appear with a new ontology.
>> Any way to repair the existing one, or should I just recreate it?
>>
>> Steve
>>
>>
>>
>>
>> On Thu, Dec 16, 2021 at 1:09 PM Irene Polikoff 
>> wrote:
>>
>>> I don’t think it is related to permissions.
>>>
>>> Try creating a new ontology to see if features appear there.
>>>
>>> On Dec 16, 2021, at 3:54 PM, Steve Ray  wrote:
>>>
>>> ...and here's a view of the EDG Permissions page, showing the
>>> SHACL Schema Customizations collection, which is the ontology
>>>
>>> 
>>> Steve
>>>
>>>
>>>
>>>
>>> On Thu, Dec 16, 2021 at 12:45 PM Irene Polikoff 
>>> wrote:
>>>
>>>> If it was a permissions problem, Steve would not be able to see the
>>>> Manage tab.
>>>>
>>>> As David said, all these options are still there. I can’t think of a
>>>> reason as to why they would not be shown other than someone deactivated
>>>> them for this asset collection by using Manage>Configure Features.
>>>>
>>>> However, such disabling has no effect on the Administrator user, they
>>>> would still see all the features. A more “permanent” disabling could be
>>>> done in SWP code.
>>>>
>>>> On Dec 16, 2021, at 2:20 PM, David Price 
>>>> wrote:
>>>>
>>>> That sounds like a permissions problem where you do not have Editor or
>>>> Manager privileges OR maybe you need to clear browser cache as you have a
>>>> mix of old and new EDG JS code running.
>>>>
>>>> Manage/Clear and Manage/Delete are still there.
>>>>
>>>> There was never a Settings/Import feature so not sure what you mean
>>>> with that - Settings/Includes perhaps?
>>>>
>>>> Imports is a tab on its own with Import RDF File, etc.
>>>>
>>>> Cheers,
>>>> David
>>>>
>>>> On 16 Dec 2021, at 19:05, Steve Ray  wrote:
>>>>
>>>> Admittedly, it was July that I last updated one of our EDG Collections,
>>>> but when I went to update it today (now using EDG 7.0.3) I no longer find
>>>> the Manage-Clear menu option, which I used to use before, followed by
>>>> Settings-Import to upload the latest version (also no longer present).
>>>>
>>>> I have looked through the 7.0 documentation but clearly not in the
>>>> right place, because I can't find how I'm supposed to do this now. Could
>>>> you point me to the right document?
>>>>
>>>> Thanks,
>>>>
>>>> Steve
>>>>
>>>>
>>>>
>>>> --
>>>> 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 topbraid-users+unsubscr...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/topbraid-users/CAGUep87oTST1i2v3vb1zejXHECHqK7kD-e3dZTw2BS7MQtrd2g%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/topbraid-users/CAGUep87oTST1i2v3vb1zejXHECHqK7kD-e3dZTw2BS7MQtrd2g%40mail.gmail.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>>
>>>> UK +44 (0) 7788 561308
>>>> US +1 (336) 283-0808‬
>>>>
>>>>
>>>> --
>>>> 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 topbraid-users+unsubscr...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.

Re: [topbraid-users] The Manage-Delete and Manage-Clear menu options have disappeared

[Steve Ray]

Yes, the menu options appear with a new ontology.
Any way to repair the existing one, or should I just recreate it?

Steve




On Thu, Dec 16, 2021 at 1:09 PM Irene Polikoff 
wrote:

> I don’t think it is related to permissions.
>
> Try creating a new ontology to see if features appear there.
>
> On Dec 16, 2021, at 3:54 PM, Steve Ray  wrote:
>
> ...and here's a view of the EDG Permissions page, showing the SHACL Schema
> Customizations collection, which is the ontology
>
> 
> Steve
>
>
>
>
> On Thu, Dec 16, 2021 at 12:45 PM Irene Polikoff 
> wrote:
>
>> If it was a permissions problem, Steve would not be able to see the
>> Manage tab.
>>
>> As David said, all these options are still there. I can’t think of a
>> reason as to why they would not be shown other than someone deactivated
>> them for this asset collection by using Manage>Configure Features.
>>
>> However, such disabling has no effect on the Administrator user, they
>> would still see all the features. A more “permanent” disabling could be
>> done in SWP code.
>>
>> On Dec 16, 2021, at 2:20 PM, David Price  wrote:
>>
>> That sounds like a permissions problem where you do not have Editor or
>> Manager privileges OR maybe you need to clear browser cache as you have a
>> mix of old and new EDG JS code running.
>>
>> Manage/Clear and Manage/Delete are still there.
>>
>> There was never a Settings/Import feature so not sure what you mean with
>> that - Settings/Includes perhaps?
>>
>> Imports is a tab on its own with Import RDF File, etc.
>>
>> Cheers,
>> David
>>
>> On 16 Dec 2021, at 19:05, Steve Ray  wrote:
>>
>> Admittedly, it was July that I last updated one of our EDG Collections,
>> but when I went to update it today (now using EDG 7.0.3) I no longer find
>> the Manage-Clear menu option, which I used to use before, followed by
>> Settings-Import to upload the latest version (also no longer present).
>>
>> I have looked through the 7.0 documentation but clearly not in the right
>> place, because I can't find how I'm supposed to do this now. Could you
>> point me to the right document?
>>
>> Thanks,
>>
>> Steve
>>
>>
>>
>> --
>> 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 topbraid-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/topbraid-users/CAGUep87oTST1i2v3vb1zejXHECHqK7kD-e3dZTw2BS7MQtrd2g%40mail.gmail.com
>> <https://groups.google.com/d/msgid/topbraid-users/CAGUep87oTST1i2v3vb1zejXHECHqK7kD-e3dZTw2BS7MQtrd2g%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>>
>> UK +44 (0) 7788 561308
>> US +1 (336) 283-0808‬
>>
>>
>> --
>> 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 topbraid-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/topbraid-users/992E5A34-8923-47F2-91FC-7C787828160C%40topquadrant.com
>> <https://groups.google.com/d/msgid/topbraid-users/992E5A34-8923-47F2-91FC-7C787828160C%40topquadrant.com?utm_medium=email_source=footer>
>> .
>>
>>
>>
>> --
>> 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 topbraid-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/topbraid-users/0CEEDA38-2DBD-41C1-AC75-462867B81B30%40topquadrant.com
>> <https://groups.google.com/d/msgid/topbraid-users/0CEEDA38-2DBD-41C1-AC75-462867B81B30%40topquadrant.com?utm_medium=email_source=footer>
>> .
>>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CAGUep86WJLgPExyQC4ZnXW_ggonB0DfUmYOC7G%3DigOsEONg3ww%40mail.gmail.com
> <https://groups.google.com/d/msgid/topbraid-users/CAGUep86WJLgPExyQC4ZnXW_ggonB0DfUmYO

Re: [topbraid-users] The Manage-Delete and Manage-Clear menu options have disappeared

[Steve Ray]

...and here's a view of the EDG Permissions page, showing the SHACL Schema
Customizations collection, which is the ontology

[image: image.png]
Steve




On Thu, Dec 16, 2021 at 12:45 PM Irene Polikoff 
wrote:

> If it was a permissions problem, Steve would not be able to see the Manage
> tab.
>
> As David said, all these options are still there. I can’t think of a
> reason as to why they would not be shown other than someone deactivated
> them for this asset collection by using Manage>Configure Features.
>
> However, such disabling has no effect on the Administrator user, they
> would still see all the features. A more “permanent” disabling could be
> done in SWP code.
>
> On Dec 16, 2021, at 2:20 PM, David Price  wrote:
>
> That sounds like a permissions problem where you do not have Editor or
> Manager privileges OR maybe you need to clear browser cache as you have a
> mix of old and new EDG JS code running.
>
> Manage/Clear and Manage/Delete are still there.
>
> There was never a Settings/Import feature so not sure what you mean with
> that - Settings/Includes perhaps?
>
> Imports is a tab on its own with Import RDF File, etc.
>
> Cheers,
> David
>
> On 16 Dec 2021, at 19:05, Steve Ray  wrote:
>
> Admittedly, it was July that I last updated one of our EDG Collections,
> but when I went to update it today (now using EDG 7.0.3) I no longer find
> the Manage-Clear menu option, which I used to use before, followed by
> Settings-Import to upload the latest version (also no longer present).
>
> I have looked through the 7.0 documentation but clearly not in the right
> place, because I can't find how I'm supposed to do this now. Could you
> point me to the right document?
>
> Thanks,
>
> Steve
>
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CAGUep87oTST1i2v3vb1zejXHECHqK7kD-e3dZTw2BS7MQtrd2g%40mail.gmail.com
> <https://groups.google.com/d/msgid/topbraid-users/CAGUep87oTST1i2v3vb1zejXHECHqK7kD-e3dZTw2BS7MQtrd2g%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>
> UK +44 (0) 7788 561308
> US +1 (336) 283-0808‬
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/992E5A34-8923-47F2-91FC-7C787828160C%40topquadrant.com
> <https://groups.google.com/d/msgid/topbraid-users/992E5A34-8923-47F2-91FC-7C787828160C%40topquadrant.com?utm_medium=email_source=footer>
> .
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/0CEEDA38-2DBD-41C1-AC75-462867B81B30%40topquadrant.com
> <https://groups.google.com/d/msgid/topbraid-users/0CEEDA38-2DBD-41C1-AC75-462867B81B30%40topquadrant.com?utm_medium=email_source=footer>
> .
>

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep86WJLgPExyQC4ZnXW_ggonB0DfUmYOC7G%3DigOsEONg3ww%40mail.gmail.com.

Re: [topbraid-users] The Manage-Delete and Manage-Clear menu options have disappeared

[Steve Ray]

I looked at the Manage>Configure Features page, and every feature is
enabled for this collection.

I just tried looking at some of my Data Graph collections, and indeed, the
Manage>Clear and Manage>Delete options are there, as is the Import tab. So
it is something to do with the (one) Ontology collection we have, but not
the Data Graphs.

Steve




On Thu, Dec 16, 2021 at 12:45 PM Irene Polikoff 
wrote:

> If it was a permissions problem, Steve would not be able to see the Manage
> tab.
>
> As David said, all these options are still there. I can’t think of a
> reason as to why they would not be shown other than someone deactivated
> them for this asset collection by using Manage>Configure Features.
>
> However, such disabling has no effect on the Administrator user, they
> would still see all the features. A more “permanent” disabling could be
> done in SWP code.
>
> On Dec 16, 2021, at 2:20 PM, David Price  wrote:
>
> That sounds like a permissions problem where you do not have Editor or
> Manager privileges OR maybe you need to clear browser cache as you have a
> mix of old and new EDG JS code running.
>
> Manage/Clear and Manage/Delete are still there.
>
> There was never a Settings/Import feature so not sure what you mean with
> that - Settings/Includes perhaps?
>
> Imports is a tab on its own with Import RDF File, etc.
>
> Cheers,
> David
>
> On 16 Dec 2021, at 19:05, Steve Ray  wrote:
>
> Admittedly, it was July that I last updated one of our EDG Collections,
> but when I went to update it today (now using EDG 7.0.3) I no longer find
> the Manage-Clear menu option, which I used to use before, followed by
> Settings-Import to upload the latest version (also no longer present).
>
> I have looked through the 7.0 documentation but clearly not in the right
> place, because I can't find how I'm supposed to do this now. Could you
> point me to the right document?
>
> Thanks,
>
> Steve
>
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CAGUep87oTST1i2v3vb1zejXHECHqK7kD-e3dZTw2BS7MQtrd2g%40mail.gmail.com
> <https://groups.google.com/d/msgid/topbraid-users/CAGUep87oTST1i2v3vb1zejXHECHqK7kD-e3dZTw2BS7MQtrd2g%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>
> UK +44 (0) 7788 561308
> US +1 (336) 283-0808‬
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/992E5A34-8923-47F2-91FC-7C787828160C%40topquadrant.com
> <https://groups.google.com/d/msgid/topbraid-users/992E5A34-8923-47F2-91FC-7C787828160C%40topquadrant.com?utm_medium=email_source=footer>
> .
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/0CEEDA38-2DBD-41C1-AC75-462867B81B30%40topquadrant.com
> <https://groups.google.com/d/msgid/topbraid-users/0CEEDA38-2DBD-41C1-AC75-462867B81B30%40topquadrant.com?utm_medium=email_source=footer>
> .
>

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep86tmipnV%2BTUc5UgnHQ_cYK_KSNRO-moU-XNzbOch1O4Tg%40mail.gmail.com.

Re: [topbraid-users] The Manage-Delete and Manage-Clear menu options have disappeared

[Steve Ray]

Interesting. I logged into our server as the administrator, which always
worked before. Also tried with Chrome and Safari in case of caching. No
dice.
Do you think a restart of EDG would work? Or even more nuclear, a reboot of
our server?

I'll keep digging...

Steve




On Thu, Dec 16, 2021 at 11:20 AM David Price  wrote:

> That sounds like a permissions problem where you do not have Editor or
> Manager privileges OR maybe you need to clear browser cache as you have a
> mix of old and new EDG JS code running.
>
> Manage/Clear and Manage/Delete are still there.
>
> There was never a Settings/Import feature so not sure what you mean with
> that - Settings/Includes perhaps?
>
> Imports is a tab on its own with Import RDF File, etc.
>
> Cheers,
> David
>
> On 16 Dec 2021, at 19:05, Steve Ray  wrote:
>
> Admittedly, it was July that I last updated one of our EDG Collections,
> but when I went to update it today (now using EDG 7.0.3) I no longer find
> the Manage-Clear menu option, which I used to use before, followed by
> Settings-Import to upload the latest version (also no longer present).
>
> I have looked through the 7.0 documentation but clearly not in the right
> place, because I can't find how I'm supposed to do this now. Could you
> point me to the right document?
>
> Thanks,
>
> Steve
>
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CAGUep87oTST1i2v3vb1zejXHECHqK7kD-e3dZTw2BS7MQtrd2g%40mail.gmail.com
> <https://groups.google.com/d/msgid/topbraid-users/CAGUep87oTST1i2v3vb1zejXHECHqK7kD-e3dZTw2BS7MQtrd2g%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>
> UK +44 (0) 7788 561308
> US +1 (336) 283-0808‬
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/992E5A34-8923-47F2-91FC-7C787828160C%40topquadrant.com
> <https://groups.google.com/d/msgid/topbraid-users/992E5A34-8923-47F2-91FC-7C787828160C%40topquadrant.com?utm_medium=email_source=footer>
> .
>

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep84eCtGBXYTk4vR%2BKORoMYtdvR%2BOrU6jJOUEWcXhcRykEg%40mail.gmail.com.

[topbraid-users] The Manage-Delete and Manage-Clear menu options have disappeared

[Steve Ray]

Admittedly, it was July that I last updated one of our EDG Collections, but
when I went to update it today (now using EDG 7.0.3) I no longer find the
Manage-Clear menu option, which I used to use before, followed by
Settings-Import to upload the latest version (also no longer present).

I have looked through the 7.0 documentation but clearly not in the right
place, because I can't find how I'm supposed to do this now. Could you
point me to the right document?

Thanks,

Steve

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep87oTST1i2v3vb1zejXHECHqK7kD-e3dZTw2BS7MQtrd2g%40mail.gmail.com.

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

[Steve Ray]

I'm not sure I fully understand why, but I changed my root class to be a
subClass of rdfs:Resource instead of rdfs:Class as you suggested, and the
odd behavior of all my instances suddenly being inferred to be subClasses
of rdfs:Resource went away. So thank you.

Steve




On Thu, Oct 28, 2021 at 12:20 PM Irene Polikoff 
wrote:

> myNamespace:MyRootClass
>   rdf:type rdfs:Class ;
>   rdf:type sh:NodeShape ;
>   rdfs:subClassOf rdfs:Resource ;
>
> On Oct 28, 2021, at 2:33 PM, Steve Ray  wrote:
>
> One last(?) guidance request.
> Previously, I had been declaring classes as:
>
>   ex:MyRandomClass
>   rdf:type owl:Class ;
>   rdf:type sh:NodeShape ;
>   rdfs:subClassOf owl:Thing ;
> ...
>
> Normally, I define a root class in my ontologies, and all my other classes
> are subclasses of that:
>
> myNamespace:MyRootClass
>   rdf:type owl:Class ;
>   rdf:type sh:NodeShape ;
>   rdfs:subClassOf owl:Thing ;
>
> So in my no-OWL migration, I have defined my own non-OWL version of
> owl:Class:
>
> myNamespace:Class
>   rdf:type rdfs:Class ;
>   rdf:type sh:NodeShape ;
>   rdfs:subClassOf rdfs:Class ;
>
> so my random classes would be:
>
>   ex:MyRandomClass
>   rdf:type myNamespace:Class ;
>   rdf:type sh:NodeShape ;
>   rdfs:subClassOf myNamespace:MyRootClass ;
>
> so should my new root class be:
>
> myNamespace:MyRootClass
>   rdf:type myNamespace:Class ;
>   rdf:type sh:NodeShape ;
>   rdfs:subClassOf rdfs:Class ;
>
> or should it be:
>
> myNamespace:MyRootClass
>   rdf:type myNamespace:Class ;
>   rdf:type sh:NodeShape ;
>   rdfs:subClassOf rdfs:Resource ;
>
>
> ...I'm starting to confuse myself about things being a subClassOf
> something and being an rdf:type of something else. (I think I was absent
> during that session of semantic web 101!)
> I'm thinking the first one, but does the SHACL/rdf world even need both a
> type and a subClass?
> I realize that SHACL will just ignore the OWL stuff, but I'd like to go
> ahead and not have it there to avoid confusion.
>
> Steve
>
>
>
>
> On Tue, Oct 26, 2021 at 6:52 PM Holger Knublauch 
> wrote:
>
>>
>> On 2021-10-27 10:40 am, Steve Ray wrote:
>>
>> Thanks Holger and Irene for this perspective.
>>
>> Regarding properties, are you saying I should just declare all my
>> properties to be of type rdf:Property? I'm reluctant to just have them all
>> embedded inside property shapes, just for clarity.
>>
>> This is your choice. SHACL or TopBraid doesn't require global
>> rdf:Property triples (except in some older code places which are now
>> considered bugs). If however you want to produce a generic ontology that is
>> also useful for external RDFS/OWL tools, then rdf:type rdf:Property is not
>> harmful. But you'd need to make sure they don't get out of synch, e.g.
>> after renaming the property.
>>
>>
>> Also, I have written SHACL rules to infer reverse triples for
>> owl:SymmetricProperty and owl:InverseProperty declarations, but I suppose I
>> could declare them as myNamespace:SymmetricProperty and
>> myNamespace:InverseProperty which could be subClassOf rdf:Property. Would
>> that be best practice?
>>
>> I assume you mean owl:inverseOf?
>>
>> It is perfectly fine to use SHACL rules that react on the OWL vocabulary,
>> e.g. owl:SymmetricProperty.
>>
>> FYI there is also a SHACL constraint in the dash: namespace that serves
>> not as inference but as a constraint
>>
>> https://datashapes.org/constraints.html#SymmetricConstraintComponent
>>
>> I don't like using owl:inverseOf and strongly discourage its use.
>> sh:inversePath is sufficient and doesn't require the use of an (OWL)
>> inference engine.
>>
>> Holger
>>
>>
>>
>> Steve
>>
>>
>>
>>
>> On Fri, Oct 22, 2021 at 5:32 PM Irene Polikoff 
>> wrote:
>>
>>> Please see below.
>>>
>>> On Oct 22, 2021, at 7:54 PM, Steve Ray  wrote:
>>>
>>> I now understand.
>>>
>>> On a related point, is it true that the only owl uses that persist in
>>> SHACL implementations are the two relating to managing graphs:
>>>
>>> owl:imports (if you want to import other graphs), and
>>>
>>>
>>> Yes, explicitly supported in SHACL e.g.,
>>> https://www.w3.org/TR/shacl/#shapes-graph
>>>
>>> X a owl:Ontology (if you want to name a graph so that you can do things
>>> like imports)?
>>>
>>>
>>> Not really supported/required, but you can use it if you want.
>>>
>>&

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

[Steve Ray]

Michel,
It helped in the following specific case where I don't need to include a
"$this a/rdfs:subClassOf " statement. All my defined classes
are instances of s223:Class. All the imported classes from various other
ontologies are not.

s223:Class
sh:property [
sh:path rdfs:label ;
sh:sparql [
a sh:SPARQLConstraint ;
sh:message "{$this} must have an rdfs:label" ;
sh:prefixes <http://data.ashrae.org/standard223/1.0/validation/schema> ;
sh:select """
SELECT $this
WHERE {
FILTER (NOT EXISTS {$this rdfs:label ?something}) .
}
""" ;
] ;
] ;
.
Steve




On Thu, Oct 28, 2021 at 1:00 PM 'Bohms, H.M. (Michel)' via TopBraid Suite
Users  wrote:

> I do understand that an own generic rootclass can help but not how an own
> "owl class" can support that.
>
> Op 28 okt. 2021 21:53 schreef Steve Ray :
> Michel,
> I was doing it similar to what you suggest, but making our own version of
> owl:Class made it slightly easier to collect all the locally defined
> classes for validation/inferencing. Don't have to have
>
> a/rdfs:subClassOf* in my queries when validating all our defined classes.
> I suppose it's a style/judgment call.
>
> Steve
>
>
>
>
> On Thu, Oct 28, 2021 at 11:59 AM 'Bohms, H.M. (Michel)' via TopBraid Suite
> Users  wrote:
>
>>  Cant see why you would need an owndefined owlclass in your no owl
>> rdfs
>>
>> Just type your random classes as rdfs class and subclass them wrt your
>> rootclass itself also of type rdfs class.
>>
>> Op 28 okt. 2021 20:49 schreef David Price :
>> Hi Steve
>>
>>
>> Rdfs subclass is between RDFS Class as a set theory relation (all Sub are
>> Super) and type is from RDF to define set membership (Ind is a member of
>> Sub)
>>
>> Cheers,
>> David
>>
>> On 28 Oct 2021, at 19:33, Steve Ray  wrote:
>>
>> 
>> One last(?) guidance request.
>> Previously, I had been declaring classes as:
>>
>>   ex:MyRandomClass
>>
>>   rdf:type owl:Class ;
>>
>>   rdf:type sh:NodeShape ;
>>
>>   rdfs:subClassOf owl:Thing ;
>> ...
>>
>> Normally, I define a root class in my ontologies, and all my other
>> classes are subclasses of that:
>>
>> myNamespace:MyRootClass
>>
>>   rdf:type owl:Class ;
>>
>>   rdf:type sh:NodeShape ;
>>
>>   rdfs:subClassOf owl:Thing ;
>>
>> So in my no-OWL migration, I have defined my own non-OWL version of
>> owl:Class:
>>
>>
>> myNamespace:Class
>>
>>   rdf:type rdfs:Class ;
>>
>>   rdf:type sh:NodeShape ;
>>
>>   rdfs:subClassOf rdfs:Class ;
>>
>> so my random classes would be:
>>
>>   ex:MyRandomClass
>>
>>   rdf:type myNamespace:Class ;
>>
>>   rdf:type sh:NodeShape ;
>>
>>   rdfs:subClassOf myNamespace:MyRootClass ;
>>
>> so should my new root class be:
>>
>> myNamespace:MyRootClass
>>
>>   rdf:type myNamespace:Class ;
>>
>>   rdf:type sh:NodeShape ;
>>
>>   rdfs:subClassOf rdfs:Class ;
>>
>>
>> or should it be:
>>
>>
>> myNamespace:MyRootClass
>>
>>   rdf:type myNamespace:Class ;
>>
>>   rdf:type sh:NodeShape ;
>>
>>   rdfs:subClassOf rdfs:Resource ;
>>
>>
>> ...I'm starting to confuse myself about things being a subClassOf
>> something and being an rdf:type of something else. (I think I was absent
>> during that session of semantic web 101!)
>> I'm thinking the first one, but does the SHACL/rdf world even need both a
>> type and a subClass?
>> I realize that SHACL will just ignore the OWL stuff, but I'd like to go
>> ahead and not have it there to avoid confusion.
>>
>> Steve
>>
>>
>>
>>
>> On Tue, Oct 26, 2021 at 6:52 PM Holger Knublauch 
>> wrote:
>>
>>>
>>> On 2021-10-27 10:40 am, Steve Ray wrote:
>>>
>>> Thanks Holger and Irene for this perspective.
>>>
>>> Regarding properties, are you saying I should just declare all my
>>> properties to be of type rdf:Property? I'm reluctant to just have them all
>>> embedded inside property shapes, just for clarity.
>>>
>>> This is your choice. SHACL or TopBraid doesn't require global
>>> rdf:Property triples (except in some older code places which are now
>>> considered bugs). If however you want to produce a generic ontology that is
>>> also useful for external RDFS/OWL tools, then rdf:type rdf:Property is not
>>> harmful. But you'd need to make su

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

[Steve Ray]

Michel,
I was doing it similar to what you suggest, but making our own version of
owl:Class made it slightly easier to collect all the locally defined
classes for validation/inferencing. Don't have to have

a/rdfs:subClassOf* in my queries when validating all our defined classes. I
suppose it's a style/judgment call.

Steve




On Thu, Oct 28, 2021 at 11:59 AM 'Bohms, H.M. (Michel)' via TopBraid Suite
Users  wrote:

>  Cant see why you would need an owndefined owlclass in your no owl
> rdfs
>
> Just type your random classes as rdfs class and subclass them wrt your
> rootclass itself also of type rdfs class.
>
> Op 28 okt. 2021 20:49 schreef David Price :
> Hi Steve
>
>
> Rdfs subclass is between RDFS Class as a set theory relation (all Sub are
> Super) and type is from RDF to define set membership (Ind is a member of
> Sub)
>
> Cheers,
> David
>
> On 28 Oct 2021, at 19:33, Steve Ray  wrote:
>
> 
> One last(?) guidance request.
> Previously, I had been declaring classes as:
>
>   ex:MyRandomClass
>
>   rdf:type owl:Class ;
>
>   rdf:type sh:NodeShape ;
>
>   rdfs:subClassOf owl:Thing ;
> ...
>
> Normally, I define a root class in my ontologies, and all my other classes
> are subclasses of that:
>
> myNamespace:MyRootClass
>
>   rdf:type owl:Class ;
>
>   rdf:type sh:NodeShape ;
>
>   rdfs:subClassOf owl:Thing ;
>
> So in my no-OWL migration, I have defined my own non-OWL version of
> owl:Class:
>
>
> myNamespace:Class
>
>   rdf:type rdfs:Class ;
>
>   rdf:type sh:NodeShape ;
>
>   rdfs:subClassOf rdfs:Class ;
>
> so my random classes would be:
>
>   ex:MyRandomClass
>
>   rdf:type myNamespace:Class ;
>
>   rdf:type sh:NodeShape ;
>
>   rdfs:subClassOf myNamespace:MyRootClass ;
>
> so should my new root class be:
>
> myNamespace:MyRootClass
>
>   rdf:type myNamespace:Class ;
>
>   rdf:type sh:NodeShape ;
>
>   rdfs:subClassOf rdfs:Class ;
>
>
> or should it be:
>
>
> myNamespace:MyRootClass
>
>   rdf:type myNamespace:Class ;
>
>   rdf:type sh:NodeShape ;
>
>   rdfs:subClassOf rdfs:Resource ;
>
>
> ...I'm starting to confuse myself about things being a subClassOf
> something and being an rdf:type of something else. (I think I was absent
> during that session of semantic web 101!)
> I'm thinking the first one, but does the SHACL/rdf world even need both a
> type and a subClass?
> I realize that SHACL will just ignore the OWL stuff, but I'd like to go
> ahead and not have it there to avoid confusion.
>
> Steve
>
>
>
>
> On Tue, Oct 26, 2021 at 6:52 PM Holger Knublauch 
> wrote:
>
>>
>> On 2021-10-27 10:40 am, Steve Ray wrote:
>>
>> Thanks Holger and Irene for this perspective.
>>
>> Regarding properties, are you saying I should just declare all my
>> properties to be of type rdf:Property? I'm reluctant to just have them all
>> embedded inside property shapes, just for clarity.
>>
>> This is your choice. SHACL or TopBraid doesn't require global
>> rdf:Property triples (except in some older code places which are now
>> considered bugs). If however you want to produce a generic ontology that is
>> also useful for external RDFS/OWL tools, then rdf:type rdf:Property is not
>> harmful. But you'd need to make sure they don't get out of synch, e.g.
>> after renaming the property.
>>
>>
>> Also, I have written SHACL rules to infer reverse triples for
>> owl:SymmetricProperty and owl:InverseProperty declarations, but I suppose I
>> could declare them as myNamespace:SymmetricProperty and
>> myNamespace:InverseProperty which could be subClassOf rdf:Property. Would
>> that be best practice?
>>
>> I assume you mean owl:inverseOf?
>>
>> It is perfectly fine to use SHACL rules that react on the OWL vocabulary,
>> e.g. owl:SymmetricProperty.
>>
>> FYI there is also a SHACL constraint in the dash: namespace that serves
>> not as inference but as a constraint
>>
>> https://datashapes.org/constraints.html#SymmetricConstraintComponent
>>
>> I don't like using owl:inverseOf and strongly discourage its use.
>> sh:inversePath is sufficient and doesn't require the use of an (OWL)
>> inference engine.
>>
>> Holger
>>
>>
>>
>> Steve
>>
>>
>>
>>
>> On Fri, Oct 22, 2021 at 5:32 PM Irene Polikoff 
>> wrote:
>>
>>> Please see below.
>>>
>>> On Oct 22, 2021, at 7:54 PM, Steve Ray  wrote:
>>>
>>> I now understand.
>>>
>>> On a related point, is it true that the on

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

[Steve Ray]

I agree. When I run the SHACL reasoner with the following code, I get all
the inverse triples.

s223:InversePropertyShape
a sh:NodeShape ;
sh:rule [
a sh:SPARQLRule ;
sh:construct """
CONSTRUCT {
?o ?invP $this .
}
WHERE {
$this ?p ?o .
?p s223:inverseOf ?invP .
}
""" ;
sh:prefixes <http://data.ashrae.org/standard223/1.0/inference/owl-subset> ;
] ;
sh:targetClass s223:Concept ;
.

Your point is well taken that we could do it your way without running the
reasoner, although we run it anyway for other inferences.

Steve




On Thu, Oct 28, 2021 at 12:18 PM Irene Polikoff 
wrote:

> In SHACL, you give a name to the inverse relation by creating a property
> shape with the inverse path. For example:
>
> skos:Concept-broader-inverse
>   a sh:PropertyShape ;
>   sh:path [
>   sh:inversePath skos:broader ;
> ] ;
>   sh:class skos:Concept ;
>   sh:name "narrower concept" ;
> .
>
> This is the true notion of the inverse relation in a graph because it
> describes traversing a relationship in an opposite direction and it gives a
> name to the opposite direction.
>
> When you declare a separate URI for a property and say that it is an
> inverse e.g.,
>
> skos:narrower owl:inverseOf skos:broader.
>
> And then talk about triples that use the skos:narrower predicate, strictly
> speaking, you are not really talking about triples with the skos:broader
> relationship that exist in your graph - whether you traverse such triples
> in one direction or in another. At most, you are talking about skos:broader
> triples that would get generated from the skos:narrower should a reasoner
> be applied.
>
> On Oct 27, 2021, at 12:41 PM, Steve Ray  wrote:
>
> Yes, you are correct - I meant the use of owl:inverseOf, for which I infer
> the inverse triple. I agree with you about not needing this, but it seems
> some on the committee like being able to refer to the inverse relation by a
> more familiar relation name. I may try one more time to argue to eliminate
> our inverse properties.
>
> Regarding the owl:SymmetricProperty declaration, I plan to go ahead and
> replace it with a mynamespace:SymmetricProperty declaration, since I wrote
> the SHACL inference rule anyway. One less OWL element in the model.
>
> Steve
>
>
>
>
> On Tue, Oct 26, 2021 at 6:52 PM Holger Knublauch 
> wrote:
>
>>
>> On 2021-10-27 10:40 am, Steve Ray wrote:
>>
>> Thanks Holger and Irene for this perspective.
>>
>> Regarding properties, are you saying I should just declare all my
>> properties to be of type rdf:Property? I'm reluctant to just have them all
>> embedded inside property shapes, just for clarity.
>>
>> This is your choice. SHACL or TopBraid doesn't require global
>> rdf:Property triples (except in some older code places which are now
>> considered bugs). If however you want to produce a generic ontology that is
>> also useful for external RDFS/OWL tools, then rdf:type rdf:Property is not
>> harmful. But you'd need to make sure they don't get out of synch, e.g.
>> after renaming the property.
>>
>>
>> Also, I have written SHACL rules to infer reverse triples for
>> owl:SymmetricProperty and owl:InverseProperty declarations, but I suppose I
>> could declare them as myNamespace:SymmetricProperty and
>> myNamespace:InverseProperty which could be subClassOf rdf:Property. Would
>> that be best practice?
>>
>> I assume you mean owl:inverseOf?
>>
>> It is perfectly fine to use SHACL rules that react on the OWL vocabulary,
>> e.g. owl:SymmetricProperty.
>>
>> FYI there is also a SHACL constraint in the dash: namespace that serves
>> not as inference but as a constraint
>>
>> https://datashapes.org/constraints.html#SymmetricConstraintComponent
>>
>> I don't like using owl:inverseOf and strongly discourage its use.
>> sh:inversePath is sufficient and doesn't require the use of an (OWL)
>> inference engine.
>>
>> Holger
>>
>>
>>
>> Steve
>>
>>
>>
>>
>> On Fri, Oct 22, 2021 at 5:32 PM Irene Polikoff 
>> wrote:
>>
>>> Please see below.
>>>
>>> On Oct 22, 2021, at 7:54 PM, Steve Ray  wrote:
>>>
>>> I now understand.
>>>
>>> On a related point, is it true that the only owl uses that persist in
>>> SHACL implementations are the two relating to managing graphs:
>>>
>>> owl:imports (if you want to import other graphs), and
>>>
>>>
>>> Yes, explicitly supported in SHACL e.g.,
>>> https://www.w3.org/TR/shacl/#shapes-graph
>>>
>>> X a owl:Ontology 

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

[Steve Ray]

One last(?) guidance request.
Previously, I had been declaring classes as:

  ex:MyRandomClass

  rdf:type owl:Class ;

  rdf:type sh:NodeShape ;

  rdfs:subClassOf owl:Thing ;
...

Normally, I define a root class in my ontologies, and all my other classes
are subclasses of that:

myNamespace:MyRootClass

  rdf:type owl:Class ;

  rdf:type sh:NodeShape ;

  rdfs:subClassOf owl:Thing ;

So in my no-OWL migration, I have defined my own non-OWL version of
owl:Class:


myNamespace:Class

  rdf:type rdfs:Class ;

  rdf:type sh:NodeShape ;

  rdfs:subClassOf rdfs:Class ;

so my random classes would be:

  ex:MyRandomClass

  rdf:type myNamespace:Class ;

  rdf:type sh:NodeShape ;

  rdfs:subClassOf myNamespace:MyRootClass ;

so should my new root class be:

myNamespace:MyRootClass

  rdf:type myNamespace:Class ;

  rdf:type sh:NodeShape ;

  rdfs:subClassOf rdfs:Class ;


or should it be:


myNamespace:MyRootClass

  rdf:type myNamespace:Class ;

  rdf:type sh:NodeShape ;

  rdfs:subClassOf rdfs:Resource ;


...I'm starting to confuse myself about things being a subClassOf something
and being an rdf:type of something else. (I think I was absent during that
session of semantic web 101!)
I'm thinking the first one, but does the SHACL/rdf world even need both a
type and a subClass?
I realize that SHACL will just ignore the OWL stuff, but I'd like to go
ahead and not have it there to avoid confusion.

Steve




On Tue, Oct 26, 2021 at 6:52 PM Holger Knublauch 
wrote:

>
> On 2021-10-27 10:40 am, Steve Ray wrote:
>
> Thanks Holger and Irene for this perspective.
>
> Regarding properties, are you saying I should just declare all my
> properties to be of type rdf:Property? I'm reluctant to just have them all
> embedded inside property shapes, just for clarity.
>
> This is your choice. SHACL or TopBraid doesn't require global rdf:Property
> triples (except in some older code places which are now considered bugs).
> If however you want to produce a generic ontology that is also useful for
> external RDFS/OWL tools, then rdf:type rdf:Property is not harmful. But
> you'd need to make sure they don't get out of synch, e.g. after renaming
> the property.
>
>
> Also, I have written SHACL rules to infer reverse triples for
> owl:SymmetricProperty and owl:InverseProperty declarations, but I suppose I
> could declare them as myNamespace:SymmetricProperty and
> myNamespace:InverseProperty which could be subClassOf rdf:Property. Would
> that be best practice?
>
> I assume you mean owl:inverseOf?
>
> It is perfectly fine to use SHACL rules that react on the OWL vocabulary,
> e.g. owl:SymmetricProperty.
>
> FYI there is also a SHACL constraint in the dash: namespace that serves
> not as inference but as a constraint
>
> https://datashapes.org/constraints.html#SymmetricConstraintComponent
>
> I don't like using owl:inverseOf and strongly discourage its use.
> sh:inversePath is sufficient and doesn't require the use of an (OWL)
> inference engine.
>
> Holger
>
>
>
> Steve
>
>
>
>
> On Fri, Oct 22, 2021 at 5:32 PM Irene Polikoff 
> wrote:
>
>> Please see below.
>>
>> On Oct 22, 2021, at 7:54 PM, Steve Ray  wrote:
>>
>> I now understand.
>>
>> On a related point, is it true that the only owl uses that persist in
>> SHACL implementations are the two relating to managing graphs:
>>
>> owl:imports (if you want to import other graphs), and
>>
>>
>> Yes, explicitly supported in SHACL e.g.,
>> https://www.w3.org/TR/shacl/#shapes-graph
>>
>> X a owl:Ontology (if you want to name a graph so that you can do things
>> like imports)?
>>
>>
>> Not really supported/required, but you can use it if you want.
>>
>>
>> Do you endorse the use of owl property declarations, e.g. Y a
>> owl:ObjectProperty, etc., or do you recommend enforcing the implications of
>> those with SHACL shapes? If the latter, are there SHACL definitions for
>> those?
>>
>>
>> In general, we do not recommend the use of property declarations. SHACL
>> will ignore them. However, if you wanted to, you could use them - as long
>> as you understand that they have no meaning to SHACL.
>>
>> If you say:
>>
>> :PS a sh:PropertyShape;
>> sh:path :p;
>> sh:nodeKind sh:BlankNodeOrIRI ( sh:IRI or sh:BlankNode)
>>
>> You have effectively said that :p is used to connect two resources. If
>> you know what class values of :p belong to, you could also say:
>>
>> :PS a sh:PropertyShape;
>> sh:path :p;
>> sh:class :C .
>>
>> This would also indicate that the property connects two resources, but it
>> says more than that. Using both, sh:class constraint and

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

[Steve Ray]

Yes, you are correct - I meant the use of owl:inverseOf, for which I infer
the inverse triple. I agree with you about not needing this, but it seems
some on the committee like being able to refer to the inverse relation by a
more familiar relation name. I may try one more time to argue to eliminate
our inverse properties.

Regarding the owl:SymmetricProperty declaration, I plan to go ahead and
replace it with a mynamespace:SymmetricProperty declaration, since I wrote
the SHACL inference rule anyway. One less OWL element in the model.

Steve




On Tue, Oct 26, 2021 at 6:52 PM Holger Knublauch 
wrote:

>
> On 2021-10-27 10:40 am, Steve Ray wrote:
>
> Thanks Holger and Irene for this perspective.
>
> Regarding properties, are you saying I should just declare all my
> properties to be of type rdf:Property? I'm reluctant to just have them all
> embedded inside property shapes, just for clarity.
>
> This is your choice. SHACL or TopBraid doesn't require global rdf:Property
> triples (except in some older code places which are now considered bugs).
> If however you want to produce a generic ontology that is also useful for
> external RDFS/OWL tools, then rdf:type rdf:Property is not harmful. But
> you'd need to make sure they don't get out of synch, e.g. after renaming
> the property.
>
>
> Also, I have written SHACL rules to infer reverse triples for
> owl:SymmetricProperty and owl:InverseProperty declarations, but I suppose I
> could declare them as myNamespace:SymmetricProperty and
> myNamespace:InverseProperty which could be subClassOf rdf:Property. Would
> that be best practice?
>
> I assume you mean owl:inverseOf?
>
> It is perfectly fine to use SHACL rules that react on the OWL vocabulary,
> e.g. owl:SymmetricProperty.
>
> FYI there is also a SHACL constraint in the dash: namespace that serves
> not as inference but as a constraint
>
> https://datashapes.org/constraints.html#SymmetricConstraintComponent
>
> I don't like using owl:inverseOf and strongly discourage its use.
> sh:inversePath is sufficient and doesn't require the use of an (OWL)
> inference engine.
>
> Holger
>
>
>
> Steve
>
>
>
>
> On Fri, Oct 22, 2021 at 5:32 PM Irene Polikoff 
> wrote:
>
>> Please see below.
>>
>> On Oct 22, 2021, at 7:54 PM, Steve Ray  wrote:
>>
>> I now understand.
>>
>> On a related point, is it true that the only owl uses that persist in
>> SHACL implementations are the two relating to managing graphs:
>>
>> owl:imports (if you want to import other graphs), and
>>
>>
>> Yes, explicitly supported in SHACL e.g.,
>> https://www.w3.org/TR/shacl/#shapes-graph
>>
>> X a owl:Ontology (if you want to name a graph so that you can do things
>> like imports)?
>>
>>
>> Not really supported/required, but you can use it if you want.
>>
>>
>> Do you endorse the use of owl property declarations, e.g. Y a
>> owl:ObjectProperty, etc., or do you recommend enforcing the implications of
>> those with SHACL shapes? If the latter, are there SHACL definitions for
>> those?
>>
>>
>> In general, we do not recommend the use of property declarations. SHACL
>> will ignore them. However, if you wanted to, you could use them - as long
>> as you understand that they have no meaning to SHACL.
>>
>> If you say:
>>
>> :PS a sh:PropertyShape;
>> sh:path :p;
>> sh:nodeKind sh:BlankNodeOrIRI ( sh:IRI or sh:BlankNode)
>>
>> You have effectively said that :p is used to connect two resources. If
>> you know what class values of :p belong to, you could also say:
>>
>> :PS a sh:PropertyShape;
>> sh:path :p;
>> sh:class :C .
>>
>> This would also indicate that the property connects two resources, but it
>> says more than that. Using both, sh:class constraint and sh:nodeKind
>> sh:BlankNodeOrIRI is redundant.
>>
>> If you are not able to identify the class, you could say sh:class
>> rdfs:Resource.
>>
>> Instead of  owl:Datatype property, you would use sh:nodeKind sh:Literal
>> or use sh:datatype constraint if you can be more specific and identify the
>> datatype. This is not one to one to OWL since OWL distinguishes between the
>> datatype and annotation properties because annotation properties are not
>> used in DL reasoning. SHACL does not have this concept.
>>
>> Another difference is that OWL property type declarations are global.
>> SHACL property shape definitions are specific to targets where a scope of a
>> target could be quite limited. In principle, while a bad practice, it is
>> possible to define two different property 

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

[Steve Ray]

Thanks Holger and Irene for this perspective.

Regarding properties, are you saying I should just declare all my
properties to be of type rdf:Property? I'm reluctant to just have them all
embedded inside property shapes, just for clarity.

Also, I have written SHACL rules to infer reverse triples for
owl:SymmetricProperty and owl:InverseProperty declarations, but I suppose I
could declare them as myNamespace:SymmetricProperty and
myNamespace:InverseProperty which could be subClassOf rdf:Property. Would
that be best practice?

Steve




On Fri, Oct 22, 2021 at 5:32 PM Irene Polikoff 
wrote:

> Please see below.
>
> On Oct 22, 2021, at 7:54 PM, Steve Ray  wrote:
>
> I now understand.
>
> On a related point, is it true that the only owl uses that persist in
> SHACL implementations are the two relating to managing graphs:
>
> owl:imports (if you want to import other graphs), and
>
>
> Yes, explicitly supported in SHACL e.g.,
> https://www.w3.org/TR/shacl/#shapes-graph
>
> X a owl:Ontology (if you want to name a graph so that you can do things
> like imports)?
>
>
> Not really supported/required, but you can use it if you want.
>
>
> Do you endorse the use of owl property declarations, e.g. Y a
> owl:ObjectProperty, etc., or do you recommend enforcing the implications of
> those with SHACL shapes? If the latter, are there SHACL definitions for
> those?
>
>
> In general, we do not recommend the use of property declarations. SHACL
> will ignore them. However, if you wanted to, you could use them - as long
> as you understand that they have no meaning to SHACL.
>
> If you say:
>
> :PS a sh:PropertyShape;
> sh:path :p;
> sh:nodeKind sh:BlankNodeOrIRI ( sh:IRI or sh:BlankNode)
>
> You have effectively said that :p is used to connect two resources. If you
> know what class values of :p belong to, you could also say:
>
> :PS a sh:PropertyShape;
> sh:path :p;
> sh:class :C .
>
> This would also indicate that the property connects two resources, but it
> says more than that. Using both, sh:class constraint and sh:nodeKind
> sh:BlankNodeOrIRI is redundant.
>
> If you are not able to identify the class, you could say sh:class
> rdfs:Resource.
>
> Instead of  owl:Datatype property, you would use sh:nodeKind sh:Literal or
> use sh:datatype constraint if you can be more specific and identify the
> datatype. This is not one to one to OWL since OWL distinguishes between the
> datatype and annotation properties because annotation properties are not
> used in DL reasoning. SHACL does not have this concept.
>
> Another difference is that OWL property type declarations are global.
> SHACL property shape definitions are specific to targets where a scope of a
> target could be quite limited. In principle, while a bad practice, it is
> possible to define two different property shapes with the same path but
> different targets and have one use sh:nodeKind sh:IRI and another
> sh:nodeKind sh:Literal.
>
>
>
> Steve
>
>
>
>
> On Fri, Oct 22, 2021 at 4:12 PM Holger Knublauch 
> wrote:
>
>>
>>
>> On 23 Oct 2021, at 3:50 am, Steve Ray  wrote:
>>
>> Holger,
>>
>> Your final suggestion was the key! Who knew that we must declare
>> owl:Class to be of type sh:NodeShape!
>> I had a similar validation test for labelling all properties, and
>> declaring rdf:Property as rdf:type sh:NodeShape fixed that one as well.
>> Thank you so much for that subtle tip. If this is documented in the SHACL
>> spec, I missed it. If it is not, I'll bet other people will bump into this
>> problem.
>>
>>
>> It’s mentioned here: https://www.w3.org/TR/shacl/#implicit-targetClass
>>
>> To validate instances of any class, either use sh:targetClass X or make X
>> rdf:type rdfs:Class AND rdf:type sh:NodeShape.
>>
>> Holger
>>
>>
>>
>> Steve
>>
>>
>>
>>
>> On Thu, Oct 21, 2021 at 6:18 PM Holger Knublauch 
>> wrote:
>>
>>> Hi Steve,
>>>
>>> it SHOULD work, but TBC has two validation buttons and only the green
>>> one includes the classes and properties:
>>>
>>> <3HjnsEUcNN3NjWZm.png>
>>> On 2021-10-22 8:09 am, Steve Ray wrote:
>>>
>>> I'm not understanding something about validating SHACL files. Normally I
>>> successfully use shapes and SPARQLConstraints to validate rdf instance
>>> files, but I'd also like to apply some constraints to our SHACL shape
>>> definitions themselves.
>>>
>>> For example, I'd like to ensure all our declared classes/Nodeshapes have
>>> an rdfs:label, so I wrote:
>>>
>&

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

[Steve Ray]

I now understand.

On a related point, is it true that the only owl uses that persist in
SHACL implementations are the two relating to managing graphs:

owl:imports (if you want to import other graphs), and
X a owl:Ontology (if you want to name a graph so that you can do things
like imports)?

Do you endorse the use of owl property declarations, e.g. Y a
owl:ObjectProperty, etc., or do you recommend enforcing the implications of
those with SHACL shapes? If the latter, are there SHACL definitions for
those?

Steve




On Fri, Oct 22, 2021 at 4:12 PM Holger Knublauch 
wrote:

>
>
> On 23 Oct 2021, at 3:50 am, Steve Ray  wrote:
>
> Holger,
>
> Your final suggestion was the key! Who knew that we must declare owl:Class
> to be of type sh:NodeShape!
> I had a similar validation test for labelling all properties, and
> declaring rdf:Property as rdf:type sh:NodeShape fixed that one as well.
> Thank you so much for that subtle tip. If this is documented in the SHACL
> spec, I missed it. If it is not, I'll bet other people will bump into this
> problem.
>
>
> It’s mentioned here: https://www.w3.org/TR/shacl/#implicit-targetClass
>
> To validate instances of any class, either use sh:targetClass X or make X
> rdf:type rdfs:Class AND rdf:type sh:NodeShape.
>
> Holger
>
>
>
> Steve
>
>
>
>
> On Thu, Oct 21, 2021 at 6:18 PM Holger Knublauch 
> wrote:
>
>> Hi Steve,
>>
>> it SHOULD work, but TBC has two validation buttons and only the green one
>> includes the classes and properties:
>>
>> <3HjnsEUcNN3NjWZm.png>
>> On 2021-10-22 8:09 am, Steve Ray wrote:
>>
>> I'm not understanding something about validating SHACL files. Normally I
>> successfully use shapes and SPARQLConstraints to validate rdf instance
>> files, but I'd also like to apply some constraints to our SHACL shape
>> definitions themselves.
>>
>> For example, I'd like to ensure all our declared classes/Nodeshapes have
>> an rdfs:label, so I wrote:
>>
>> owl:Class
>> sh:property [
>> sh:path rdfs:label ;
>> sh:minCount 1 ;
>> ] ;
>> .
>>
>> On the above, please double-check that owl:Class rdf:type sh:NodeShape is
>> also asserted.
>>
>> Holger
>>
>>
>> I also tried
>> 1. Writing a SPARQLConstraint to do the same thing.
>> 2. Using the sh:targetClass method with an explicitly named shape.
>> 3. Using these with sh:NodeShape instead of owl:Class, since all my
>> classes are also instances of sh:NodeShape.
>>
>> None produced any validation errors when I ran the TBC validator on a
>> shapes file containing the definition of a class where I intentionally
>> omitted an rdfs:label value.
>>
>> I know that the SHACL spec even has the shsh:ShapeShape specification, so
>> I assume this kind of thing can be done. Is something blocking the
>> validation error from showing up? Is it because rdfs:label is an annotation
>> property?
>>
>> Steve
>>
>>
>> --
>> 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 topbraid-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/topbraid-users/CAGUep87sNoHp7PQaJq9bVsODsOL7OY1Q-%2B9LBDooJtC1tBWBCQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/topbraid-users/CAGUep87sNoHp7PQaJq9bVsODsOL7OY1Q-%2B9LBDooJtC1tBWBCQ%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>>
>> --
>> 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 topbraid-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/topbraid-users/e3dba027-2908-89d8-c930-7abf03361868%40topquadrant.com
>> <https://groups.google.com/d/msgid/topbraid-users/e3dba027-2908-89d8-c930-7abf03361868%40topquadrant.com?utm_medium=email_source=footer>
>> .
>>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CAGUep851gHoMy%2BVCgYnTTSfXG54aoy16O9HxkH0j3BrsjtUFRA%40mail.gmail.com
> <https://groups.google.com/d/msgi

Re: [topbraid-users] Validating owl:Classes or sh:NodeShapes

[Steve Ray]

Holger,

Your final suggestion was the key! Who knew that we must declare owl:Class
to be of type sh:NodeShape!
I had a similar validation test for labelling all properties, and declaring
rdf:Property as rdf:type sh:NodeShape fixed that one as well.
Thank you so much for that subtle tip. If this is documented in the SHACL
spec, I missed it. If it is not, I'll bet other people will bump into this
problem.

Steve




On Thu, Oct 21, 2021 at 6:18 PM Holger Knublauch 
wrote:

> Hi Steve,
>
> it SHOULD work, but TBC has two validation buttons and only the green one
> includes the classes and properties:
>
> On 2021-10-22 8:09 am, Steve Ray wrote:
>
> I'm not understanding something about validating SHACL files. Normally I
> successfully use shapes and SPARQLConstraints to validate rdf instance
> files, but I'd also like to apply some constraints to our SHACL shape
> definitions themselves.
>
> For example, I'd like to ensure all our declared classes/Nodeshapes have
> an rdfs:label, so I wrote:
>
> owl:Class
> sh:property [
> sh:path rdfs:label ;
> sh:minCount 1 ;
> ] ;
> .
>
> On the above, please double-check that owl:Class rdf:type sh:NodeShape is
> also asserted.
>
> Holger
>
>
> I also tried
> 1. Writing a SPARQLConstraint to do the same thing.
> 2. Using the sh:targetClass method with an explicitly named shape.
> 3. Using these with sh:NodeShape instead of owl:Class, since all my
> classes are also instances of sh:NodeShape.
>
> None produced any validation errors when I ran the TBC validator on a
> shapes file containing the definition of a class where I intentionally
> omitted an rdfs:label value.
>
> I know that the SHACL spec even has the shsh:ShapeShape specification, so
> I assume this kind of thing can be done. Is something blocking the
> validation error from showing up? Is it because rdfs:label is an annotation
> property?
>
> Steve
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CAGUep87sNoHp7PQaJq9bVsODsOL7OY1Q-%2B9LBDooJtC1tBWBCQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/topbraid-users/CAGUep87sNoHp7PQaJq9bVsODsOL7OY1Q-%2B9LBDooJtC1tBWBCQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/e3dba027-2908-89d8-c930-7abf03361868%40topquadrant.com
> <https://groups.google.com/d/msgid/topbraid-users/e3dba027-2908-89d8-c930-7abf03361868%40topquadrant.com?utm_medium=email_source=footer>
> .
>

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep851gHoMy%2BVCgYnTTSfXG54aoy16O9HxkH0j3BrsjtUFRA%40mail.gmail.com.

[topbraid-users] Validating owl:Classes or sh:NodeShapes

[Steve Ray]

I'm not understanding something about validating SHACL files. Normally I
successfully use shapes and SPARQLConstraints to validate rdf instance
files, but I'd also like to apply some constraints to our SHACL shape
definitions themselves.

For example, I'd like to ensure all our declared classes/Nodeshapes have an
rdfs:label, so I wrote:

owl:Class
sh:property [
sh:path rdfs:label ;
sh:minCount 1 ;
] ;
.
I also tried
1. Writing a SPARQLConstraint to do the same thing.
2. Using the sh:targetClass method with an explicitly named shape.
3. Using these with sh:NodeShape instead of owl:Class, since all my classes
are also instances of sh:NodeShape.

None produced any validation errors when I ran the TBC validator on a
shapes file containing the definition of a class where I intentionally
omitted an rdfs:label value.

I know that the SHACL spec even has the shsh:ShapeShape specification, so I
assume this kind of thing can be done. Is something blocking the validation
error from showing up? Is it because rdfs:label is an annotation property?

Steve

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep87sNoHp7PQaJq9bVsODsOL7OY1Q-%2B9LBDooJtC1tBWBCQ%40mail.gmail.com.

Re: [topbraid-users] Query Error in EDG but not in TBC

[Steve Ray]

Just to chime in, that second syntax is exactly what I always use.

Steve




On Fri, Jul 23, 2021 at 1:15 PM Pat Doyle  wrote:

> If I recall correctly, this is a consequence of the third party sparql
> query editor library we use in the browser being a bit more picky about
> syntax than we are in Composer itself.
>
> I think I worked around it in the past by changing any instance of SELECT
> COUNT(*) to SELECT (COUNT(*) as ?count), or something similar.
>
> On Fri, Jul 23, 2021 at 1:07 PM Tim Smith  wrote:
>
>> Hi,
>>
>> Could someone please check this query in EDG?
>>
>> SELECT COUNT(*)
>> WHERE {
>> ?s rdfs:label ?slabel .
>> }
>>
>> Using TBC 7.0.3, I start TBC, after closing all browsers, open EDG , open
>> the Kennedy Family Data Graph, open a SPARQL panel and type in the query
>> above.
>>
>> EDG thinks there is an error in the query:
>>
>> [image: image.png]
>>
>> Remove the COUNT, and it will work.
>>
>> Using the same query in TBC, it executes as expected.  I've reset the
>> SPARQL panel to the default query and re-typed the query several times with
>> the same error message.
>>
>> Am I missing something obvious?
>>
>> Thanks,
>>
>> Tim
>>
>> --
>> 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 topbraid-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/topbraid-users/CAF0WbnJLQdHzNR%3Dczy%2BTKXfbJMm8aaUdcLfBB7ZcSeAhXMEP7g%40mail.gmail.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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CA%2B5SJmHv8VgbZ-qquztor4sD0CSfE_2UvO9UfC0%3DrMpwkD4SbQ%40mail.gmail.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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep85%3DP%2BLs7xqzrRveX1ZBHM7Eyo75piVbMaK8SEXuZQ-4nw%40mail.gmail.com.

[topbraid-users] Cannot find a setting in TBC

[Steve Ray]

Several of us are collaborating on a project, using TBC, and my copy
serializes the rdf:type predicate as "a" (which I like), while another copy
sticks with "rdf:type". I have scoured the preferences and help documents
and just cannot find where the setting is to specify which to use.

Of course, git carefully shows me every change as we hand off files to each
other, making it very difficult to see the real changes.

I'm hoping this is a 5-second fix for somebody to point me to the right
place...

Steve

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep86r29TEnb8HPLd_ugz%3DrsHgAS_OaKrnyCYY-jSr7Oesng%40mail.gmail.com.

Re: [topbraid-users] sh:targetClass question

[Steve Ray]

Thanks for the quick response. I'm unsure how TBC handles sh:node, since my
toy example validates without errors, while my real code hangs forever.
What is your intended TBC behavior? (Then I will dig in and try to figure
out which of my examples doesn't work that way).

Steve




On Fri, Jul 2, 2021 at 11:10 AM Irene Polikoff 
wrote:

> https://www.w3.org/TR/shacl/#shapes-recursion
>
> On Jul 2, 2021, at 10:50 AM, Steve Ray  wrote:
>
> I believe that I now understand everything you say regarding sh:node. I
> recognize that any instance that satisfies the constraints of the NodeShape
> will pass the sh:node constraint, thus not error is raised.
>
> All was good until I found that I was hanging TBC. My hypothesis is that
> in determining satisfaction of the sh:node constraint, the engine had to
> examine all the properties of the NodeShape. Since some of those properties
> in turn contained sh:node constraints, it had to recurse in to check if
> those properties were satisfied. Since some of the instances pointed to
> each other, I figured I had sent TBC into an infinite recursion.
>
> To check this, I built a toy example (attached) with a "sibling" relation
> with the same pattern. However, this example seems to validate just fine,
> without hanging. I'm wondering why the same infinite recursion is not
> happening.
>
> Steve
>
>
>
>
> On Wed, Jun 23, 2021 at 3:09 PM Irene Polikoff 
> wrote:
>
>>
>> Not sure I understand the question.
>>
>> sh:node :Connectable
>>
>> Simply means that the values need to satisfy the constraints defined
>> for :Connectable. If you have a type constraint defined for :Connectable
>> (i.e., a property have that rdf:type must be some specific class), then it
>> will be evaluated, but if you don’t, then, it does not matter what is the
>> type of the value resource.
>>
>>
>> Given your model, there are two ways to identify nodes to validate
>> against :Connectable - 1)values of :connectsFrom for instances of
>> SomeOtherClass and instances of Device and other target classes. This
>> includes instances of subclass.
>>
>>
>> On Jun 23, 2021, at 3:00 PM, Steve Ray  wrote:
>>
>> I forgot one detail, which is that I have a subClassOf hierarchy under
>> Device, and the instances of any of those subClasses do not seem to
>> validate against the Connectable shape. Does sh:node traverse the
>> subClassOf hierarchy of the sh:targetClass values?
>>
>> Steve
>>
>>
>>
>>
>> On Wed, Jun 23, 2021 at 11:47 AM Irene Polikoff 
>> wrote:
>>
>>> What behaviour did you expect?
>>>
>>> Since Connectable is just a shape and does not have any instances, then
>>> you can’t use it in sh:class. This constraint says that the value must be
>>> an instance of Connectable, which will always be wrong.
>>>
>>> When you say sh:node s223:Connectable, it means that values should
>>> validate against the constraints defined for Connectable. For this scenario
>>> targets associated with Connectable are ignored since the constraint is
>>> already targeting - all values of s223:connectedFrom that belong to members
>>> of SomeOtherClass will be validated against the shape.
>>>
>>> All instances of Device, DomainSpace and Sensor will also be validated
>>> against the Connectable shape - because of the target statements.
>>>
>>> https://www.w3.org/TR/shacl/#NodeConstraintComponent
>>>
>>> https://www.w3.org/TR/shacl/#focusNodes
>>>
>>> On Jun 23, 2021, at 1:19 PM, Steve Ray  wrote:
>>>
>>> The discussion you have been having regarding sh:targetClass reminds me
>>> of a problem I am having, as follows.
>>>
>>> I'm defining an abstract "mixin" shape, Connectable, that has various
>>> properties used by a number of target classes. I do not want to allow
>>> instantiation of Connectable, so I defined it only as a NodeShape, but not
>>> an owl:Class. (I cannot use the dash:abstract property without stepping
>>> outside strict SHACL). Then, I need other classes to have the equivalent of
>>> a sh:class constraint on properties that point to instances of all those
>>> target classes. I assume I cannot use sh:class as in the example below,
>>> since Connectable is not a class. I tried sh:node, since the documentation
>>> implies that's what I need, but I'm not getting the expected behavior.
>>>
>>> Am I misunderstanding the use of sh:node?
>>>
>>> s223:Connectable
>>> a sh:NodeShape ;
>>&

Re: [topbraid-users] sh:targetClass question

[Steve Ray]

I believe that I now understand everything you say regarding sh:node. I
recognize that any instance that satisfies the constraints of the NodeShape
will pass the sh:node constraint, thus not error is raised.

All was good until I found that I was hanging TBC. My hypothesis is that in
determining satisfaction of the sh:node constraint, the engine had to
examine all the properties of the NodeShape. Since some of those properties
in turn contained sh:node constraints, it had to recurse in to check if
those properties were satisfied. Since some of the instances pointed to
each other, I figured I had sent TBC into an infinite recursion.

To check this, I built a toy example (attached) with a "sibling" relation
with the same pattern. However, this example seems to validate just fine,
without hanging. I'm wondering why the same infinite recursion is not
happening.

Steve




On Wed, Jun 23, 2021 at 3:09 PM Irene Polikoff 
wrote:

>
> Not sure I understand the question.
>
> sh:node :Connectable
>
> Simply means that the values need to satisfy the constraints defined
> for :Connectable. If you have a type constraint defined for :Connectable
> (i.e., a property have that rdf:type must be some specific class), then it
> will be evaluated, but if you don’t, then, it does not matter what is the
> type of the value resource.
>
>
> Given your model, there are two ways to identify nodes to validate against
> :Connectable - 1)values of :connectsFrom for instances of SomeOtherClass
> and instances of Device and other target classes. This includes instances
> of subclass.
>
>
> On Jun 23, 2021, at 3:00 PM, Steve Ray  wrote:
>
> I forgot one detail, which is that I have a subClassOf hierarchy under
> Device, and the instances of any of those subClasses do not seem to
> validate against the Connectable shape. Does sh:node traverse the
> subClassOf hierarchy of the sh:targetClass values?
>
> Steve
>
>
>
>
> On Wed, Jun 23, 2021 at 11:47 AM Irene Polikoff 
> wrote:
>
>> What behaviour did you expect?
>>
>> Since Connectable is just a shape and does not have any instances, then
>> you can’t use it in sh:class. This constraint says that the value must be
>> an instance of Connectable, which will always be wrong.
>>
>> When you say sh:node s223:Connectable, it means that values should
>> validate against the constraints defined for Connectable. For this scenario
>> targets associated with Connectable are ignored since the constraint is
>> already targeting - all values of s223:connectedFrom that belong to members
>> of SomeOtherClass will be validated against the shape.
>>
>> All instances of Device, DomainSpace and Sensor will also be validated
>> against the Connectable shape - because of the target statements.
>>
>> https://www.w3.org/TR/shacl/#NodeConstraintComponent
>>
>> https://www.w3.org/TR/shacl/#focusNodes
>>
>> On Jun 23, 2021, at 1:19 PM, Steve Ray  wrote:
>>
>> The discussion you have been having regarding sh:targetClass reminds me
>> of a problem I am having, as follows.
>>
>> I'm defining an abstract "mixin" shape, Connectable, that has various
>> properties used by a number of target classes. I do not want to allow
>> instantiation of Connectable, so I defined it only as a NodeShape, but not
>> an owl:Class. (I cannot use the dash:abstract property without stepping
>> outside strict SHACL). Then, I need other classes to have the equivalent of
>> a sh:class constraint on properties that point to instances of all those
>> target classes. I assume I cannot use sh:class as in the example below,
>> since Connectable is not a class. I tried sh:node, since the documentation
>> implies that's what I need, but I'm not getting the expected behavior.
>>
>> Am I misunderstanding the use of sh:node?
>>
>> s223:Connectable
>> a sh:NodeShape ;
>> ...various properties
>> sh:targetClass s223:Device ;
>> sh:targetClass s223:DomainSpace ;
>> sh:targetClass s223:Sensor ;
>> .
>>
>> s223:Device
>> a owl:Class ;
>> a sh:NodeShape ;
>> ...
>> .
>>
>> # Presumed invalid case
>> s223:SomeOtherClass
>> a owl:Class ;
>> a sh:NodeShape ;
>> sh:property [
>> sh:path s223:connectsFrom ;
>> sh:class s223:Connectable ;
>> ...
>>
>> #Expected valid case
>> s223:SomeOtherClass
>> a owl:Class ;
>> a sh:NodeShape ;
>> sh:property [
>> sh:path s223:connectsFrom ;
>> sh:node s223:Connectable ;
>> ...
>>
>>
>> Steve
>>
>>
>>
>> --
>> You received this message because you are subscribed to the

Re: [topbraid-users] sh:targetClass question

[Steve Ray]

Problem solved.
I think I was a victim of some caching of leftover definitions of some
sort. Once I closed and re-opened TBC, my use of "sh:node s223:Connectable"
worked as expected with instances of a subClass of Device.


Steve




On Wed, Jun 23, 2021 at 12:09 PM Irene Polikoff 
wrote:

>
> Not sure I understand the question.
>
> sh:node :Connectable
>
> Simply means that the values need to satisfy the constraints defined
> for :Connectable. If you have a type constraint defined for :Connectable
> (i.e., a property have that rdf:type must be some specific class), then it
> will be evaluated, but if you don’t, then, it does not matter what is the
> type of the value resource.
>
>
> Given your model, there are two ways to identify nodes to validate against
> :Connectable - 1)values of :connectsFrom for instances of SomeOtherClass
> and instances of Device and other target classes. This includes instances
> of subclass.
>
>
> On Jun 23, 2021, at 3:00 PM, Steve Ray  wrote:
>
> I forgot one detail, which is that I have a subClassOf hierarchy under
> Device, and the instances of any of those subClasses do not seem to
> validate against the Connectable shape. Does sh:node traverse the
> subClassOf hierarchy of the sh:targetClass values?
>
> Steve
>
>
>
>
> On Wed, Jun 23, 2021 at 11:47 AM Irene Polikoff 
> wrote:
>
>> What behaviour did you expect?
>>
>> Since Connectable is just a shape and does not have any instances, then
>> you can’t use it in sh:class. This constraint says that the value must be
>> an instance of Connectable, which will always be wrong.
>>
>> When you say sh:node s223:Connectable, it means that values should
>> validate against the constraints defined for Connectable. For this scenario
>> targets associated with Connectable are ignored since the constraint is
>> already targeting - all values of s223:connectedFrom that belong to members
>> of SomeOtherClass will be validated against the shape.
>>
>> All instances of Device, DomainSpace and Sensor will also be validated
>> against the Connectable shape - because of the target statements.
>>
>> https://www.w3.org/TR/shacl/#NodeConstraintComponent
>>
>> https://www.w3.org/TR/shacl/#focusNodes
>>
>> On Jun 23, 2021, at 1:19 PM, Steve Ray  wrote:
>>
>> The discussion you have been having regarding sh:targetClass reminds me
>> of a problem I am having, as follows.
>>
>> I'm defining an abstract "mixin" shape, Connectable, that has various
>> properties used by a number of target classes. I do not want to allow
>> instantiation of Connectable, so I defined it only as a NodeShape, but not
>> an owl:Class. (I cannot use the dash:abstract property without stepping
>> outside strict SHACL). Then, I need other classes to have the equivalent of
>> a sh:class constraint on properties that point to instances of all those
>> target classes. I assume I cannot use sh:class as in the example below,
>> since Connectable is not a class. I tried sh:node, since the documentation
>> implies that's what I need, but I'm not getting the expected behavior.
>>
>> Am I misunderstanding the use of sh:node?
>>
>> s223:Connectable
>> a sh:NodeShape ;
>> ...various properties
>> sh:targetClass s223:Device ;
>> sh:targetClass s223:DomainSpace ;
>> sh:targetClass s223:Sensor ;
>> .
>>
>> s223:Device
>> a owl:Class ;
>> a sh:NodeShape ;
>> ...
>> .
>>
>> # Presumed invalid case
>> s223:SomeOtherClass
>> a owl:Class ;
>> a sh:NodeShape ;
>> sh:property [
>> sh:path s223:connectsFrom ;
>> sh:class s223:Connectable ;
>> ...
>>
>> #Expected valid case
>> s223:SomeOtherClass
>> a owl:Class ;
>> a sh:NodeShape ;
>> sh:property [
>> sh:path s223:connectsFrom ;
>> sh:node s223:Connectable ;
>> ...
>>
>>
>> Steve
>>
>>
>>
>> --
>> 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 topbraid-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/topbraid-users/CAGUep86aRz_enWzvhfMkT5pW0SvNA3XYdbdB%2BAsSXP%3DfEFAusQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/topbraid-users/CAGUep86aRz_enWzvhfMkT5pW0SvNA3XYdbdB%2BAsSXP%3DfEFAusQ%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>>
>>
>> --
>> You received this m

Re: [topbraid-users] sh:targetClass question

[Steve Ray]

I forgot one detail, which is that I have a subClassOf hierarchy under
Device, and the instances of any of those subClasses do not seem to
validate against the Connectable shape. Does sh:node traverse the
subClassOf hierarchy of the sh:targetClass values?

Steve




On Wed, Jun 23, 2021 at 11:47 AM Irene Polikoff 
wrote:

> What behaviour did you expect?
>
> Since Connectable is just a shape and does not have any instances, then
> you can’t use it in sh:class. This constraint says that the value must be
> an instance of Connectable, which will always be wrong.
>
> When you say sh:node s223:Connectable, it means that values should
> validate against the constraints defined for Connectable. For this scenario
> targets associated with Connectable are ignored since the constraint is
> already targeting - all values of s223:connectedFrom that belong to members
> of SomeOtherClass will be validated against the shape.
>
> All instances of Device, DomainSpace and Sensor will also be validated
> against the Connectable shape - because of the target statements.
>
> https://www.w3.org/TR/shacl/#NodeConstraintComponent
>
> https://www.w3.org/TR/shacl/#focusNodes
>
> On Jun 23, 2021, at 1:19 PM, Steve Ray  wrote:
>
> The discussion you have been having regarding sh:targetClass reminds me of
> a problem I am having, as follows.
>
> I'm defining an abstract "mixin" shape, Connectable, that has various
> properties used by a number of target classes. I do not want to allow
> instantiation of Connectable, so I defined it only as a NodeShape, but not
> an owl:Class. (I cannot use the dash:abstract property without stepping
> outside strict SHACL). Then, I need other classes to have the equivalent of
> a sh:class constraint on properties that point to instances of all those
> target classes. I assume I cannot use sh:class as in the example below,
> since Connectable is not a class. I tried sh:node, since the documentation
> implies that's what I need, but I'm not getting the expected behavior.
>
> Am I misunderstanding the use of sh:node?
>
> s223:Connectable
> a sh:NodeShape ;
> ...various properties
> sh:targetClass s223:Device ;
> sh:targetClass s223:DomainSpace ;
> sh:targetClass s223:Sensor ;
> .
>
> s223:Device
> a owl:Class ;
> a sh:NodeShape ;
> ...
> .
>
> # Presumed invalid case
> s223:SomeOtherClass
> a owl:Class ;
> a sh:NodeShape ;
> sh:property [
> sh:path s223:connectsFrom ;
> sh:class s223:Connectable ;
> ...
>
> #Expected valid case
> s223:SomeOtherClass
> a owl:Class ;
> a sh:NodeShape ;
> sh:property [
> sh:path s223:connectsFrom ;
> sh:node s223:Connectable ;
> ...
>
>
> Steve
>
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CAGUep86aRz_enWzvhfMkT5pW0SvNA3XYdbdB%2BAsSXP%3DfEFAusQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/topbraid-users/CAGUep86aRz_enWzvhfMkT5pW0SvNA3XYdbdB%2BAsSXP%3DfEFAusQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/3A11B544-71EA-48BD-B068-0BA71EBD5E1D%40topquadrant.com
> <https://groups.google.com/d/msgid/topbraid-users/3A11B544-71EA-48BD-B068-0BA71EBD5E1D%40topquadrant.com?utm_medium=email_source=footer>
> .
>

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep86S_teBHHHDmhb13U1sQ4ctx197%3D2LLb60p8BtwiRK69A%40mail.gmail.com.

[topbraid-users] sh:targetClass question

[Steve Ray]

The discussion you have been having regarding sh:targetClass reminds me of
a problem I am having, as follows.

I'm defining an abstract "mixin" shape, Connectable, that has various
properties used by a number of target classes. I do not want to allow
instantiation of Connectable, so I defined it only as a NodeShape, but not
an owl:Class. (I cannot use the dash:abstract property without stepping
outside strict SHACL). Then, I need other classes to have the equivalent of
a sh:class constraint on properties that point to instances of all those
target classes. I assume I cannot use sh:class as in the example below,
since Connectable is not a class. I tried sh:node, since the documentation
implies that's what I need, but I'm not getting the expected behavior.

Am I misunderstanding the use of sh:node?

s223:Connectable
a sh:NodeShape ;
...various properties
sh:targetClass s223:Device ;
sh:targetClass s223:DomainSpace ;
sh:targetClass s223:Sensor ;
.

s223:Device
a owl:Class ;
a sh:NodeShape ;
...
.

# Presumed invalid case
s223:SomeOtherClass
a owl:Class ;
a sh:NodeShape ;
sh:property [
sh:path s223:connectsFrom ;
sh:class s223:Connectable ;
...

#Expected valid case
s223:SomeOtherClass
a owl:Class ;
a sh:NodeShape ;
sh:property [
sh:path s223:connectsFrom ;
sh:node s223:Connectable ;
...


Steve

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep86aRz_enWzvhfMkT5pW0SvNA3XYdbdB%2BAsSXP%3DfEFAusQ%40mail.gmail.com.

Re: [topbraid-users] Staying with official SHACL

[Steve Ray]

Hi Holger,
Things are looking good on my end using TBC 7.0.1 and only importing the
SHACL URI and not dash or tosh. Running SHACL reasoning and
SHACL validation both seem to work reliably. I'm assuming that, as you
mentioned, dash and/or tosh are brought in automatically if needed.

The only exception is a summer student working on the standards project who
is using the TBC Free edition (which seems to have moved backwards to
6.0.1). It seems to choke when validating because it isn't finding some
tosh objects.
(Caused by: java.lang.IllegalArgumentException: Shapes graph does not
include tosh:http://datashapes.org/dash#DefaultValueTypeRule)

The workaround for the student is just to have him explicitly import
dash.ttl whenever he wants to run the validator, but remove it before doing
his git push. I know that you all aren't supporting TBC Free any more, but
I just wanted to confirm that this is expected behavior.

Steve




On Sun, Jun 20, 2021 at 3:58 PM Holger Knublauch 
wrote:

> In addition to the extra constraint components
>
> http://datashapes.org/constraints.html
>
> the dash namespace also imports the tosh namespace, which contains
> constraints on the SHACL metamodel and therefore is used to drive the forms
> in EDG.
>
> What you do with the files generated with TopBraid outside of TopBraid is
> of course your own decision. I assume all standards-compliant SHACL
> validation engines will support at least SHACL Core without any mandatory
> owl:imports. In the SHACL API that I wrote, the code uses dash and tosh
> internally to identify the constraint components, so they are internally
> added in case they don't exist in the provided shapes graph. But this
> happens automatically.
>
> Holger
>
>
> On 2021-06-20 7:48 am, Steve Ray wrote:
>
> Very cool! With bated breath, I tried it, and nothing blew up!
>
> It would be good to know at some point what functionality I lose by
> directly importing
> owl:imports <http://www.w3.org/ns/shacl#> ;
> instead of
>   owl:imports <http://datashapes.org/dash> ;
> Steve
>
>
>
>
> On Sat, Jun 19, 2021 at 3:36 AM David Price 
> wrote:
>
>> Hi Steve and Michel
>>
>> I’m not near my computer so cannot do it for you, but suggest replacing
>> dash import with SHACL import and trying it. I think that’s ok.
>>
>> Cheers,
>> David
>>
>> On 19 Jun 2021, at 08:44, 'Bohms, H.M. (Michel)' via TopBraid Suite Users
>>  wrote:
>>
>> 
>>
>> I have exactly the same issue in CEN TC442/WG4/TG3 ….
>>
>>
>>
>> I now have:
>>
>>
>>
>> # baseURI: https://w3id.org/sml/shacl/def
>>
>> # imports: https://w3id.org/sml/rdfs/def
>>
>> # imports: http://datashapes.org/dash
>>
>> # imports: http://qudt.org/schema/qudt
>>
>> # imports: http://qudt.org/vocab/quantitykind
>>
>> # imports: http://qudt.org/vocab/unit
>>
>> # imports: http://www.w3.org/2004/02/skos/core
>>
>> # imports: https://www.w3.org/2006/time
>>
>> # prefix: sml
>>
>>
>>
>> @prefix dash: <http://datashapes.org/dash#> .
>>
>> @prefix sml: <https://w3id.org/sml/def#> .
>>
>> @prefix owl: <http://www.w3.org/2002/07/owl#> .
>>
>> @prefix quantitykind: <http://qudt.org/vocab/quantitykind/> .
>>
>> @prefix qudt: <http://qudt.org/schema/qudt/> .
>>
>> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
>>
>> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
>>
>> @prefix sh: <http://www.w3.org/ns/shacl#> .
>>
>> @prefix skos: <http://www.w3.org/2004/02/skos/core#> .
>>
>> @prefix time: <http://www.w3.org/2006/time#> .
>>
>> @prefix unit: <http://qudt.org/vocab/unit/> .
>>
>> @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
>>
>>
>>
>> <https://w3id.org/sml/shacl/def>
>>
>>   a owl:Ontology ;
>>
>>   owl:imports <https://w3id.org/sml/rdfs/def> ;
>>
>>   owl:imports <http://datashapes.org/dash> ;
>>
>>   owl:imports <http://qudt.org/schema/qudt> ;
>>
>>   owl:imports <http://qudt.org/vocab/quantitykind> ;
>>
>>   owl:imports <http://qudt.org/vocab/unit> ;
>>
>>   owl:imports <https://www.w3.org/2006/time> ;
>>
>> .
>>
>> Etc.
>>
>>
>>
>> But people question the red.
>>
>>
>>
>> Thx michel
>>
>>
>>
>>
>>
>> Dr. ir. H.M. (Michel) Bohms
>> Scientist Specialist
>> Structural Reliabil

Re: [topbraid-users] Staying with official SHACL

[Steve Ray]

Very cool! With bated breath, I tried it, and nothing blew up!

It would be good to know at some point what functionality I lose by
directly importing
owl:imports <http://www.w3.org/ns/shacl#> ;
instead of
  owl:imports <http://datashapes.org/dash> ;

Steve




On Sat, Jun 19, 2021 at 3:36 AM David Price  wrote:

> Hi Steve and Michel
>
> I’m not near my computer so cannot do it for you, but suggest replacing
> dash import with SHACL import and trying it. I think that’s ok.
>
> Cheers,
> David
>
> On 19 Jun 2021, at 08:44, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <
> topbraid-users@googlegroups.com> wrote:
>
> 
>
> I have exactly the same issue in CEN TC442/WG4/TG3 ….
>
>
>
> I now have:
>
>
>
> # baseURI: https://w3id.org/sml/shacl/def
>
> # imports: https://w3id.org/sml/rdfs/def
>
> # imports: http://datashapes.org/dash
>
> # imports: http://qudt.org/schema/qudt
>
> # imports: http://qudt.org/vocab/quantitykind
>
> # imports: http://qudt.org/vocab/unit
>
> # imports: http://www.w3.org/2004/02/skos/core
>
> # imports: https://www.w3.org/2006/time
>
> # prefix: sml
>
>
>
> @prefix dash: <http://datashapes.org/dash#> .
>
> @prefix sml: <https://w3id.org/sml/def#> .
>
> @prefix owl: <http://www.w3.org/2002/07/owl#> .
>
> @prefix quantitykind: <http://qudt.org/vocab/quantitykind/> .
>
> @prefix qudt: <http://qudt.org/schema/qudt/> .
>
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
>
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
>
> @prefix sh: <http://www.w3.org/ns/shacl#> .
>
> @prefix skos: <http://www.w3.org/2004/02/skos/core#> .
>
> @prefix time: <http://www.w3.org/2006/time#> .
>
> @prefix unit: <http://qudt.org/vocab/unit/> .
>
> @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
>
>
>
> <https://w3id.org/sml/shacl/def>
>
>   a owl:Ontology ;
>
>   owl:imports <https://w3id.org/sml/rdfs/def> ;
>
>   owl:imports <http://datashapes.org/dash> ;
>
>   owl:imports <http://qudt.org/schema/qudt> ;
>
>   owl:imports <http://qudt.org/vocab/quantitykind> ;
>
>   owl:imports <http://qudt.org/vocab/unit> ;
>
>   owl:imports <https://www.w3.org/2006/time> ;
>
> .
>
> Etc.
>
>
>
> But people question the red.
>
>
>
> Thx michel
>
>
>
>
>
> Dr. ir. H.M. (Michel) Bohms
> Scientist Specialist
> Structural Reliability
>
> T +31 (0)88 866 31 07
> M +31 (0)63 038 12 20
> E michel.bo...@tno.nl
>
> Location <http://www.tno.nl/locations/DTS>
>
>
>
> <http://www.tno.nl/>
>  <http://www.tno.nl/>
>
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use
> it and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
>
>
>
> *Van:* topbraid-users@googlegroups.com  
> *Namens
> *Steve Ray
> *Verzonden:* vrijdag 18 juni 2021 21:58
> *Aan:* TopBraid Suite Users 
> *Onderwerp:* [topbraid-users] Staying with official SHACL
>
>
>
> Hi, I'm working with a standards committee that would rather avoid
> straying outside the official W3C SHACL standard. My question is, if I
> removed the import of datashapes.org/dash from the files I'm working
> with, does this bring the TopQuadrant tools to a crashing halt as far as
> running the SHACL reasoner?
>
>
>
> I suppose another way of asking this is whether SHACL is built in to TBC
> under the hood, or is the dash import part of that?
>
>
>
>
> Steve
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CAGUep84C6i_88CtyP2ySiMBO-%2B2S_4p94Qxvt3N3Q%3DBipW2h1A%40mail.gmail.com
> <https://groups.google.com/d/msgid/topbraid-users/CAGUep84C6i_88CtyP2ySiMBO-%2B2S_4p94Qxvt3N3Q%3DBipW2h1A%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> --
> 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 topbr

[topbraid-users] Staying with official SHACL

[Steve Ray]

Hi, I'm working with a standards committee that would rather avoid straying
outside the official W3C SHACL standard. My question is, if I removed the
import of datashapes.org/dash from the files I'm working with, does this
bring the TopQuadrant tools to a crashing halt as far as running the
SHACL reasoner?

I suppose another way of asking this is whether SHACL is built in to TBC
under the hood, or is the dash import part of that?


Steve

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep84C6i_88CtyP2ySiMBO-%2B2S_4p94Qxvt3N3Q%3DBipW2h1A%40mail.gmail.com.

[topbraid-users] Can a SHACL rule check on a validation test?

[Steve Ray]

Let's suppose I'd like to execute a sh:SPARQLRule to infer something, but
only if various shape validations have been satisfied. Is there a way I can
confirm that inside the rule with a statement in my WHERE clause that that
is the case?

I typically use anonymous nodes when declaring the shapes, but I can see
how that might present a problem when I'm trying to ask if a particular
shape conforms. Would I be able to say something like:

...
WHERE {
 sh:conforms true .
...

Bottom line, I'd like my rule to fire only when the validations have passed.

Thanks for any pointers,

Steve

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep86OU7YRFXV_1DReU8eGOo%2B%2BeYXA7sWGoL_EaQfdE1514Q%40mail.gmail.com.

Re: [topbraid-users] Trying to update a graph using an Active Data Shape service

[Steve Ray]

Thanks for your always informative help. I did get this to work, only to
realize that I now have a web service that will update the graph living in
the EDG database, but not a web service that will update the Turtle file on
my local machine, which is ultimately my goal.

So, I have learned about dash:GraphService and dash:ResourceService, and
now am starting to learn about dash:ModifyAction as something I may need to
use. However, is ModifyAction designed more for creating ui actions in EDG?
Should I just be using dash:GraphService and use a call
to graph.uploadedFile? If so, after modifying the graph, is there some sort
of graph.saveFile (which I cannot find). Also, why is graph.uploadedFile
crossed out in the script editor pull-down?
[image: image.png]

I'm hoping these questions are of general interest. Basically I'm trying to
use web services to maintain local files, and I call these web services
from shell scripts. That's how we publish all our web pages.

Steve




On Thu, Apr 1, 2021 at 9:11 PM Holger Knublauch 
wrote:

> Hi Steve,
>
> On 1 Apr 2021, at 10:26 am, Steve Ray  wrote:
>
> Hi, I have a question about accomplishing the above.
>
> 1. How do I make my graph not a "read-only" graph?
> 
>
>
> The Script Editor panel has an unlock button/setting in the upper right
> corner. This toggles between read-only and writable APIs. The writable APIs
> have additional functions etc.
>
> I have set "Enable SPARQL updates" to true in Server Configuration.
> The graph in question is the focus graph in my local EDG.
> I have ensured Administrator is listed as both Manager and Editor for the
> graph in EDG Permissions Management.
> I am using the default settings in Rights Management
>
> Here's the code I'm trying to run in the Script Editor:
> graph.update(`DELETE {
> ?qk qudt:applicableUnit ?unit .
> }
> INSERT {
> ?newqk qudt:applicableUnit ?newunit .
> }
> WHERE {
> {
> ?qk a qudt:QuantityKind .
> ?qk qudt:applicableUnit ?unit .
> }
> UNION
> {
> ?newqk a qudt:QuantityKind .
> ?newqk qudt:inferredApplicableUnit ?newunit .
> } .
> } `)
>
> I get the same error when invoking the service from a web browser:
>
>
> http://localhost:8083/tbl/service/qudt_quantitykind/qudt/refreshApplicableUnits
>
> yields:
>
> Cannot evaluate Script:org.topbraid.core.servlet.HttpErrorException: Failed 
> service request /qudt_quantitykind/qudt/refreshApplicableUnits: Attempt to 
> change a read-only graph rejected
>
>
> Here's my service definition code:
>
> qudt:refreshApplicableUnits
>   rdf:type dash:GraphService ;
>   dash:js """graph.update(`
> DELETE {
> ?qk qudt:applicableUnit ?unit .
> }
> INSERT {
> ?newqk qudt:applicableUnit ?newunit .
> }
> WHERE {
> {
> ?qk a qudt:QuantityKind .
> ?qk qudt:applicableUnit ?unit .
> }
> UNION
> {
> ?newqk a qudt:QuantityKind .
> ?newqk qudt:inferredApplicableUnit ?newunit .
> } .
> }
> `)
> """ ;
>   dash:responseContentType "void" ;
>   rdfs:label "Refresh the applicableUnits property" ;
> .
>
> To enable updates, add dash:canWrite true.
>
> Holger
>
>
>
> There must be a setting I'm missing!
> Thanks in advance for your help.
>
> Steve
>
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CAGUep84svBqwK9G7545srJ5FziguTvK3JhUuUN8ztVgi5ZOkug%40mail.gmail.com
> <https://groups.google.com/d/msgid/topbraid-users/CAGUep84svBqwK9G7545srJ5FziguTvK3JhUuUN8ztVgi5ZOkug%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/DB84CB8F-AC83-4C31-8537-AD0E4C600B03%40topquadrant.com
> <https://groups.google.com/d/msgid/topbraid-users/DB84CB8F-AC83-4C31-8537-AD0E4C600B03%40topquadrant.com?utm_medium=email_source=footer>
> .
>

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep84xVf6xq0ngAQgE%2B9PBNSkp-Xv4EUR8UD5_z6yAbO2Pbg%40mail.gmail.com.

[topbraid-users] Trying to update a graph using an Active Data Shape service

[Steve Ray]

Hi, I have a question about accomplishing the above.

1. How do I make my graph not a "read-only" graph?
[image: image.png]
I have set "Enable SPARQL updates" to true in Server Configuration.
The graph in question is the focus graph in my local EDG.
I have ensured Administrator is listed as both Manager and Editor for the
graph in EDG Permissions Management.
I am using the default settings in Rights Management

Here's the code I'm trying to run in the Script Editor:
graph.update(`DELETE {
?qk qudt:applicableUnit ?unit .
}
INSERT {
?newqk qudt:applicableUnit ?newunit .
}
WHERE {
{
?qk a qudt:QuantityKind .
?qk qudt:applicableUnit ?unit .
}
UNION
{
?newqk a qudt:QuantityKind .
?newqk qudt:inferredApplicableUnit ?newunit .
} .
} `)

I get the same error when invoking the service from a web browser:

http://localhost:8083/tbl/service/qudt_quantitykind/qudt/refreshApplicableUnits

yields:

Cannot evaluate Script:org.topbraid.core.servlet.HttpErrorException:
Failed service request /qudt_quantitykind/qudt/refreshApplicableUnits:
Attempt to change a read-only graph rejected


Here's my service definition code:

qudt:refreshApplicableUnits
  rdf:type dash:GraphService ;
  dash:js """graph.update(`
DELETE {
?qk qudt:applicableUnit ?unit .
}
INSERT {
?newqk qudt:applicableUnit ?newunit .
}
WHERE {
{
?qk a qudt:QuantityKind .
?qk qudt:applicableUnit ?unit .
}
UNION
{
?newqk a qudt:QuantityKind .
?newqk qudt:inferredApplicableUnit ?newunit .
} .
}
`)
""" ;
  dash:responseContentType "void" ;
  rdfs:label "Refresh the applicableUnits property" ;
.


There must be a setting I'm missing!
Thanks in advance for your help.

Steve

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep84svBqwK9G7545srJ5FziguTvK3JhUuUN8ztVgi5ZOkug%40mail.gmail.com.

[topbraid-users] Feedback on TBC 7.0

[Steve Ray]

After some experimentation, I have found that just starting TBCME 7.0,
without going on to open any folders or starting the local EDG server
explicitly, is not sufficient to start the local TBL server.
I need to either open a project folder or start EDG, and then after a bit
of a delay for things to load, I can make SWP or ADS service calls.

Is this intentional?

Steve

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep86w-2GXNpKzdoJurKdeLySH7ujQS7C%2BXoF7RGuqXrnbzQ%40mail.gmail.com.

Re: [topbraid-users] Problems defining prefixes in SPARQL-based shapes

[Steve Ray]

Wonderful! It works!

Also, point taken on the mismatch between baseURI statement and
owl:Ontology statement. I had thrown together the two examples and
overlooked that bit of housekeeping.

For anybody else who is interested, I'm attaching the working example using
prefixes (and fixing the above baseURI/owl:Ontology mismatch).

Steve




On Mon, Mar 22, 2021 at 4:49 PM Holger Knublauch 
wrote:

> In your first example, add
>
>   sh:rule [
>   a sh:SPARQLRule ;
>   sh:prefixes
> <http://data.ashrae.org/standard223/1.0/inference/owl-subset>
> <http://data.ashrae.org/standard223/1.0/inference/owl-subset> ;
>
> because
>
> <http://data.ashrae.org/standard223/1.0/inference/owl-subset>
> <http://data.ashrae.org/standard223/1.0/inference/owl-subset>
> sh:declare [
>   sh:namespace "http://www.w3.org/2002/07/owl#;
> <http://www.w3.org/2002/07/owl#>^^xsd:anyURI ;
>   sh:prefix "owl" ;
> ] .
>
> is already a correct prefix declaration.
>
> If you attempt something like in your second example:
>
>   sh:prefixes <http://www.w3.org/2002/07/owl>
> <http://www.w3.org/2002/07/owl> ;
>
> then the assumption is that the following triples are present
>
> <http://www.w3.org/2002/07/owl> <http://www.w3.org/2002/07/owl>
> sh:declare [
>   sh:namespace "http://www.w3.org/2002/07/owl#;
> <http://www.w3.org/2002/07/owl#>^^xsd:anyURI ;
>   sh:prefix "owl" ;
> ] .
>
> which they are not.
>
> There is clear evidence that too many people struggle with this aspect of
> the SHACL spec, and that as an editor I should have done a better job
> there. If I could simply re-upload the SHACL spec this would be the first
> thing to fix. However, the formal W3C process doesn't allow this easily.
>
> I have to admit I never liked to even have the need to declare those
> namespaces as triples - this is a mixed blessing because nobody seems to
> understand the syntax yet namespace prefixes are a serialization concept
> only, not a graph concept. At some stage I may just give up on this and
> change our SHACL engine to simply add the declared prefixes from the files,
> like SPIN did for pragmatic reasons, ignoring the spec.
>
> BTW both examples have a mismatch between the baseURI and the
> owl:Ontology. I suggest to keep them aligned.
>
> HTH
> Holger
>
>
> On 2021-03-23 6:40 am, Steve Ray wrote:
>
> I have been working around this problem by avoiding any prefixes when
> defining a shape with SPARQL, but this still bugs me. Attached are two tiny
> files, epp1.shapes.ttl and epp2.shapes.ttl.
>
> I'm running the SHACL reasoner.
> epp1 works - it does not use any prefixes inside the shape.
> epp2 is identical to epp1, except it declares the owl: prefix in the
> shape.
>
> TBC complains that it cannot resolve owl:SymmetricProperty.
>
> I have tried following the documentation for this, but clearly I'm getting
> something wrong. What am I missing?
>
> Steve
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CAGUep85Rf1yk3YVsLV3ihJjso7w5uF%2BBGqFOSpPWybBCuGw6nQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/topbraid-users/CAGUep85Rf1yk3YVsLV3ihJjso7w5uF%2BBGqFOSpPWybBCuGw6nQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/e0633424-2ad7-12b8-e035-fd553f0e92ed%40topquadrant.com
> <https://groups.google.com/d/msgid/topbraid-users/e0633424-2ad7-12b8-e035-fd553f0e92ed%40topquadrant.com?utm_medium=email_source=footer>
> .
>

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep85tjkgCcuVxX4tH5%2B%3DHaX8Lh7fqpyyn_wODaGSh97pGhQ%40mail.gmail.com.


epp2.shapes.ttl
Description: Binary data

Re: [topbraid-users] Problems defining prefixes in SPARQL-based shapes

[Steve Ray]

I think the light bulb just went on.

Are you saying that the natural language interpretation of the sh:prefixes
triple *inside* a SPARQLRule is:

"Go to the following graph URI to get the definitions for the prefixes you
will need in the SPARQL query"...

...and in the ontology declaration, you use the sh:declare to do those
definitions.  (without wrapping those sh:declare statements inside a
sh:prefixes clause)?

(I will test this while waiting for the Australian day to begin. :)


Steve




On Mon, Mar 22, 2021 at 4:49 PM Holger Knublauch 
wrote:

> In your first example, add
>
>   sh:rule [
>   a sh:SPARQLRule ;
>   sh:prefixes
> <http://data.ashrae.org/standard223/1.0/inference/owl-subset>
> <http://data.ashrae.org/standard223/1.0/inference/owl-subset> ;
>
> because
>
> <http://data.ashrae.org/standard223/1.0/inference/owl-subset>
> <http://data.ashrae.org/standard223/1.0/inference/owl-subset>
> sh:declare [
>   sh:namespace "http://www.w3.org/2002/07/owl#;
> <http://www.w3.org/2002/07/owl#>^^xsd:anyURI ;
>   sh:prefix "owl" ;
> ] .
>
> is already a correct prefix declaration.
>
> If you attempt something like in your second example:
>
>   sh:prefixes <http://www.w3.org/2002/07/owl>
> <http://www.w3.org/2002/07/owl> ;
>
> then the assumption is that the following triples are present
>
> <http://www.w3.org/2002/07/owl> <http://www.w3.org/2002/07/owl>
> sh:declare [
>   sh:namespace "http://www.w3.org/2002/07/owl#;
> <http://www.w3.org/2002/07/owl#>^^xsd:anyURI ;
>   sh:prefix "owl" ;
> ] .
>
> which they are not.
>
> There is clear evidence that too many people struggle with this aspect of
> the SHACL spec, and that as an editor I should have done a better job
> there. If I could simply re-upload the SHACL spec this would be the first
> thing to fix. However, the formal W3C process doesn't allow this easily.
>
> I have to admit I never liked to even have the need to declare those
> namespaces as triples - this is a mixed blessing because nobody seems to
> understand the syntax yet namespace prefixes are a serialization concept
> only, not a graph concept. At some stage I may just give up on this and
> change our SHACL engine to simply add the declared prefixes from the files,
> like SPIN did for pragmatic reasons, ignoring the spec.
>
> BTW both examples have a mismatch between the baseURI and the
> owl:Ontology. I suggest to keep them aligned.
>
> HTH
> Holger
>
>
> On 2021-03-23 6:40 am, Steve Ray wrote:
>
> I have been working around this problem by avoiding any prefixes when
> defining a shape with SPARQL, but this still bugs me. Attached are two tiny
> files, epp1.shapes.ttl and epp2.shapes.ttl.
>
> I'm running the SHACL reasoner.
> epp1 works - it does not use any prefixes inside the shape.
> epp2 is identical to epp1, except it declares the owl: prefix in the
> shape.
>
> TBC complains that it cannot resolve owl:SymmetricProperty.
>
> I have tried following the documentation for this, but clearly I'm getting
> something wrong. What am I missing?
>
> Steve
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CAGUep85Rf1yk3YVsLV3ihJjso7w5uF%2BBGqFOSpPWybBCuGw6nQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/topbraid-users/CAGUep85Rf1yk3YVsLV3ihJjso7w5uF%2BBGqFOSpPWybBCuGw6nQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/e0633424-2ad7-12b8-e035-fd553f0e92ed%40topquadrant.com
> <https://groups.google.com/d/msgid/topbraid-users/e0633424-2ad7-12b8-e035-fd553f0e92ed%40topquadrant.com?utm_medium=email_source=footer>
> .
>

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep85BWQbeqdh35OGKrqcmG13TbTo%3DD7Or-QsVOQoFq61PUA%40mail.gmail.com.

Re: [topbraid-users] Problems defining prefixes in SPARQL-based shapes

[Steve Ray]

I'm afraid I spoke too soon. I added the sh:prefixes statement exactly as
in your response, and I'm still getting an unresolved prefix error.

<http://data.ashrae.org/standard223/1.0/inference/owl-subset>
a owl:Ontology ;
owl:imports <http://datashapes.org/dash> ;
owl:versionInfo "Created with TopBraid Composer" ;
sh:prefixes [sh:declare [
sh:namespace "http://www.w3.org/2002/07/owl#"^^xsd:anyURI ;
sh:prefix "owl" ;
] ;
] ;
.

Steve




On Mon, Mar 22, 2021 at 2:15 PM Irene Polikoff 
wrote:

> <http://data.ashrae.org/standard223/1.0/inference/owl-subset>
>   a owl:Ontology ;
>   owl:imports <http://datashapes.org/dash> ;
>   owl:versionInfo "Created with TopBraid Composer" ;
>   sh:prefixes [sh:declare [
>   sh:namespace "http://www.w3.org/2002/07/owl#"^^xsd:anyURI ;
>   sh:prefix "owl" ;
> ] ;];
>
> On Mar 22, 2021, at 4:40 PM, Steve Ray  wrote:
>
> I have been working around this problem by avoiding any prefixes when
> defining a shape with SPARQL, but this still bugs me. Attached are two tiny
> files, epp1.shapes.ttl and epp2.shapes.ttl.
>
> I'm running the SHACL reasoner.
> epp1 works - it does not use any prefixes inside the shape.
> epp2 is identical to epp1, except it declares the owl: prefix in the
> shape.
>
> TBC complains that it cannot resolve owl:SymmetricProperty.
>
> I have tried following the documentation for this, but clearly I'm getting
> something wrong. What am I missing?
>
> Steve
>
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CAGUep85Rf1yk3YVsLV3ihJjso7w5uF%2BBGqFOSpPWybBCuGw6nQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/topbraid-users/CAGUep85Rf1yk3YVsLV3ihJjso7w5uF%2BBGqFOSpPWybBCuGw6nQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
> 
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/159328BE-4286-447E-BDA7-0827C564A2E3%40topquadrant.com
> <https://groups.google.com/d/msgid/topbraid-users/159328BE-4286-447E-BDA7-0827C564A2E3%40topquadrant.com?utm_medium=email_source=footer>
> .
>

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep86ejo%3Dz2-xzEC%2Bjq%2Bxp1dRetCYnbPuNJt586aL7zPMofA%40mail.gmail.com.

Re: [topbraid-users] Problems defining prefixes in SPARQL-based shapes

[Steve Ray]

Wow! I could have saved so much time, had I asked earlier. The W3C SHACL
spec example misses the sh:prefixes statement in section 5.2.1 (
https://www.w3.org/TR/shacl/#sparql-prefixes).

Now I can go back and do it the way I thought it should work!

Parenthetically, I suppose there might be some rationale behind it, but it
seems very cumbersome to have to declare prefixes in three places:

@prefix at the top of the file
sh:prefixes in the Ontology declaration
sh:prefixes in the shape definition.

...and each with a slightly different syntax:
@prefix owl: <http://www.w3.org/2002/07/owl#> .
 sh:namespace "http://www.w3.org/2002/07/owl#"^^xsd:anyURI ;
 sh:prefixes <http://www.w3.org/2002/07/owl> ;

This is really a comment to W3C of course, not TopQuadrant.


Thanks for your speedy reply!
Steve




On Mon, Mar 22, 2021 at 2:15 PM Irene Polikoff 
wrote:

> <http://data.ashrae.org/standard223/1.0/inference/owl-subset>
>   a owl:Ontology ;
>   owl:imports <http://datashapes.org/dash> ;
>   owl:versionInfo "Created with TopBraid Composer" ;
>   sh:prefixes [sh:declare [
>   sh:namespace "http://www.w3.org/2002/07/owl#"^^xsd:anyURI ;
>       sh:prefix "owl" ;
> ] ;];
>
> On Mar 22, 2021, at 4:40 PM, Steve Ray  wrote:
>
> I have been working around this problem by avoiding any prefixes when
> defining a shape with SPARQL, but this still bugs me. Attached are two tiny
> files, epp1.shapes.ttl and epp2.shapes.ttl.
>
> I'm running the SHACL reasoner.
> epp1 works - it does not use any prefixes inside the shape.
> epp2 is identical to epp1, except it declares the owl: prefix in the
> shape.
>
> TBC complains that it cannot resolve owl:SymmetricProperty.
>
> I have tried following the documentation for this, but clearly I'm getting
> something wrong. What am I missing?
>
> Steve
>
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CAGUep85Rf1yk3YVsLV3ihJjso7w5uF%2BBGqFOSpPWybBCuGw6nQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/topbraid-users/CAGUep85Rf1yk3YVsLV3ihJjso7w5uF%2BBGqFOSpPWybBCuGw6nQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
> 
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/159328BE-4286-447E-BDA7-0827C564A2E3%40topquadrant.com
> <https://groups.google.com/d/msgid/topbraid-users/159328BE-4286-447E-BDA7-0827C564A2E3%40topquadrant.com?utm_medium=email_source=footer>
> .
>

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep86UgMuSQVUSvOQLGrSfeWyiArtCHuvkyijEtHiYgDpfDA%40mail.gmail.com.

[topbraid-users] Problems defining prefixes in SPARQL-based shapes

[Steve Ray]

I have been working around this problem by avoiding any prefixes when
defining a shape with SPARQL, but this still bugs me. Attached are two tiny
files, epp1.shapes.ttl and epp2.shapes.ttl.

I'm running the SHACL reasoner.
epp1 works - it does not use any prefixes inside the shape.
epp2 is identical to epp1, except it declares the owl: prefix in the shape.

TBC complains that it cannot resolve owl:SymmetricProperty.

I have tried following the documentation for this, but clearly I'm getting
something wrong. What am I missing?

Steve

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep85Rf1yk3YVsLV3ihJjso7w5uF%2BBGqFOSpPWybBCuGw6nQ%40mail.gmail.com.


epp1.shapes.ttl
Description: Binary data


epp2.shapes.ttl
Description: Binary data

Re: [topbraid-users] Trying to write out a Turtle serialized class definition

[Steve Ray]

Interesting. The DESCRIBE query sounds intriguing, but I need to create the
.ttl files so that when somebody types

http://qudt.org/schema/qudt/Unit

...it resolves to the Turtle code, without using a SPARQL endpoint.

Just like if you type http://qudt.org/vocab/unit/A you get the definition
of the Ampere. (Content negotiation will give you either html or ttl
depending on the header, so a browser yields html).

Can I use DESCRIBE inside a ui:TurtleServices web service? I tried with
ui:update, but that expects an INSERT or DELETE. Am I making this more
complicated than it needs to be?


Steve




On Wed, Mar 17, 2021 at 4:08 PM Holger Knublauch 
wrote:

> Hi Steve,
>
> you could just use SPARQL DESCRIBE queries, which will compute the graph
> for a resource including its depending blank nodes, e.g.
>
> DESCRIBE <http://topquadrant.com/ns/examples/geography#Country>
> <http://topquadrant.com/ns/examples/geography#Country>
>
> via the SPARQL endpoint.
>
> Holger
>
>
> On 2021-03-18 9:01 am, Steve Ray wrote:
>
> Hi,
> I'm using SWP to generate a bunch of .ttl files that will be available to
> the LinkedData community for resolving class definitions. I'm hoping to use
> the code below that works fine for our instance data, but this code doesn't
> do the right thing when there are bnodes (such as restriction classes).
> This is written as a ui prototype that is a subClass of ui:TurtleServices.
>
> *Is there some setting to have it also serialize the bnodes*? Here's the
> ui:prototype code:
>
> <*ui:group* let:*extension*=".ttl"
>
>   let:*myGraphU*="*{=* ui:graphWithImports(*IRI*(*?graph*)) *}*"
>
>   let:*myInstance*="*{=* *IRI*(*?instance*) *}*"
>
>   let:*newPath*="*{=* *CONCAT*(/generatedFiles/,
> xsd:string(*?folder*), /) *}*">
>
> <*ui:debug*>
>
> **Inside VersionlessIndividual. Value of ?newPath is *{=*
> ?newPath *}***
>
> 
>
> <*ui:dumpScope* ui:message="AAA:VersionlessIndividual, newPath= *{=*
> ?newPath *}*"/>
>
> <*ui:group* let:*localName*="*{=* afn:localname(?myInstance) *}*">
>
> <*ui:group* let:*newFile*="*{=* *CONCAT*(?newPath, ?localName,
> ?extension) *}*">
>
> <*ui:dumpResultSet* ui:message="AAA:VersionlessGraph,
> newUnit= " ui:resultSet="*{=* *?instance* *}*"/>
>
> <*ui:setContext* ui:silentTransactions="true">
>
> <*ui:setContext* ui:queryGraph="ui:tempGraph">
>
> **
>
> <*ui:update* ui:updateQuery="*{!*
>
> *DELETE* {
>
> *GRAPH* ui:tempGraph {
>
> ?s ?p ?o .
>
> } .
>
> }
>
> *WHERE* {
>
> ?s ?p ?o .
>
> } *}*"/>
>
> <*ui:update* ui:updateQuery="*{!*
>
> *INSERT* {
>
> *GRAPH* ui:tempGraph {
>
> ?myInstance ?p ?o .
>
> } .
>
> }
>
> *WHERE* {
>
> *GRAPH* ?myGraphU {
>
> ?myInstance ?p ?o .
>
> } .
>
> } *}*"/>
>
> <*ui:return*/>
>
> 
>
> 
>
> 
>
> 
>
> 
>
>
>
> ...which produces the following file:
>
>
> [image: image.png]
>
> I want all the stuff inside the [] to show up as well!
>
>
>
> Steve
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CAGUep85DXyHFA%3DwmgdArgZnw-k6EHPJ5AsRDwYsHBT65sU2csg%40mail.gmail.com
> <https://groups.google.com/d/msgid/topbraid-users/CAGUep85DXyHFA%3DwmgdArgZnw-k6EHPJ5AsRDwYsHBT65sU2csg%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "TopBraid Suite Users" group.
> To unsubscribe from th

[topbraid-users] Trying to write out a Turtle serialized class definition

[Steve Ray]

Hi,
I'm using SWP to generate a bunch of .ttl files that will be available to
the LinkedData community for resolving class definitions. I'm hoping to use
the code below that works fine for our instance data, but this code doesn't
do the right thing when there are bnodes (such as restriction classes).
This is written as a ui prototype that is a subClass of ui:TurtleServices.

*Is there some setting to have it also serialize the bnodes*? Here's the
ui:prototype code:

<*ui:group* let:*extension*=".ttl"

  let:*myGraphU*="*{=* ui:graphWithImports(*IRI*(*?graph*)) *}*"

  let:*myInstance*="*{=* *IRI*(*?instance*) *}*"

  let:*newPath*="*{=* *CONCAT*(/generatedFiles/,
xsd:string(*?folder*), /) *}*">

<*ui:debug*>

**Inside VersionlessIndividual. Value of ?newPath is *{=*
?newPath *}***



<*ui:dumpScope* ui:message="AAA:VersionlessIndividual, newPath= *{=*
?newPath *}*"/>

<*ui:group* let:*localName*="*{=* afn:localname(?myInstance) *}*">

<*ui:group* let:*newFile*="*{=* *CONCAT*(?newPath, ?localName,
?extension) *}*">

<*ui:dumpResultSet* ui:message="AAA:VersionlessGraph, newUnit=
" ui:resultSet="*{=* *?instance* *}*"/>

<*ui:setContext* ui:silentTransactions="true">

<*ui:setContext* ui:queryGraph="ui:tempGraph">

**

<*ui:update* ui:updateQuery="*{!*

*DELETE* {

*GRAPH* ui:tempGraph {

?s ?p ?o .

} .

}

*WHERE* {

?s ?p ?o .

} *}*"/>

<*ui:update* ui:updateQuery="*{!*

*INSERT* {

*GRAPH* ui:tempGraph {

?myInstance ?p ?o .

} .

}

*WHERE* {

*GRAPH* ?myGraphU {

?myInstance ?p ?o .

} .

} *}*"/>

<*ui:return*/>













...which produces the following file:


[image: image.png]

I want all the stuff inside the [] to show up as well!



Steve

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep85DXyHFA%3DwmgdArgZnw-k6EHPJ5AsRDwYsHBT65sU2csg%40mail.gmail.com.

[topbraid-users] Status of sh:values

[Steve Ray]

I have been taking advantage of sh:values in my work, but it was recently
pointed out to me that sh:values is not part of either the official SHACL
or SHACL AF. I'm wondering if you have any insight on whether it will be
officially part of SHACL AF any time soon?

(If not, I may need to recode using sh:rule... :(


Steve

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep84cwGJBm2f4DSeiEeJgdZE7f7jdoeYSLAZ_hUk3owXS_g%40mail.gmail.com.

Re: [topbraid-users] Graph view in TBC-ME

[Steve Ray]

Wow, so that's what that icon is for! Thanks.
Steve




On Mon, Jan 18, 2021 at 1:33 PM Irene Polikoff 
wrote:

> If you switch into the labels mode - Person icon in the header, next to
> the Home icon
>
> On Jan 18, 2021, at 2:01 PM, Steve Ray  wrote:
>
> I am increasingly using the Graph view to visualize complex instance
> topologies, and would really like to have the instance boxes displayed with
> their rdfs:labels instead of their URIs. Is this customizable? Something I
> could tweak in some display class?
>
> Steve
>
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CAGUep85zuk%3D04EW4Cd37UUu-dXW-TaYLT4FHtYXrcwo2bBDz8w%40mail.gmail.com
> <https://groups.google.com/d/msgid/topbraid-users/CAGUep85zuk%3D04EW4Cd37UUu-dXW-TaYLT4FHtYXrcwo2bBDz8w%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/97525DD1-77ED-4D88-B9EE-E1E215BD5F99%40topquadrant.com
> <https://groups.google.com/d/msgid/topbraid-users/97525DD1-77ED-4D88-B9EE-E1E215BD5F99%40topquadrant.com?utm_medium=email_source=footer>
> .
>

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep840MkO1U-6Lnryp8S_CCTreiqnN_azyfm-tsA1aD-MFzQ%40mail.gmail.com.

[topbraid-users] Graph view in TBC-ME

[Steve Ray]

I am increasingly using the Graph view to visualize complex instance
topologies, and would really like to have the instance boxes displayed with
their rdfs:labels instead of their URIs. Is this customizable? Something I
could tweak in some display class?

Steve

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep85zuk%3D04EW4Cd37UUu-dXW-TaYLT4FHtYXrcwo2bBDz8w%40mail.gmail.com.

Re: [topbraid-users] Understanding the limits of SHACL

[Steve Ray]

I see your point. Using sh:class still worked with the superclass
(c223:InletPoint).

Here is my working shape (this time for an InletPoint, which has a
subClassOf AirInletPoint):

b20:InletPressureShape

  rdf:type sh:PropertyShape ;

  sh:path c223:hasInletPressure ;

  sh:name "Inlet Pressure Shape" ;

  sh:values [

  sh:path c223:hasValue ;

  sh:nodes [

  sh:filterShape [

  sh:property [

  sh:path qudt:hasQuantityKind ;

  sh:hasValue qudtqk:Pressure ;

] ;

] ;

  sh:nodes [

  sh:path c223:hasProperty ;

  sh:nodes [

  sh:filterShape [

  sh:class c223:InletPoint ;

] ;

  sh:nodes [

  sh:path c223:hasConnectionPoint ;

] ;

] ;

] ;

] ;

] ;

.


I do find that I still need to run the SHACL reasoner before the
c223:hasInletPressure relation returns a result in the query below, but I
don't need to run the OWL RL rules.


*SELECT* *

*WHERE* {

?s c223:hasInletPressure ?press .

}





Steve




On Fri, Dec 11, 2020 at 4:29 PM Holger Knublauch 
wrote:

> On 2020-12-12 3:59 am, Steve Ray wrote:
>
> > Holger,
> > Your example is tremendously helpful! Thanks so much. I can see how
> > the sh:filterShape and sh:nodes statements always come in pairs, and
> > that the outermost sh:path (inside the sh:values) needs an sh:nodes to
> > operate on. These are all things that I wasn't sure about.
> >
> > I will use this approach in the future. In our work, we are going to
> > be assuming OWL RL reasoning, so the embedded sh:class
> > ex:AirOutletPoint should even work with a superClass, as in my
> > original example. I understand that if I don't run the OWL RL reasoner
> > first, then I would need to fall back to the SPARQL query approach if
> > I want to query against the superclass of AirOutletPoint.
>
> Just to be extra clear: sh:values expressions will not automatically use
> other types of reasoning such as OWL RL. Those triples would need to be
> asserted. However, operators such as sh:class will automatically walk
> up/down the rdfs:subClassOf hierarchy and thus have some kind of simple
> reasoning built in.
>
> Holger
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/b7b27a50-4c20-12d6-8981-2dbb533c0d08%40topquadrant.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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep879gDbYVpkziuqSt59%2BzXQP8ec1Q2xidwd%3D7D17S-v1Dg%40mail.gmail.com.

[topbraid-users] Understanding the limits of SHACL

[Steve Ray]

I'd like to run the following scenario by you to confirm whether my
understanding of what I can and cannot do with TBC and SHACL is correct.

Suppose I have the following pattern:

[image: image.png]

I want to use a SHACL PropertyShape with sh:values to give me an inferred
"shortcut" relation from Class A to Class D. However, in doing so, I want
to filter on values of Prop B and Prop C, so it is not just a simple matter
of a 3-step sh:path statement.
I read your documentation at https://www.topquadrant.com/graphql/values.html
with interest on this topic, and have concluded that while a single
PropertyShape cannot achieve this, I can nest two PropertyShapes:
the first gives me a filtered "shortcut" relation from Class A to Class C
(filtering on Prop B), which I can then use in defining a second filtered
"shortcut" that filters on Prop C and gets me to Class D. This conclusion
is based on the fact that one cannot nest sh:values statements inside a
single PropertyShape definition - is this true? (If it IS possible to nest
sh:values statements, does the inner sh:values statement play the role of
sh:nodes for the outer filterShape?)

Corollary questions:
Must Class A be the targetClass of both of the above PropertyShapes?
Must I run the SHACL reasoner beforehand for the inferred relations to be
usable?

I also tried to achieve the same behavior with an embedded SPARQL query
instead of native SHACL statements, which allowed me to create the inferred
shortcut relation with a single SPARQL query. However, as you document at the
same link above , under
the section "Use of Inferred Values using SPARQL", I can only use the
shortcut property if:
a) I use the   (?a ?shortcut-property) tosh:values ?d  syntax,
or
b) I run the SHACL reasoner before making a query.

Is this correct?

Finally, you also solicit feedback on whether the integration with SPARQL
should work more directly, without the use of the tosh:values magic
property, to which I will add a strong "YES PLEASE!". I say this because my
colleagues are looking for use-cases where the inferred shortcut property
is indistinguishable from a regular explicit property when querying.



Steve

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep8515RB8ZCxqx2YBou_dp%2BxyFKE5ZkRqB0Ho5jC-prixCQ%40mail.gmail.com.

Re: [topbraid-users] Trying to play nice with SHACL

[Steve Ray]

Oh dear. I'm doing this work in support of a standards committee where I'm
the only one using TBC. Others are using either Jena, or raw text editors
and home-rolled reasoners. (!) (I may be persuading one member to get TBC
though).

Of the solutions you are suggesting, which would you recommend that is the
most universal? Does Jena support SPIN (i.e. magic properties?). I'm
assuming tosh isn't available outside TBC/EDG?

Steve




On Tue, Nov 24, 2020 at 6:43 PM Holger Knublauch 
wrote:

>
> On 11/25/2020 12:32 PM, Steve Ray wrote:
>
> Wow, fast!
> I was just trying exactly that. I also dropped the prefixes since I wasn't
> using any. So now I have:
>
> ssh:Class_1
>
>   rdf:type owl:Class ;
>
>   rdf:type sh:NodeShape ;
>
>   rdfs:subClassOf owl:Thing ;
>
>   sh:property [
>
>   sh:path ssh:Property_1 ;
>
>   sh:values [
>
>   sh:select """SELECT ?result
>
>WHERE {
>
>BIND (\"Hello\" AS ?result) .
>
>}""" ;
>
> ] ;
>
> ] ;
>
> .
>
> So far so good.
>
>
> But executing this query:
>
>
> *SELECT* *
>
> *WHERE* {
>
> ?subject a ssh:Class_1 .
>
> ?subject ssh:Property_1 ?object .
>
> }
>
>
> ...is coming up empty.
>
> This is because SPARQL only queries the asserted graph. To query the
> inferred values, either use GraphQL, Active Data Shapes or use this magic
> property:
>
> PREFIX teamwork: <http://topbraid.org/teamwork#>
> <http://topbraid.org/teamwork#>
> SELECT *
> WHERE {
>   ...
>   (?subject ssh:Property_1 ) teamwork:values ?object
> .
> }
>
> This takes the master graph that is holding the data in EDG (here: the
> Geography ontology). This is the fastest variation for performance, but
> this one here is more general:
>
>   (?subject ssh:Property_1) tosh:values ?object .
>
> This design has some implications, e.g. you normally cannot query inferred
> values in the inverse direction, e.g. if ?object is given. They are just
> computed on the fly, for the duration of the query. This means that the
> system doesn't need to keep track of inferences or invalidate them if the
> data changes - it's always up to date.
>
> Holger
>
>
> (Once I get one example working, I'm off to the races!)
>
>
> Steve
>
>
>
>
> On Tue, Nov 24, 2020 at 6:25 PM Holger Knublauch 
> wrote:
>
>>
>> On 11/25/2020 12:18 PM, Steve Ray wrote:
>>
>> Sorry to keep using up bandwidth here.
>>
>> No problem. Admittedly, the official spec at
>> https://w3c.github.io/shacl/shacl-af/#select is not exactly full of
>> examples. A failure of the editor :)
>>
>>
>> I have pored over all the documentation I can find on the proper use of
>> sh:values with SPARQL, and clearly I'm not getting something. Here is my
>> trivial toy example that is supposed to just infer a hard-coded value of
>> "Hello" for a property. Can you see what I'm doing wrong?
>> TBC keeps saying: Property ssh:Property_1: values=(SHACL node expression
>> of unknown type: java.lang.IllegalArgumentException: Malformed SHACL node
>> expression)
>>
>>  I'm also attaching the full file in case you want to just load it.
>>
>> Just drop the sh:sparql node and instead do something like
>>
>> sh:values [
>> sh:select ...
>> sh:prefixes ...
>> ]
>>
>> HTH
>> Holger
>>
>>
>>
>> ssh:Class_1
>> a owl:Class ;
>> a sh:NodeShape ;
>> rdfs:subClassOf owl:Thing ;
>> sh:property [
>> sh:path ssh:Property_1 ;
>> sh:values [
>> sh:sparql [
>> sh:prefixes <http://example.org/sparqlshape> ;
>> sh:select """SELECT ?result
>> WHERE {
>> BIND (\"Hello\" AS ?result) .
>> }""" ;
>> ] ;
>> ] ;
>> ] ;
>> .
>> ssh:Instance_1
>> a ssh:Class_1 ;
>> .
>> ssh:Property_1
>> a rdf:Property ;
>> .
>>
>>
>> Steve
>>
>>
>>
>>
>> On Tue, Nov 24, 2020 at 2:57 PM Holger Knublauch 
>> wrote:
>>
>>>
>>> On 11/25/2020 8:48 AM, Steve Ray wrote:
>>>
>>> I agree with you. Is there no way to have "variable" predicates in
>>> native SHACL? Or is my only option here to use the embedded SPARQL?
>>>
>>> Exactly. SHACL node expressions do not have a notion of variables. It is
>>> intentionally limited to be easier, but then doesn't offer all features
>>&

Re: [topbraid-users] Trying to play nice with SHACL

[Steve Ray]

Wow, fast!
I was just trying exactly that. I also dropped the prefixes since I wasn't
using any. So now I have:

ssh:Class_1

  rdf:type owl:Class ;

  rdf:type sh:NodeShape ;

  rdfs:subClassOf owl:Thing ;

  sh:property [

  sh:path ssh:Property_1 ;

  sh:values [

  sh:select """SELECT ?result

   WHERE {

   BIND (\"Hello\" AS ?result) .

   }""" ;

] ;

] ;

.


But executing this query:


*SELECT* *

*WHERE* {

?subject a ssh:Class_1 .

?subject ssh:Property_1 ?object .

}


...is coming up empty.


(Once I get one example working, I'm off to the races!)


Steve




On Tue, Nov 24, 2020 at 6:25 PM Holger Knublauch 
wrote:

>
> On 11/25/2020 12:18 PM, Steve Ray wrote:
>
> Sorry to keep using up bandwidth here.
>
> No problem. Admittedly, the official spec at
> https://w3c.github.io/shacl/shacl-af/#select is not exactly full of
> examples. A failure of the editor :)
>
>
> I have pored over all the documentation I can find on the proper use of
> sh:values with SPARQL, and clearly I'm not getting something. Here is my
> trivial toy example that is supposed to just infer a hard-coded value of
> "Hello" for a property. Can you see what I'm doing wrong?
> TBC keeps saying: Property ssh:Property_1: values=(SHACL node expression
> of unknown type: java.lang.IllegalArgumentException: Malformed SHACL node
> expression)
>
>  I'm also attaching the full file in case you want to just load it.
>
> Just drop the sh:sparql node and instead do something like
>
> sh:values [
> sh:select ...
> sh:prefixes ...
> ]
>
> HTH
> Holger
>
>
>
> ssh:Class_1
> a owl:Class ;
> a sh:NodeShape ;
> rdfs:subClassOf owl:Thing ;
> sh:property [
> sh:path ssh:Property_1 ;
> sh:values [
> sh:sparql [
> sh:prefixes <http://example.org/sparqlshape> ;
> sh:select """SELECT ?result
> WHERE {
> BIND (\"Hello\" AS ?result) .
> }""" ;
> ] ;
> ] ;
> ] ;
> .
> ssh:Instance_1
> a ssh:Class_1 ;
> .
> ssh:Property_1
> a rdf:Property ;
> .
>
>
> Steve
>
>
>
>
> On Tue, Nov 24, 2020 at 2:57 PM Holger Knublauch 
> wrote:
>
>>
>> On 11/25/2020 8:48 AM, Steve Ray wrote:
>>
>> I agree with you. Is there no way to have "variable" predicates in native
>> SHACL? Or is my only option here to use the embedded SPARQL?
>>
>> Exactly. SHACL node expressions do not have a notion of variables. It is
>> intentionally limited to be easier, but then doesn't offer all features
>> that SPARQL does. There is nothing wrong with using SPARQL node expressions
>> as a fallback.
>>
>> Holger
>>
>>
>>
>> Steve
>>
>>
>>
>>
>> On Tue, Nov 24, 2020 at 12:51 PM Irene Polikoff 
>> wrote:
>>
>>> There is no path in your example that could get from ?this to ?prop. A
>>> path specifies predicates. You do not have predicates to specify - you are
>>> finding out your predicates in the first WHERE statement. This is why you
>>> need to have 2 statements in the WHERE clause and can’t boil them down to a
>>> path expression in a single statement.
>>>
>>> On Nov 24, 2020, at 12:39 PM, Steve Ray  wrote:
>>>
>>> I'm trying to get comfortable with using SHACL code and wean myself from
>>> embedded SPARQL. However, I'm having some trouble mapping certain common
>>> SPARQL patterns into the SHACL counterpart. Specifically, here's an
>>> example. I'm trying to find all the values of any property that is a
>>> subPropertyOf a parent property (c223:hasProperty).
>>> The SPARQL should (I think) be something like this:
>>>
>>> c223:PropertiesShape
>>>   rdf:type sh:PropertyShape ;
>>>   sh:path c223:hasProperty ;
>>>   sh:name "PropertiesShape" ;
>>>   sh:values [
>>>   sh:sparql [
>>>   sh:prefixes <http://www.w3.org/2000/01/rdf-schema> ;
>>>   sh:select """SELECT DISTINCT ?prop
>>>  WHERE {
>>>  ?property rdfs:subPropertyOf*
>>> c223:hasProperty .
>>>  $this ?property ?prop .
>>> }""" ;
>>> ] ;
>>> ] ;
>>> .
>>>
>>> I know the following is wrong, but not sure what sh: calls I should be
>>> using:
>>>
>>> c223:PropertiesShape
>>>   rdf:type sh:PropertyShape ;
>&g

Re: [topbraid-users] Trying to play nice with SHACL

[Steve Ray]

Sorry to keep using up bandwidth here. I have pored over all the
documentation I can find on the proper use of sh:values with SPARQL, and
clearly I'm not getting something. Here is my trivial toy example that is
supposed to just infer a hard-coded value of "Hello" for a property. Can
you see what I'm doing wrong?
TBC keeps saying: Property ssh:Property_1: values=(SHACL node expression of
unknown type: java.lang.IllegalArgumentException: Malformed SHACL node
expression)

 I'm also attaching the full file in case you want to just load it.

ssh:Class_1
a owl:Class ;
a sh:NodeShape ;
rdfs:subClassOf owl:Thing ;
sh:property [
sh:path ssh:Property_1 ;
sh:values [
sh:sparql [
sh:prefixes <http://example.org/sparqlshape> ;
sh:select """SELECT ?result
WHERE {
BIND (\"Hello\" AS ?result) .
}""" ;
] ;
] ;
] ;
.
ssh:Instance_1
a ssh:Class_1 ;
.
ssh:Property_1
a rdf:Property ;
.



Steve




On Tue, Nov 24, 2020 at 2:57 PM Holger Knublauch 
wrote:

>
> On 11/25/2020 8:48 AM, Steve Ray wrote:
>
> I agree with you. Is there no way to have "variable" predicates in native
> SHACL? Or is my only option here to use the embedded SPARQL?
>
> Exactly. SHACL node expressions do not have a notion of variables. It is
> intentionally limited to be easier, but then doesn't offer all features
> that SPARQL does. There is nothing wrong with using SPARQL node expressions
> as a fallback.
>
> Holger
>
>
>
> Steve
>
>
>
>
> On Tue, Nov 24, 2020 at 12:51 PM Irene Polikoff 
> wrote:
>
>> There is no path in your example that could get from ?this to ?prop. A
>> path specifies predicates. You do not have predicates to specify - you are
>> finding out your predicates in the first WHERE statement. This is why you
>> need to have 2 statements in the WHERE clause and can’t boil them down to a
>> path expression in a single statement.
>>
>> On Nov 24, 2020, at 12:39 PM, Steve Ray  wrote:
>>
>> I'm trying to get comfortable with using SHACL code and wean myself from
>> embedded SPARQL. However, I'm having some trouble mapping certain common
>> SPARQL patterns into the SHACL counterpart. Specifically, here's an
>> example. I'm trying to find all the values of any property that is a
>> subPropertyOf a parent property (c223:hasProperty).
>> The SPARQL should (I think) be something like this:
>>
>> c223:PropertiesShape
>>   rdf:type sh:PropertyShape ;
>>   sh:path c223:hasProperty ;
>>   sh:name "PropertiesShape" ;
>>   sh:values [
>>   sh:sparql [
>>   sh:prefixes <http://www.w3.org/2000/01/rdf-schema> ;
>>   sh:select """SELECT DISTINCT ?prop
>>  WHERE {
>>  ?property rdfs:subPropertyOf*
>> c223:hasProperty .
>>  $this ?property ?prop .
>> }""" ;
>> ] ;
>> ] ;
>> .
>>
>> I know the following is wrong, but not sure what sh: calls I should be
>> using:
>>
>> c223:PropertiesShape
>>   rdf:type sh:PropertyShape ;
>>   sh:path c223:hasProperty ;
>>   sh:name "PropertiesShape" ;
>>   sh:values [
>>   sh:distinct [
>>   sh:nodes [
>>   sh:path (
>>   [
>> sh:zeroOrMorePath rdfs:subPropertyOf ;
>>   ]
>>   c223:hasProperty
>> ) ;
>> ] ;
>> ] ;
>> ] ;
>> .
>>
>> This gives me a "malformed SHACL expression", so there are definitely
>> problems.
>>
>> My real question is, how does one duplicate this pattern in SHACL?:
>>
>> WHERE {
>>  ?property rdfs:subPropertyOf*
>>  .
>>  $this ?property ?result .
>> }
>>
>>
>>
>>
>> Steve
>>
>>
>>
>> --
>> 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 topbraid-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/topbraid-users/CAGUep87nmSVo5eziHPh6ExbPD1%3DD%3DWrfTNOwNtK0PBww21%3DpgA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/topbraid-users/CAGUep87nmSVo5eziHPh6ExbPD1%3DD%3DWrfTNOwNtK0PBww21%3DpgA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>>
>> --
>> You received this message b

Re: [topbraid-users] Trying to play nice with SHACL

[Steve Ray]

I agree with you. Is there no way to have "variable" predicates in native
SHACL? Or is my only option here to use the embedded SPARQL?

Steve




On Tue, Nov 24, 2020 at 12:51 PM Irene Polikoff 
wrote:

> There is no path in your example that could get from ?this to ?prop. A
> path specifies predicates. You do not have predicates to specify - you are
> finding out your predicates in the first WHERE statement. This is why you
> need to have 2 statements in the WHERE clause and can’t boil them down to a
> path expression in a single statement.
>
> On Nov 24, 2020, at 12:39 PM, Steve Ray  wrote:
>
> I'm trying to get comfortable with using SHACL code and wean myself from
> embedded SPARQL. However, I'm having some trouble mapping certain common
> SPARQL patterns into the SHACL counterpart. Specifically, here's an
> example. I'm trying to find all the values of any property that is a
> subPropertyOf a parent property (c223:hasProperty).
> The SPARQL should (I think) be something like this:
>
> c223:PropertiesShape
>   rdf:type sh:PropertyShape ;
>   sh:path c223:hasProperty ;
>   sh:name "PropertiesShape" ;
>   sh:values [
>   sh:sparql [
>   sh:prefixes <http://www.w3.org/2000/01/rdf-schema> ;
>   sh:select """SELECT DISTINCT ?prop
>  WHERE {
>  ?property rdfs:subPropertyOf*
> c223:hasProperty .
>  $this ?property ?prop .
> }""" ;
> ] ;
> ] ;
> .
>
> I know the following is wrong, but not sure what sh: calls I should be
> using:
>
> c223:PropertiesShape
>   rdf:type sh:PropertyShape ;
>   sh:path c223:hasProperty ;
>   sh:name "PropertiesShape" ;
>   sh:values [
>   sh:distinct [
>   sh:nodes [
>   sh:path (
>   [
> sh:zeroOrMorePath rdfs:subPropertyOf ;
>   ]
>   c223:hasProperty
> ) ;
> ] ;
> ] ;
> ] ;
> .
>
> This gives me a "malformed SHACL expression", so there are definitely
> problems.
>
> My real question is, how does one duplicate this pattern in SHACL?:
>
> WHERE {
>  ?property rdfs:subPropertyOf*
>  .
>  $this ?property ?result .
> }
>
>
>
>
> Steve
>
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CAGUep87nmSVo5eziHPh6ExbPD1%3DD%3DWrfTNOwNtK0PBww21%3DpgA%40mail.gmail.com
> <https://groups.google.com/d/msgid/topbraid-users/CAGUep87nmSVo5eziHPh6ExbPD1%3DD%3DWrfTNOwNtK0PBww21%3DpgA%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/11EA64E3-07D1-4DAF-A609-21C84A739254%40topquadrant.com
> <https://groups.google.com/d/msgid/topbraid-users/11EA64E3-07D1-4DAF-A609-21C84A739254%40topquadrant.com?utm_medium=email_source=footer>
> .
>

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep87Hq%3DPv7rCT0f3aQPU%2BzYo27dA1eodYyGe9ZOoh4D9opA%40mail.gmail.com.

[topbraid-users] Trying to play nice with SHACL

[Steve Ray]

I'm trying to get comfortable with using SHACL code and wean myself from
embedded SPARQL. However, I'm having some trouble mapping certain common
SPARQL patterns into the SHACL counterpart. Specifically, here's an
example. I'm trying to find all the values of any property that is a
subPropertyOf a parent property (c223:hasProperty).
The SPARQL should (I think) be something like this:

c223:PropertiesShape
  rdf:type sh:PropertyShape ;
  sh:path c223:hasProperty ;
  sh:name "PropertiesShape" ;
  sh:values [
  sh:sparql [
  sh:prefixes  ;
  sh:select """SELECT DISTINCT ?prop
 WHERE {
 ?property rdfs:subPropertyOf* c223:hasProperty
.
 $this ?property ?prop .
}""" ;
] ;
] ;
.

I know the following is wrong, but not sure what sh: calls I should be
using:

c223:PropertiesShape
  rdf:type sh:PropertyShape ;
  sh:path c223:hasProperty ;
  sh:name "PropertiesShape" ;
  sh:values [
  sh:distinct [
  sh:nodes [
  sh:path (
  [
sh:zeroOrMorePath rdfs:subPropertyOf ;
  ]
  c223:hasProperty
) ;
] ;
] ;
] ;
.

This gives me a "malformed SHACL expression", so there are definitely
problems.

My real question is, how does one duplicate this pattern in SHACL?:

WHERE {
 ?property rdfs:subPropertyOf* 
.
 $this ?property ?result .
}




Steve

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep87nmSVo5eziHPh6ExbPD1%3DD%3DWrfTNOwNtK0PBww21%3DpgA%40mail.gmail.com.

Re: [topbraid-users] Feature request for EDG spreadsheet imports

[Steve Ray]

How about matching for the full URI? That would still support my use case.

Steve




On Wed, Nov 18, 2020 at 4:42 PM Holger Knublauch 
wrote:

> Hi Steve,
>
> I don't see an efficient algorithm that could do such matches. Finding all
> resources with a given local name would require walking through all
> subjects in the graph. And we would have to do this for each row in the
> spreadsheet. You'll end up with combinatorial explosion and many unhappy
> users if we offer this feature. However, directly matching certain values
> would be much easier, because that's a simple ?s ?p $value look-up.
>
> Holger
>
>
> On 11/19/2020 10:36 AM, Steve Ray wrote:
>
> I started to try importing some classes and data from a spreadsheet
> recently, and used Irene's very helpful walk-through from the October User
> Group meeting (
> https://www.topquadrant.com/project/topquadrant-user-group-meeting/).
> Things went fairly well after I fixed up the header rows, except for one
> thing:
>
> My spreadsheet contained the first column which corresponded to new
> instance URIs, which I was able to import (Class A). However, another
> column contained the localnames for instances of another class (Class B). I
> was able to tell the import pattern that it was a relation, but the wizard
> only offers matching by the properties of the class (Class B), such as the
> label, etc., but not by the localname. I was forced to temporarily create a
> throwaway property that contained the localname, for each of the Class B
> instances, so that the wizard could match on that property.
>
> It would sure be helpful if the localname was also offered as a field to
> match on. What do you think?
>
> Steve
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CAGUep84XyuGQGSzHs%3DhTAtB-At%3D%2B8T9de59uaGr9cE8PP9WB5g%40mail.gmail.com
> <https://groups.google.com/d/msgid/topbraid-users/CAGUep84XyuGQGSzHs%3DhTAtB-At%3D%2B8T9de59uaGr9cE8PP9WB5g%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/c3f08277-8724-a9cd-d867-ad390170c7d5%40topquadrant.com
> <https://groups.google.com/d/msgid/topbraid-users/c3f08277-8724-a9cd-d867-ad390170c7d5%40topquadrant.com?utm_medium=email_source=footer>
> .
>

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep84a7pObhSrRY-49UrMF4TMEsNEdwYx6rUTrrO4cewCfNQ%40mail.gmail.com.

[topbraid-users] Feature request for EDG spreadsheet imports

[Steve Ray]

I started to try importing some classes and data from a spreadsheet
recently, and used Irene's very helpful walk-through from the October User
Group meeting (
https://www.topquadrant.com/project/topquadrant-user-group-meeting/).
Things went fairly well after I fixed up the header rows, except for one
thing:

My spreadsheet contained the first column which corresponded to new
instance URIs, which I was able to import (Class A). However, another
column contained the localnames for instances of another class (Class B). I
was able to tell the import pattern that it was a relation, but the wizard
only offers matching by the properties of the class (Class B), such as the
label, etc., but not by the localname. I was forced to temporarily create a
throwaway property that contained the localname, for each of the Class B
instances, so that the wizard could match on that property.

It would sure be helpful if the localname was also offered as a field to
match on. What do you think?

Steve

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep84XyuGQGSzHs%3DhTAtB-At%3D%2B8T9de59uaGr9cE8PP9WB5g%40mail.gmail.com.

Re: [topbraid-users] Recursion using a sh:PropertyShape with embedded SPARQL

[Steve Ray]

Thanks Holger! That worked! I had to rebalance some ]'s but then it
performed perfectly!

I'm still getting used to the syntax of the sh: operators. If I could
trouble you for one more piece of advice.

I realized that there are some instances of qudt:PhysicalConstant that also
point to instances of qudt:QuantityKind, so I want to filter out anything
that is not an instance of qudt:Unit. After exploring the documentation at
https://w3c.github.io/shacl/shacl-af, I thought sh:filterShape might do the
trick. The amended code is shown below. It isn't working - in fact it is
weirdly now returning just the value of $this, i.e. the subject
QuantityKind. Am I using sh:filterShape correctly? I'm trying to say "Look
to see if anything is pointing to you via the hasQuantityKind property, and
filter those down to just instances of qudt:Unit. If you find some, return
those. If not, follow the skos:broader relation and try again with that
QuantityKind."

Here is the functioning code:

qudt:QuantityKind-appropriateUnit

  rdf:type sh:NodeShape ;

  sh:property [

  rdf:type sh:PropertyShape ;

  sh:path qudt:appropriateUnit ;

  sh:group qudt:AppropriateUnitsGroup ;

  sh:order "15"^^xsd:decimal ;

  sh:values [

  sh:distinct [

  sh:else [

  sh:path qudt:appropriateUnit ;

  sh:nodes [

  sh:path skos:broader ;

] ;

] ;

  sh:if [

  sh:exists [

  sh:path [

  sh:inversePath qudt:hasQuantityKind ;

] ;

  sh:filterShape qudt:Unit ;

] ;

] ;

  sh:then [

  sh:path [

  sh:inversePath qudt:hasQuantityKind ;

] ;

  sh:filterShape qudt:Unit ;

] ;

] ;

] ;

] ;

  sh:targetClass qudt:QuantityKind ;

.

I realized that I need to
Steve




On Wed, Oct 28, 2020 at 7:39 PM Holger Knublauch 
wrote:

>
> On 10/29/2020 11:51 AM, Steve Ray wrote:
>
> Hi,
> I am trying to recreate a recursive magic property, using a SHACL property
> shape. However, I suspect that the reason the recursion is not working is
> because the property identified in the sh:path statement isn't really a
> function in the same sense as a magic property is a function.
>
> My shape code is as follows:
>
> qudt:QuantityKind-appropriateUnit
>
>   rdf:type sh:NodeShape ;
>
>   sh:property [
>
>   rdf:type sh:PropertyShape ;
>
>   sh:path qudt:dappropriateUnit ;
>
>   sh:values [
>
>   sh:prefixes <http://qudt.org/2.1/schema/shacl/overlay/qudt> ;
>
>   sh:select """SELECT DISTINCT ?unit
>
> WHERE {
>
> {
>
> ?unit qudt:hasQuantityKind $this .
>
> }
>
> UNION
>
> {
>
> NOT EXISTS {
>
> ?unit qudt:hasQuantityKind $this .
>
> } .
>
> $this skos:broader ?parent1 .
>
> ?parent1 qudt:dappropriateUnit ?unit .
>
> } .
>
> }  """ ;
>
> ] ;
>
> ] ;
>
>   sh:targetClass qudt:QuantityKind ;
>
> .
>
> The non-recursive part works (the first clause of the union). But the
> second union clause does not work. Is there a way to make the
> qudt:dappropriateUnit property know that there's this associated sh:values
> clause?
>
> As you have found out, SPARQL itself doesn't "see" the additional inferred
> triples. SHACL node expressions do, if you can reformulate this query,
> using sh:path.
>
> In TopBraid there is a "native" way of querying inferred values within
> SPARQL too:
>
> Try
>
> ( ?parent1 qudt:dappropriateUnit ) tosh:values ?unit .
>
> which is a magic property that will look at both inferred and asserted
> values at query time. Make sure to avoid infinite loops though, i.e. no
> cycles in the graph.
>
> As this would only work within TopBraid, a more "standard" approach would
> be to use node expressions. Something like
>
> sh:values [
> sh:distinct [
> sh:if [
> sh:exists [
> sh:path [ sh:inversePath qudt:hasQuantityKind ]
>
> ]
> ] ;
> sh:then [
> sh:path [ sh:inversePath qudt:hasQuantityKind ]
> ]
> ] ;
> sh:else [
> sh:path qudt:dappropriateUnit ;
> sh:nodes [
> sh:path skos:broader ;
> ]
> ]
> ]
> ]
>
> which due to the geekiness and my lack of example data I haven't tested.
>

[topbraid-users] Recursion using a sh:PropertyShape with embedded SPARQL

[Steve Ray]

Hi,
I am trying to recreate a recursive magic property, using a SHACL property
shape. However, I suspect that the reason the recursion is not working is
because the property identified in the sh:path statement isn't really a
function in the same sense as a magic property is a function.

My shape code is as follows:

qudt:QuantityKind-appropriateUnit

  rdf:type sh:NodeShape ;

  sh:property [

  rdf:type sh:PropertyShape ;

  sh:path qudt:dappropriateUnit ;

  sh:values [

  sh:prefixes  ;

  sh:select """SELECT DISTINCT ?unit

WHERE {

{

?unit qudt:hasQuantityKind $this .

}

UNION

{

NOT EXISTS {

?unit qudt:hasQuantityKind $this .

} .

$this skos:broader ?parent1 .

?parent1 qudt:dappropriateUnit ?unit .

} .

}  """ ;

] ;

] ;

  sh:targetClass qudt:QuantityKind ;

.

The non-recursive part works (the first clause of the union). But the
second union clause does not work. Is there a way to make the
qudt:dappropriateUnit property know that there's this associated sh:values
clause?

Steve

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep86_5U4TAKX-Jjb5erVdzZZZ9Xrfvv5%3DOzNJi-69gCjdzg%40mail.gmail.com.

Re: [topbraid-users] Use of magic properties in EDG

[Steve Ray]

Thanks, Holger. My magic property is recursive, and yields multiple
values on the right side, so I will see if I can get the (recursive)
SPARQL query wrapped into a sh:values clause.


Steve



On Mon, Oct 19, 2020 at 3:44 PM Holger Knublauch  wrote:
>
>
> On 10/20/2020 2:27 AM, Steve Ray wrote:
> > Hi, I defined a magic property to infer values for a class relation,
> > which works fine in SPARQL queries. I was wondering if there is a way
> > for these inferred properties to be displayed in EDG without
> > explicitly asserting them with, say, sh:value? I'm trying not to
> > clutter up our vocabulary with things that can be inferred.
> >
> > How do spin Magic Properties migrate over to the EDG world?
>
> Older versions of our forms did show magic properties automatically but
> this is no longer the case.
>
> I had added sh:values rules to SHACL-AF as a substitute for magic
> properties in mind. Magic properties are a SPARQL-specific feature that
> offers a bit too much flexibility while sh:values rules cover the common
> use cases of computing values for a given focus node.
>
> Note that sh:values rules can even be chained together (using sh:path
> expressions), and work on the forms, GraphQL and the (new) Active Data
> Shapes scripts. And if the expressiveness of the built-in node
> expressions isn't sufficient, you can literally wrap the SPARQL query
> from your magic property as in
>
>  https://w3c.github.io/shacl/shacl-af/#select
>
> Note that magic properties can accept multiple "arguments" and compute
> multiple "results" (on both left and right hand side) while sh:values
> rules always just take one argument and produce one result variable.
> This variable may have multiple rows though.
>
> Holger
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/topbraid-users/e9a06553-acab-9f71-3023-e8c610e51201%40topquadrant.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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep87dgddZuQCccp6f9tkvzusAbsu-5dX%3DD0OSOaxY72NQ7Q%40mail.gmail.com.

[topbraid-users] Use of magic properties in EDG

[Steve Ray]

Hi, I defined a magic property to infer values for a class relation,
which works fine in SPARQL queries. I was wondering if there is a way
for these inferred properties to be displayed in EDG without
explicitly asserting them with, say, sh:value? I'm trying not to
clutter up our vocabulary with things that can be inferred.

How do spin Magic Properties migrate over to the EDG world?


Steve

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep85-MvHRSgd9_ttaCemZxxgr1Pq8KgRO_O13FpgjdTNUsw%40mail.gmail.com.

Re: [topbraid-users] Best practices guidance

[Steve Ray]

Understood. I'll try to remain vigilant about those little widgets.
This was a subtle one. It really had me questioning whether I
understood SHACL at all!

Steve



On Tue, Oct 13, 2020 at 3:16 PM Holger Knublauch  wrote:
>
> Hi Steve,
>
> the UI needs to decide what kind of input widget it presents based on
> what it can find out from the ontology. The case of sh:hasValue is
> difficult, because it would need to make some assumptions about what
> type of value is most likely needed. In your case this is extra
> difficult because the property shape doesn't specify sh:datatype or
> sh:class, and even worse, uses a property path. Due to lack of other
> info it thus "guesses" you may want to use an xsd:string and presents
> you with a string input field.
>
> Some things are better edited in source code, and I recommend taking a
> look at the source code from time to time. The EDG web UI allows
> arranging the source code and form panels side by side, making it easier
> to spot such mistakes.
>
> Holger
>
>
> On 10/14/2020 5:52 AM, Steve Ray wrote:
> > Irene,
> > Thanks for the feedback. I was working on a "double-hop" property
> > shape as part of this exercise, and stumbled on what I would
> > characterize as a UI bug in TBC. Note in the screenshot that when I
> > chose "Add Empty Row" when setting a value for sh:hasValue, the
> > datatype shows up as string.
> > Autocompletion works as expected (see second screenshot)
> > But here's the source code view (see third screenshot). I lost a
> > couple of hours wondering why the validation was failing until Ralph
> > helpfully pointed out the quotation marks in the source code, which of
> > course should not be there.
> >
> >
> >
> > Steve
> >
> >
> > On Mon, Oct 12, 2020 at 3:02 PM Irene Polikoff  
> > wrote:
> >> I am pretty sure this was a question about the most appropriate SHACL 
> >> modeling pattern as opposed to OWL vs SHACL.
> >>
> >> Regarding reasoning, TopBraid users typically use SHACL rules for 
> >> reasoning. SWRL is pretty obsolete. It will never be a standard and is 
> >> mainly supported by Protege.
> >>
> >> I was also assuming that PowerMeasurementDevice (if such class is created) 
> >> could be a subclass of a MeasurementDevice and instances would be the 
> >> actual devices - may be from different manufacturers, etc. Of course, the 
> >> decision on where to stop with classes and subclasses and start using 
> >> instances is also situational - it depends.
> >>
> >> On Oct 12, 2020, at 3:16 PM, Michael DeBellis  
> >> wrote:
> >>
> >>
> >>>   I'm looking for guidance on best practices for modeling the
> >>> following kind of pattern:
> >>> A PowerMeasurementDevice takes measurements of Power.
> >>
> >> In my opinion, you haven't said enough about your problem to really give a 
> >> good answer to the question. You can model this either with OWL or SHACL. 
> >> Actually, you will probably use OWL either way just to model that a   
> >> PowerMeasurementDevice is an instance of Device which is probably a 
> >> subclass of something else and that producesMeasurements is an object 
> >> property. So the real question is: is it better to use OWL alone or OWL + 
> >> SHACL?
> >>
> >> The standard answer to these kinds of questions is usually: "use OWL for 
> >> reasoning and SHACL for constraints" but of course things like the domain 
> >> and range of a property (like most things that can be modeled in SHACL) 
> >> can be modeled either way, as an axiom for reasoning or as a constraint on 
> >> data.
> >>
> >> I think what it really comes down to is what kind of data do you have? If 
> >> you are creating say an expert system ontology from scratch and are also 
> >> going to populate it with rules in SWRL or some other language then 
> >> probably OWL alone is better. If you have a lot of existing real world 
> >> data which may contain values of producesMeasurements that don't have the 
> >> appropriate values for their domain and/or range then you probably want to 
> >> use SHACL. Also,  how volatile is your data? If there is constantly new 
> >> data coming in (which may not match the constraint) then SHACL is probably 
> >> better. If it is relatively static and your data will tend to be well 
> >> formed then OWL axioms are probably better.
> >>
> >> As you probably know, the issue with using OW

Re: [topbraid-users] Best practices guidance

[Steve Ray]

Irene,
To answer your question about what my second case would look like,
here's a working example:

test1:PressureMeasuringDevice
  a owl:Class ;
  a sh:NodeShape ;
  rdfs:subClassOf owl:Thing ;
  sh:property [
  a sh:PropertyShape ;
  sh:path test1:producesMeasurements ;
  sh:class qudt:Quantity ;
  sh:name "produces measurements" ;
] ;
  sh:property [
  a sh:PropertyShape ;
  sh:path (
  test1:producesMeasurements
  qudt:unit
  qudt:hasQuantityKind
) ;
  sh:hasValue <http://qudt.org/vocab/quantitykind/ForcePerArea> ;
  sh:name "produces measurements" ;
] ;
.

Note that this does not require the definition of a constrained class
PowerMeasurement. Instead, it just says "I expect an instance of the
generalized qudt:Quantity class, but it had better have a unit with a
quantitykind of ForcePerArea".

So, the advantage of this method is there are fewer subClasses of my
Measurement class that I would have to define. The cost is more
complex property shapes.

I'm quite interested in your opinion of this.


Steve


On Mon, Oct 12, 2020 at 12:04 PM Irene Polikoff  wrote:
>
> I do not understand the difference between two options you are outlining. In 
> the second case, how would the constraint look like?
>
> The bigger question that would ultimately determine the answer is “what you 
> would like to accomplish by producing this model and what do you expect to 
> see in typical data that you will use with it?”. In other words, what do you 
> want it to do e.g., what constraint violations would you like it to produce 
> when validating what kind of data, what inferences would you like it to 
> create if any?
>
> There are few general best practices that can be stated in abstract, such as:
>
> Do not use inverse properties; instead, use shapes with inverse paths
> When deciding what direction to create a property in, go from “many” to “one”
>
>
> But for most guidance, the data and goals need to be understood. There are 
> many different options and alternatives with SHACL.  Even with the ones above 
> it is not “100% must do", ultimately, it all depends.
>
> On Oct 12, 2020, at 2:38 PM, Steve Ray  wrote:
>
> This question is directed at anyone in this group who is fluent in
> SHACL. I'm looking for guidance on best practices for modeling the
> following kind of pattern:
>
> A PowerMeasurementDevice takes measurements of Power.
>
> Is it better practice to put a SHACL constraint on the instances of a
> class called PowerMeasurement (that they should be measurements of
> Power), where:
>
> PowerMeasurementDevice producesMeasurements PowerMeasurement .
>
>
> or, should I just define a property shape for PowerMeasurementDevice
> such that the property producesMeasurements has the appropriate
> constraints? In this case, I don't need to create a special class
> called PowerMeasurement.
>
> Any thoughts one way or the other? I'm leaning toward the explicit
> definition of a PowerMeasurement class, but it's more intuition than
> principle.
>
>
> Steve
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/topbraid-users/CAGUep87ZvBUe0urm5V6rxFPJOVpYCzG3Aa0qz7DxFBH-9TR9Wg%40mail.gmail.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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/topbraid-users/E7D12854-E0D7-4342-AB1C-989E1CD1D12A%40topquadrant.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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep85%2B0qGh7WHakFjq2Y0hRfnWKMOBMUG91MaYOuOCJFTB6A%40mail.gmail.com.

Re: [topbraid-users] Best practices guidance

[Steve Ray]

Yes, sorry, I was indeed asking about SHACL modeling patterns.  I will
think some more so that I can distill my confusion into something more
clear, and perhaps gain insight along the way.

Steve



On Mon, Oct 12, 2020 at 3:02 PM Irene Polikoff  wrote:
>
> I am pretty sure this was a question about the most appropriate SHACL 
> modeling pattern as opposed to OWL vs SHACL.
>
> Regarding reasoning, TopBraid users typically use SHACL rules for reasoning. 
> SWRL is pretty obsolete. It will never be a standard and is mainly supported 
> by Protege.
>
> I was also assuming that PowerMeasurementDevice (if such class is created) 
> could be a subclass of a MeasurementDevice and instances would be the actual 
> devices - may be from different manufacturers, etc. Of course, the decision 
> on where to stop with classes and subclasses and start using instances is 
> also situational - it depends.
>
> On Oct 12, 2020, at 3:16 PM, Michael DeBellis  wrote:
>
>
>>  I'm looking for guidance on best practices for modeling the
>> following kind of pattern:
>> A PowerMeasurementDevice takes measurements of Power.
>
>
> In my opinion, you haven't said enough about your problem to really give a 
> good answer to the question. You can model this either with OWL or SHACL. 
> Actually, you will probably use OWL either way just to model that a   
> PowerMeasurementDevice is an instance of Device which is probably a subclass 
> of something else and that producesMeasurements is an object property. So the 
> real question is: is it better to use OWL alone or OWL + SHACL?
>
> The standard answer to these kinds of questions is usually: "use OWL for 
> reasoning and SHACL for constraints" but of course things like the domain and 
> range of a property (like most things that can be modeled in SHACL) can be 
> modeled either way, as an axiom for reasoning or as a constraint on data.
>
> I think what it really comes down to is what kind of data do you have? If you 
> are creating say an expert system ontology from scratch and are also going to 
> populate it with rules in SWRL or some other language then probably OWL alone 
> is better. If you have a lot of existing real world data which may contain 
> values of producesMeasurements that don't have the appropriate values for 
> their domain and/or range then you probably want to use SHACL. Also,  how 
> volatile is your data? If there is constantly new data coming in (which may 
> not match the constraint) then SHACL is probably better. If it is relatively 
> static and your data will tend to be well formed then OWL axioms are probably 
> better.
>
> As you probably know, the issue with using OWL axioms is the first time you 
> encounter an Individual that doesn't have the proper domain or range then 
> your entire ontology is inconsistent which means it can't be used for any 
> reasoning until the bad data is fixed or removed. With SHACL you just get a 
> report (or some other user defined action) about the bad data but it doesn't 
> make your entire model inconsistent.
>
> Michael
> michaeldebellis.com
>
>
> On Mon, Oct 12, 2020 at 11:39 AM Steve Ray  wrote:
>>
>> This question is directed at anyone in this group who is fluent in
>> SHACL. I'm looking for guidance on best practices for modeling the
>> following kind of pattern:
>>
>> A PowerMeasurementDevice takes measurements of Power.
>>
>> Is it better practice to put a SHACL constraint on the instances of a
>> class called PowerMeasurement (that they should be measurements of
>> Power), where:
>>
>> PowerMeasurementDevice producesMeasurements PowerMeasurement .
>>
>>
>> or, should I just define a property shape for PowerMeasurementDevice
>> such that the property producesMeasurements has the appropriate
>> constraints? In this case, I don't need to create a special class
>> called PowerMeasurement.
>>
>> Any thoughts one way or the other? I'm leaning toward the explicit
>> definition of a PowerMeasurement class, but it's more intuition than
>> principle.
>>
>>
>> Steve
>>
>> --
>> 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 topbraid-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/topbraid-users/CAGUep87ZvBUe0urm5V6rxFPJOVpYCzG3Aa0qz7DxFBH-9TR9Wg%40mail.gmail.com.
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "TopBraid Suite Users" group.
> To unsubscr

[topbraid-users] Best practices guidance

[Steve Ray]

This question is directed at anyone in this group who is fluent in
SHACL. I'm looking for guidance on best practices for modeling the
following kind of pattern:

A PowerMeasurementDevice takes measurements of Power.

Is it better practice to put a SHACL constraint on the instances of a
class called PowerMeasurement (that they should be measurements of
Power), where:

PowerMeasurementDevice producesMeasurements PowerMeasurement .


or, should I just define a property shape for PowerMeasurementDevice
such that the property producesMeasurements has the appropriate
constraints? In this case, I don't need to create a special class
called PowerMeasurement.

Any thoughts one way or the other? I'm leaning toward the explicit
definition of a PowerMeasurement class, but it's more intuition than
principle.


Steve

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep87ZvBUe0urm5V6rxFPJOVpYCzG3Aa0qz7DxFBH-9TR9Wg%40mail.gmail.com.

Re: [topbraid-users] Fighting with EDG

[Steve Ray]

Thanks. Yes, the merged view was throwing me off. I hadn't fully
appreciated the implications of leaving that on.

Steve




On Wed, Sep 16, 2020 at 5:38 PM Irene Polikoff 
wrote:

> This is true throughout - if you do not see a property displayed on a
> form, see if "Also show properties that have no values”  is checked. If you
> only see a handful of properties on a form and they all have some values,
> chances are this setting is off and the form only shows populated
> properties.
>
> This is the case for ontologies, data graphs and/or anything else.
>
> If you do not see a property displayed on a form and you know that it has
> a value e.g., you looked at the source code and you see value there, then
> there are two possible explanations:
>
> 1. No shape have been defined for a property - the form will only show
> properties for which a shape exist
> 2. A resource is a member of more than one class (or have multiple views
> defined via node shapes) and you are currently looking at a view that does
> not include this property. Of course, if you are using “Merged View”, then
> this can’t be the case.
>
> On Sep 16, 2020, at 8:28 PM, Holger Knublauch 
> wrote:
>
> In the upper right corner of that form you see the Settings (cog) button.
> Probably you have Merged View on, which you could deactivate. In any case,
> there is also a * option "Also show properties that have no values" which
> should make these missing fields visible.
>
> Holger
>
>
> On 17/09/2020 10:19, Steve Ray wrote:
>
> Thanks for the quick response, Holger. I tried going to the Ontology
> graph, clicked the little House icon (that's the Home button, right?), but
> the "Merged View" pull-down shows a No-Entry icon when I hover over it.
> 
>
> You did mean the Ontology graph and not the Data Graph, correct?
>
> Steve
>
>
>
>
> On Wed, Sep 16, 2020 at 5:09 PM Holger Knublauch 
> wrote:
>
>> Hi Steve,
>>
>> the Data Graph collection type is designed for editing arbitrary
>> instances, yet you first need to tell the system which instances you want
>> to allow the users to create. To do that, go to your Ontology's "Home"
>> resource and switch the form from Metadata to GraphQL Schema. There you can
>> select the *public classes* - add all classes that you want to allow
>> editing for. It's sufficient to declare the superclasses there if you have
>> subclasses too.
>>
>> FWIW this is mentioned in the page where you create new Data Graphs.
>> Obviously this wasn't clear enough so do you have suggestions on how to
>> make it clearer?
>>
>> 
>>
>> HTH
>> Holger
>>
>>
>> On 17/09/2020 09:57, Steve Ray wrote:
>>
>> Hi,
>> I'm ramping up on using SHACL for some new modeling I'm doing, and
>> decided to try it using EDG (6.4.0). I defined a simple schema, and then
>> went to create a data graph that includes that schema. Try as I might, I
>> could not convince EDG to let me press the "New" button in the classes and
>> instances Layout, to make some instances. It is constantly greyed out.
>> 
>>
>> In the end, I bludgeoned it into having instances by defining them in
>> Visual Studio Code, and importing the file, but obviously that is not a
>> good way to proceed. What am I doing wrong?
>>
>> One more piece of information: The "New" button is not greyed out when I
>> am in the ontology graph, but then it warns me that if I create instances
>> there, the properties will be read-only.
>>
>> I'm attaching the two test files in case that helps. They are short.
>>
>> Steve
>>
>>
>> --
>> 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 topbraid-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/topbraid-users/CAGUep85WKJ%2B5CrFT0dmEnQMSTxrMhVud9CebzGVAJRXApLjrHQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/topbraid-users/CAGUep85WKJ%2B5CrFT0dmEnQMSTxrMhVud9CebzGVAJRXApLjrHQ%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>> --
>> 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 topbraid-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/t

[topbraid-users] Fighting with EDG

[Steve Ray]

Hi,
I'm ramping up on using SHACL for some new modeling I'm doing, and decided
to try it using EDG (6.4.0). I defined a simple schema, and then went to
create a data graph that includes that schema. Try as I might, I could not
convince EDG to let me press the "New" button in the classes and instances
Layout, to make some instances. It is constantly greyed out.
[image: image.png]

In the end, I bludgeoned it into having instances by defining them in
Visual Studio Code, and importing the file, but obviously that is not a
good way to proceed. What am I doing wrong?

One more piece of information: The "New" button is not greyed out when I am
in the ontology graph, but then it warns me that if I create instances
there, the properties will be read-only.

I'm attaching the two test files in case that helps. They are short.

Steve

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep85WKJ%2B5CrFT0dmEnQMSTxrMhVud9CebzGVAJRXApLjrHQ%40mail.gmail.com.


shacl_Room2_temperature_measurement.ttl
Description: Binary data


room_2_measurement_data.ttl
Description: Binary data

[topbraid-users] API interfaces to EDG 6.4

[Steve Ray]

I'm enjoying exploring the API interfaces, specifically the SPARQL
endpoint, and the SPARQL Library links. However, invoking either one gets
interrupted by the Login screen before proceeding to executing the call.
>From a browser, this can be handled. But what about from a program, or
using curl in a terminal window? Is there some way to pass EDG credentials
as part of these API calls?

Steve

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep87rTWCC5NumRxD2tsym9GapskFox3h1MkUsBbFfRK5f9Q%40mail.gmail.com.

Re: [topbraid-users] Q: QUDT - How to model Differential Pressure

[Steve Ray]

Tim,
I'd say the best way is to submit a new quantity kind instance for the QUDT
vocabulary. You could call it quantitykind:DifferentialPressure (although
we just finished refining our unit naming rules here
,
and we may revisit our quantity kind naming rules. If so, we might suggest
quantitykind:Pressure_Differential as the qname). Regardless, the quantity
kind submission guidelines are here
,
where you can see what we require. The logical thing would then be to
include a skos:broader relation pointing to quantitykind:Pressure.
Here are the current quantity kinds that have a skos:broader of
quantitykind:Pressure:

[image: image.png]




Steve
qudt.org




On Mon, Jul 6, 2020 at 1:50 PM Tim Smith  wrote:

> Hi,
>
> I have a need to say that a value represents "Differential Pressure" -
> e.g. the difference between two pressures as measured in a system.  I see
> that there is a quantitykind:Pressure instance.  Is there a specific way to
> attach a modifier to indicate that the value, while a Pressure, is derived
> as the difference between two pressures?  I suspect I can add something
> like it via edg:PhysicalPropertyKind or some other extension point but I
> wanted to check and see if this situation has already been considered.
>
> Thanks in advance for your input!
>
> Tim
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CAF0WbnLNLzktiZWn9Wg4WTB-OJeErgEkmPGMk1WFQc-%3DCkTyGg%40mail.gmail.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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep86%2BZpc_fGrzBDwrmtA2ahn4bTXfu--EHyr8EScviuhqQQ%40mail.gmail.com.

Re: [topbraid-users] Feedback on EDG 6.4 Beta

[Steve Ray]

Examples include:
1. Typing something in "Search the EDG" gives results in a new tab.
2. Clicking the first result opens the "Data Graph" view for that instance,
in a new tab.
3. Clicking the "hamburger icon" and choosing a different collection, opens
in a new tab.

Steve




On Fri, Jul 3, 2020 at 2:46 PM Irene Polikoff  wrote:

> What actions do you mean, Steve?
>
> On Jul 3, 2020, at 3:18 PM, Steve Ray  wrote:
>
> It would be nice if there were an option in EDG so that actions do not
> open in new tabs. After a session with EDG, my browser has a glut of tabs
> open that I have to delete.
>
> On those occasions when I DO want a new tab, I generally just hold the
> Command button while clicking.
>
>
> Steve
>
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CAGUep85j65Z-nXM8c_03vooOUv9REqZb7XJJxbJ1FjSD-_RhwA%40mail.gmail.com
> <https://groups.google.com/d/msgid/topbraid-users/CAGUep85j65Z-nXM8c_03vooOUv9REqZb7XJJxbJ1FjSD-_RhwA%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/1CA4D506-6BB3-449F-85F6-C69D7F80579A%40topquadrant.com
> <https://groups.google.com/d/msgid/topbraid-users/1CA4D506-6BB3-449F-85F6-C69D7F80579A%40topquadrant.com?utm_medium=email_source=footer>
> .
>

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep87iOi%3Dc_kZ5tx1VKmhA7CCFBMX-QagGaZKtXwmMCH89Nw%40mail.gmail.com.

[topbraid-users] Feedback on EDG 6.4 Beta

[Steve Ray]

It would be nice if there were an option in EDG so that actions do not open
in new tabs. After a session with EDG, my browser has a glut of tabs open
that I have to delete.

On those occasions when I DO want a new tab, I generally just hold the
Command button while clicking.


Steve

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep85j65Z-nXM8c_03vooOUv9REqZb7XJJxbJ1FjSD-_RhwA%40mail.gmail.com.

Re: [topbraid-users] GraphQL query against imported ontology

[Steve Ray]

I would strongly urge you to consider migrating to QUDT version 2.1. Much
has changed since 1.0. For example, all unit instances are now simply
instances of the qudt:Unit class. There is no longer a class named
ElectricUnitClass, mostly because it became impractical to try to manage a
class hierarchy for units that "belong" to multiple overlapping
disciplines/domains. So QUDT 2.1 is much simpler in structure.

I'm available for any guidance requested should you choose to migrate to 2.1
Please check qudt.org for more information, and/or our GitHub site at
https://github.com/qudt/qudt-public-repo

Steve Ray
qudt.org




On Tue, Jun 30, 2020 at 1:10 AM Rob Atkinson <
rob.atkin...@surroundaustralia.com> wrote:

>
> yep fixing the namespaces in the original data files fixes it - but you
> have to perform quite a few gymnastics before everything is lined up :-)
>
>
> On Tuesday, June 30, 2020 at 5:52:08 PM UTC+10 Rob Atkinson wrote:
>
>> hmm units uses:
>> a <http://qudt.org/schema/qudt#ElectricCurrentUnit>
>>
>> but the qudt schema it imports uses:
>> a <http://qudt.org/schema/1.0/qudt#ElectricCurrentUnit>
>>
>> ouch!
>>
>> the other ns was an artefact of a different failed experiment importing
>> QUDT stuff..
>>
>> On Tuesday, June 30, 2020 at 5:31:23 PM UTC+10 Rob Atkinson wrote:
>>
>>>
>>> not sure what ttl to send -  the file is
>>> TopBraid/LinkedModels/unit-v1.0.ttl  and ?I just want to know how to expose
>>> that via GraphQL - or confirm that it cannot be done for some reasone
>>>
>>> If I create an ontology, then execute OWL 2 SHACL then it shows:
>>>
>>> <http://qudt.org/schema/1.0/qudt#Unit>
>>>   a owl:Class ;
>>>   a sh:NodeShape ;
>>>
>>>
>>> but when I include this in my data graph...
>>>
>>>   owl:imports  ;
>>>
>>> then it doesnt show up:
>>>
>>> qudt:Unit
>>>   a owl:Class ;
>>>   qudt:informativeReference
>>>
>>> because somehow its picked up a different namespace
>>>  @prefix qudt: <http://qudt.org/schema/qudt/> .
>>>
>>> now to find out why...
>>> On Tuesday, June 30, 2020 at 5:08:10 PM UTC+10 Holger Knublauch wrote:
>>>
>>>> Hi Rob,
>>>>
>>>> is the Unit class also instance of sh:NodeShape?
>>>>
>>>> Feel free to send me what you have as a TTL file and I can take a look.
>>>>
>>>> Holger
>>>>
>>>>
>>>> On 30/06/2020 17:03, Rob Atkinson wrote:
>>>>
>>>>
>>>> I have tried to make the QUDT units ontology (pre-loaded) accessible
>>>> via GraphQL and failed...
>>>>
>>>> If I include it into a empty data graph I can traverse and inspect all
>>>> the contents...
>>>>
>>>> I can set the search root to be, for example Unit
>>>>
>>>> I then add  statements like this to the graph root object..
>>>>
>>>>   graphql:publicClass qudt:Unit ;
>>>>  teamwork:mainClass qudt:Unit ;
>>>>   teamwork:rootClass qudt:Unit ;
>>>>
>>>> but the Unit class does not show up as an option the the GraphQL schema:
>>>>
>>>> { _rootTypeShapes {
>>>>   rootQueryField
>>>> } }
>>>>
>>>> =>
>>>>
>>>> {
>>>>   "data": {
>>>> "_rootTypeShapes": []
>>>>   }
>>>> }
>>>>
>>>>
>>>> I also tried loading the file into an ontology, running OWL->SHACL then
>>>> defining the graphqL public classes,  and incuding into the data graph.
>>>> Still navigable and not queryable.
>>>>
>>>> even if i wanted to, I  cannot import the file - it complains about
>>>> having classes defined.
>>>>
>>>> And in the search panel the search class is listed, but it doesnt offer
>>>> the class hierarchy and the search box is greyed out.
>>>>
>>>> I also tried building the lucene indices.
>>>>
>>>> What exactly is the requirement for GraphQL to be enabled? - and can
>>>> anyone provide an example recipe that works to allow query for any or all
>>>> of the various models available in EDG by default.
>>>>
>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "

Re: [topbraid-users] “TopBraid Composer” is damaged and can’t be opened. You should move it to the Trash.

[Steve Ray]

Here is the secret sauce. I have to do this every new install:
You may need to strip the extended attributes from the app:

Type:
xattr -cr /path/to/application.app

Steve




On Mon, Mar 9, 2020 at 5:52 PM Irene Polikoff  wrote:

> Please see Q at https://www.topquadrant.com/knowledge-assets/faq/tbc/
>
> On Mar 9, 2020, at 8:37 PM, 'R. U.S.' via TopBraid Suite Users <
> topbraid-users@googlegroups.com> wrote:
>
> I get that error when downloading Topbraid Composer Maestro in my Mac
> (Catalina, 10.15.3). I'm a Topbraid user of years, and never had a problem
> installing the previous versions. Can you guys double-check that the
> current deliverable is viable in Mac?
>
> Thanks in advance
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/98aeccba-6454-4cfe-94c2-0adecfd91d35%40googlegroups.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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/7B7576A8-31B8-4AA6-9EE3-AB821465E6F7%40topquadrant.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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep861tGwRGkS8_P%2BrQRS8n%3DD6h%3DEXPDRtP7PeJPHgca6VPA%40mail.gmail.com.

Re: [topbraid-users] Providing a SPARQL endpoint API

[Steve Ray]

Thanks. The pointers were very helpful, and I now have things running.

Steve




On Tue, Jan 14, 2020 at 1:04 PM Irene Polikoff 
wrote:

> Yes, as Tim indicated, there is a SPARQL Endpoint. You can read about it
> here https://doc.topquadrant.com/6.3/developer-guide/#SPARQL_endpoint
>
> By default, only SELECT is enabled. You can enable updates in the server
> admin console.
>
> Opening a generic SPARQL endpoint to anyone may have some undesirable
> effects since a query could be arbitrarily complex and consume a lot of
> resources. May be not that much of an issue with your data?
>
> With respect to the user ID, EDG supports form-based, basic and no
> authentication. If configured for no authentication, then user id is not
> needed. Otherwise, user id will be required. You can read more here
> https://doc.topquadrant.com/6.3/server-installation/.
>
> On Jan 14, 2020, at 3:44 PM, Tim Smith  wrote:
>
> I don’t know about the current version but older TBC/TBL versions had some
> support for a SPARQL endpoint.  I still use it with TBC 5.1.4.  I believe
> it only supported Select queries which is limiting but it was accessible as
> a service and thus could be called by a program.  I use it for localized
> ETL between SQL DBs and graphs.
>
> With TBC running, you can find the service here:
> http://localhost:8083/tbl/sparql.  It is also available on the 5.1.4
> version of TBL.
>
> On Tue, Jan 14, 2020 at 3:09 PM Taryn Madey 
> wrote:
>
>> Hi Steve. Can you send an email to TopQuadrant support instead? This
>> would be a feature of EDG.
>>
>> On Tue, Jan 14, 2020 at 11:36 AM Steve Ray  wrote:
>>
>>> Does the TopBraid/EDG suite offer an API that allows a program to run an
>>> arbitrary SPARQL SELECT query? I'd like to offer basically the same
>>> capability as the SPARQL endpoint user interface, but via an API.
>>>
>>> Also, I think I know the answer to this, but is it possible to access
>>> the SPARQL endpoint without a user id, or must I publish shared read-only
>>> account credentials if I want the public to be able to run arbitrary SPARQL
>>> SELECT queries on the endpoint? I'd like to make functionality available
>>> kind of like Virtuoso, but for our own QUDT models.
>>>
>>> Steve
>>>
>>>
>>>
>>> --
>>> 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 topbraid-users+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/topbraid-users/CAGUep87Tb-8gV0oFFLgi3hGVpBjREaOHV6X-v9QCufzN5LEmXw%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/topbraid-users/CAGUep87Tb-8gV0oFFLgi3hGVpBjREaOHV6X-v9QCufzN5LEmXw%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>>
>>
>> --
>> Taryn Madey
>> Development Manager
>> TopQuadrant Inc.
>> Raleigh, NC
>>
>>
>> --
>> 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 topbraid-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/topbraid-users/CAF6qMpp%3Di%3DV_fBtKECsp7S6QXFsi3FZR0dmopk%2BL5zxv3dyR7A%40mail.gmail.com
>> <https://groups.google.com/d/msgid/topbraid-users/CAF6qMpp%3Di%3DV_fBtKECsp7S6QXFsi3FZR0dmopk%2BL5zxv3dyR7A%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/CAF0WbnLco_mhcKpKwcRQNL%2Boo8X5MdVrAmT50C%2BGn3PTgJBpnA%40mail.gmail.com
> <https://groups.google.com/d/msgid/topbraid-users/CAF0WbnLco_mhcKpKwcRQNL%2Boo8X5MdVrAmT50C%2BGn3PTgJBpnA%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/E3E7D14A-1EFC-4C

[topbraid-users] Providing a SPARQL endpoint API

[Steve Ray]

Does the TopBraid/EDG suite offer an API that allows a program to run an
arbitrary SPARQL SELECT query? I'd like to offer basically the same
capability as the SPARQL endpoint user interface, but via an API.

Also, I think I know the answer to this, but is it possible to access the
SPARQL endpoint without a user id, or must I publish shared read-only
account credentials if I want the public to be able to run arbitrary SPARQL
SELECT queries on the endpoint? I'd like to make functionality available
kind of like Virtuoso, but for our own QUDT models.

Steve

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep87Tb-8gV0oFFLgi3hGVpBjREaOHV6X-v9QCufzN5LEmXw%40mail.gmail.com.

Re: [topbraid-users] power of owl constraints

[Steve Ray]

Isn't what Michel is asking for provided by including the OWL 2 RL profile
for an ontology?

Steve




On Wed, Nov 6, 2019 at 8:19 AM dprice  wrote:

>
>
> On 6 Nov 2019, at 13:28, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <
> topbraid-users@googlegroups.com> wrote:
>
> In an ISO group we model some relations as instances of classes (to be
> able to add meta-data).
>
> So we have:
> Class “Link”, having a To and From relation to a link element.
>
> Since we cannot reuse symmetry/transitivity/inverse functionality from OWL
> we have to model ourselves.
> So, think:
>
>1. Symmetry: If Rxy -> Ryx
>
>
>
>1. Transitivity: (Rxy AND Ryz ) -> Rxz
>
>
>
>1. Inverse: Rxy -> InverseRyx
>
>
> Would it be feasible to do this kind of constraint modelling in OWL. Or
> need to go for SHACL?
>
>
> What is it you are trying to accomplish? e.g. Do you need inferences based
> on these statements? Are you going to also write your own rules of some
> sort to produce those inferences? etc.
>
> BTW IMO most people would not call these “constraints” in the sense of
> something being invalid wrt them.
>
> Symmetric and Transitive can be just a boolean flag on a Link (or
> subclasses of Link similar to OWL). Inverse is just a relation to another
> Link. This seems simple to model which makes me ask whether there isn’t
> more to the question.
>
> Cheers,
> David
>
>
> Thx Michel
>
>
>
>
> Dr. ir. H.M. (Michel) Böhms
> Senior Data Scientist
>
> T +31888663107
> M +31630381220
> E michel.bo...@tno.nl
> Location
> 
>
>
>  
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use
> it and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
>
>
>
>
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/64e6320449544167867e9887ea6f46c6%40tno.nl
> 
> .
>
>
> UK +44 (0) 7788 561308
> US +1 (336) 283-0808‬
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/661F2697-55BF-496F-84FC-40CF10A2E38C%40topquadrant.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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/CAGUep866da%3DrmnmyJn8GybcygZLU0WmkX8qZm4TvdRum2KyKTw%40mail.gmail.com.

Re: [topbraid-users] qudt2.1 use issue

[Steve Ray]

The uses made of skos are:
skos:prefLabel
skos:altLabel
skos:exactMatch
skos:closeMatch
skos:narrowMatch
skos:definition
skos:member
skos:broader

...but there are a few class definitions that use
rdfs:subClassOf skos:Concept
such as in the definition of reference frames and coordinate systems (as
yet unpublished)

The subclasses are not in the central part of QUDT, but if you want to be
sure over the long term, then you may need to import.


Steve




On Thu, Sep 19, 2019 at 7:16 AM dprice  wrote:

>
>
> On 19 Sep 2019, at 08:36, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <
> topbraid-users@googlegroups.com> wrote:
>
> Related question on imports:
>
> I now do:
>
> <https://w3id.org/def/basicsemantics-owl>
>   a owl:Ontology ;
>   owl:imports <http://www.w3.org/2004/02/skos/core> ;
>
>
> really needed to import skos?
>
>
>
> Depends on what skos it uses. If only annotations (e.g. prefLabel) then
> maybe not. If it uses Concept then probably so.
>
> Cheers,
> David
>
>
>
>
>
>
> Dr. ir. H.M. (Michel) Böhms
> Senior Data Scientist
>
> T +31888663107
> M +31630381220
> E michel.bo...@tno.nl
> Location
> <https://www.google.com/maps/place/TNO+-+Locatie+Delft+-+Stieltjesweg/@52.000788,4.3745183,17z/data=!3m1!4b1!4m5!3m4!1s0x47c5b58c52869997:0x56681566be3b8c88!8m2!3d52.000788!4d4.376707>
>
>
>  <http://www.tno.nl/>
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use
> it and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
>
>
>
>
> *Van:* topbraid-users@googlegroups.com 
> *Namens *dprice
> *Verzonden:* Tuesday, September 17, 2019 12:14 PM
> *Aan:* topbraid-users@googlegroups.com
> *CC:* Steve Ray 
> *Onderwerp:* Re: [topbraid-users] qudt2.1 use issue
>
>
>
>
> On 17 Sep 2019, at 09:53, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <
> topbraid-users@googlegroups.com> wrote:
>
> Thx David for your extensive feedback. I see all your points (esp. from an
> IDE viewpoint). At the same time we see a trend away from data
> copy/import/exchange to sharing via publication ie more decentral
> approaches (for both data and structure). And yes those approaches come
> with issues like uncontrolled change etc. So I guess we always have to find
> a balance.
>
>
> Given how I know you, I assume the “structure” you mention will mostly be
> used in an engineering environment.
>
> FWIW I would not allow “uncontrolled change” to happen on any
> project/programme in the engineering world over which I had any control wrt
> defining its semantics. Data/structure for human interpretation is one
> thing, humans are flexible. However, data/structure for engineering
> applications is a completely different story.
>
>
>
> So, in the end, I will be importing the qudt2.1 stuff. Hoping on some
> feedback soon from Steve to have it all working.
> We now propose the QUDT approach as part of our modelling recommendations
> with CEN TC442 WG4 TG3.
>
> Maybe there is one issue you can advice: it has name spaces that are
> different from the prefix URIs. Often those are the same in other
> ontologies. Eg:
>
>
> This is one common way of managing the versioning of ontologies … version
> numbers in the graph URIs, no version numbers in the class URIs.
>
>
>
> # baseURI: http://qudt.org/2.1/vocab/quantitykind
> # imports: http://qudt.org/2.0/vocab/nidr
> # imports: http://qudt.org/2.1/schema/qudt
> # imports: http://qudt.org/2.1/vocab/dimension
> # imports: http://qudt.org/2.1/vocab/unit
> # imports: http://www.linkedmodel.org/schema/vaem
>
> @prefix dc: <http://purl.org/dc/elements/1.1/> .
> @prefix dct: <http://purl.org/dc/terms/> .
> @prefix mc: <http://www.linkedmodel.org/owl/schema/core#
> <http://www.linkedmodel.org/owl/schema/core>> .
> @prefix owl: <http://www.w3.org/2002/07/owl#
> <http://www.w3.org/2002/07/owl>> .
> @prefix prov: <http://www.w3.org/ns/prov# <http://www.w3.org/ns/prov>> .
> @prefix quantitykind: <http://qudt.org/vocab/quantitykind/> .
>
> I assumed that I in the end have it working for importing:
> http://qudt.org/vocab/quantitykind
>
> right?
> (where server-negotiation will lead to the latest version)
>
>
>
> Depends.  If QUDT is only published in a versioned form or its server only
> supports the versioned form, then you will have to import the specific
>

Re: [topbraid-users] qudt2.1 use issue

[Steve Ray]

Michel,
For your second case, if you just want to refer to unit:M using the prefix,
you don't need to import, you just need to define the unit: prefix in your
workspace. (and of course you can define any prefix you like that maps to
the same URI if you want, although things could get confusing).

Steve




On Thu, Sep 19, 2019 at 7:36 AM 'Bohms, H.M. (Michel)' via TopBraid Suite
Users  wrote:

> Could I say...(following also on our earlier discussion)... everytime I
> want to do more then just seeing a value (like for annotations like skos) I
> have to import so that tbc knows the structure behind ?
>
>
>
> Like in the earlier qudt case:
>
> - if I just want to see the value unit:M ...no import needed (resource
> shows untyped)
>
> - if I want to use say the abbreviation of unit:M I’ll have to import
>
>
>
> Thx Michel
>
>
>
>
>
>
>
>
>
>
>
> Dr. ir. H.M. (Michel) Böhms
> Senior Data Scientist
>
> T +31888663107
> M +31630381220
> E michel.bo...@tno.nl
>
> Location
> <https://www.google.com/maps/place/TNO+-+Locatie+Delft+-+Stieltjesweg/@52.000788,4.3745183,17z/data=!3m1!4b1!4m5!3m4!1s0x47c5b58c52869997:0x56681566be3b8c88!8m2!3d52.000788!4d4.376707>
>
>
>
> <http://www.tno.nl/>
>
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use
> it and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
>
>
>
>
>
>
>
>
>
> *Van:* topbraid-users@googlegroups.com  
> *Namens
> *dprice
> *Verzonden:* Thursday, September 19, 2019 4:16 PM
> *Aan:* topbraid-users@googlegroups.com
> *Onderwerp:* Re: [topbraid-users] qudt2.1 use issue
>
>
>
>
>
>
>
> On 19 Sep 2019, at 08:36, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <
> topbraid-users@googlegroups.com> wrote:
>
>
>
> Related question on imports:
>
>
>
> I now do:
>
>
>
> <https://w3id.org/def/basicsemantics-owl>
>
>   a owl:Ontology ;
>
>   owl:imports <http://www.w3.org/2004/02/skos/core> ;
>
>
>
>
>
> really needed to import skos?
>
>
>
>
>
> Depends on what skos it uses. If only annotations (e.g. prefLabel) then
> maybe not. If it uses Concept then probably so.
>
>
>
> Cheers,
>
> David
>
>
>
>
>
>
>
>
>
>
>
>
>
> Dr. ir. H.M. (Michel) Böhms
> Senior Data Scientist
>
>
> T +31888663107
> M +31630381220
> E michel.bo...@tno.nl
>
> Location
> <https://www.google.com/maps/place/TNO+-+Locatie+Delft+-+Stieltjesweg/@52.000788,4.3745183,17z/data=!3m1!4b1!4m5!3m4!1s0x47c5b58c52869997:0x56681566be3b8c88!8m2!3d52.000788!4d4.376707>
>
>
>
>  <http://www.tno.nl/>
>
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use
> it and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
>
>
>
>
>
>
>
>
>
> *Van:* topbraid-users@googlegroups.com 
> *Namens *dprice
> *Verzonden:* Tuesday, September 17, 2019 12:14 PM
> *Aan:* topbraid-users@googlegroups.com
> *CC:* Steve Ray 
> *Onderwerp:* Re: [topbraid-users] qudt2.1 use issue
>
>
>
>
>
>
>
>
> On 17 Sep 2019, at 09:53, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <
> topbraid-users@googlegroups.com> wrote:
>
>
>
> Thx David for your extensive feedback. I see all your points (esp. from an
> IDE viewpoint). At the same time we see a trend away from data
> copy/import/exchange to sharing via publication ie more decentral
> approaches (for both data and structure). And yes those approaches come
> with issues like uncontrolled change etc. So I guess we always have to find
> a balance.
>
>
>
> Given how I know you, I assume the “structure” you mention will mostly be
> used in an engineering environment.
>
>
>
> FWIW I would not allow “uncontrolled change” to happen on any
> project/programme in the engineering world over which I had any control wrt
> defining its semantics. Data/structure for human interpretation is one
> thing, humans are flexible. However, data/structure for engineering
> applications is a completely different story.
>

Re: [topbraid-users] qudt2.1 use issue

[Steve Ray]

he actual use case.
>
>
>
> WRT qudt: certain that Steve is having/working on a negotiating server
> that gives the latest version when no version is mentioned. Guess just some
> small issues left in the files (like 2.0/2.1 mixup for qudt scheme, some
> names spaces included but not used and no dereferencing of qudt scheme).
> Hopefully soon resolved so that the great stuff of qudt can finally be
> applied.
>
>
>
> Gr Michel
>
>
>
>
>
> Dr. ir. H.M. (Michel) Böhms
> Senior Data Scientist
>
> T +31888663107
> M +31630381220
> E michel.bo...@tno.nl
>
> Location
> <https://www.google.com/maps/place/TNO+-+Locatie+Delft+-+Stieltjesweg/@52.000788,4.3745183,17z/data=!3m1!4b1!4m5!3m4!1s0x47c5b58c52869997:0x56681566be3b8c88!8m2!3d52.000788!4d4.376707>
>
>
>
> [image: cid:image001.gif@01D56D8D.1E046B00] <http://www.tno.nl/>
>
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use
> it and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
>
>
>
>
>
>
>
>
>
> *Van:* topbraid-users@googlegroups.com  
> *Namens
> *dprice
> *Verzonden:* Tuesday, September 17, 2019 12:14 PM
> *Aan:* topbraid-users@googlegroups.com
> *CC:* Steve Ray 
> *Onderwerp:* Re: [topbraid-users] qudt2.1 use issue
>
>
>
>
>
>
>
> On 17 Sep 2019, at 09:53, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <
> topbraid-users@googlegroups.com> wrote:
>
>
>
> Thx David for your extensive feedback. I see all your points (esp. from an
> IDE viewpoint). At the same time we see a trend away from data
> copy/import/exchange to sharing via publication ie more decentral
> approaches (for both data and structure). And yes those approaches come
> with issues like uncontrolled change etc. So I guess we always have to find
> a balance.
>
>
>
> Given how I know you, I assume the “structure” you mention will mostly be
> used in an engineering environment.
>
>
>
> FWIW I would not allow “uncontrolled change” to happen on any
> project/programme in the engineering world over which I had any control wrt
> defining its semantics. Data/structure for human interpretation is one
> thing, humans are flexible. However, data/structure for engineering
> applications is a completely different story.
>
>
>
>
>
> So, in the end, I will be importing the qudt2.1 stuff. Hoping on some
> feedback soon from Steve to have it all working.
>
> We now propose the QUDT approach as part of our modelling recommendations
> with CEN TC442 WG4 TG3.
>
>
>
> Maybe there is one issue you can advice: it has name spaces that are
> different from the prefix URIs. Often those are the same in other
> ontologies. Eg:
>
>
>
> This is one common way of managing the versioning of ontologies … version
> numbers in the graph URIs, no version numbers in the class URIs.
>
>
>
>
>
> # baseURI: http://qudt.org/2.1/vocab/quantitykind
>
> # imports: http://qudt.org/2.0/vocab/nidr
>
> # imports: http://qudt.org/2.1/schema/qudt
>
> # imports: http://qudt.org/2.1/vocab/dimension
>
> # imports: http://qudt.org/2.1/vocab/unit
>
> # imports: http://www.linkedmodel.org/schema/vaem
>
>
>
> @prefix dc: <http://purl.org/dc/elements/1.1/> .
>
> @prefix dct: <http://purl.org/dc/terms/> .
>
> @prefix mc: <http://www.linkedmodel.org/owl/schema/core#
> <http://www.linkedmodel.org/owl/schema/core>> .
>
> @prefix owl: <http://www.w3.org/2002/07/owl#
> <http://www.w3.org/2002/07/owl>> .
>
> @prefix prov: <http://www.w3.org/ns/prov# <http://www.w3.org/ns/prov>> .
>
> @prefix quantitykind: <http://qudt.org/vocab/quantitykind/> .
>
>
>
> I assumed that I in the end have it working for importing:
>
> http://qudt.org/vocab/quantitykind
>
>
>
> right?
>
> (where server-negotiation will lead to the latest version)
>
>
>
>
>
> Depends.  If QUDT is only published in a versioned form or its server only
> supports the versioned form, then you will have to import the specific
> version you want to use. Also, servers used for the publication of
> ontologies for general reuse are often *not* intended to be used “live” in
> an app and so may not do what you expect. I don’t know the situation for
> qudt.org but I would not be surprised if there is no content negotiation
> (e.g. it’s a simple server of files). 

Re: [topbraid-users] qudt2.1 use issue

[Steve Ray]

As David mentioned, our class URIs do not have versions. So,
http://qudt.org/vocab/unit/M resolves to either the ttl definition or an
html file, depending on the header (turtle or html)
(e.g. curl -i -H 'Accept: text/turtle' http://qudt.org/vocab/unit/M or
curl -i -H 'Accept: text/html' http://qudt.org/vocab/unit/M )

The graph URIs with and without versions both resolve:
http://qudt.org/2.1/vocab/unit resolves to a graph with base URI of
http://qudt.org/2.1/vocab/unit
http://qudt.org/vocab/unit resolves to a graph with base URI of
http://qudt.org/vocab/unit

I just noticed that I neglected to define a unit: prefix in the versionless
graph. That is an error on my part that I will correct (once I figure out
why sml:ExportToRDFFile didn't include it).
In the versioned graph, the unit: prefix is defined as
http://qudt.org/vocab/unit so that all the individual units resolve
correctly.

The actual definitions in the versionless graph are currently the same
(with housekeeping exceptions) as the 2.1 version, but sometime in the
future, there will be a 2.2 or 3.0 version, and http://qudt.org/vocab/unit will
point to that.
The housekeeping changes in the versionless one are:
1. Changed the base URI to be versionless
2. Replaced the ontology declaration triples to the versionless one
3. Updated all defined instances in the qudt.org/vocab namespace (in the
subject graph) with an additional rdfs:isDefinedBy relation, pointing to
the versionless graph
4. Updated the metadata instance with an additional rdfs:isDefinedBy
relation, pointing to the versionless graph


I would welcome design advice regarding what should resolve to what. I
believe it is behaving as intended, but I may be unaware of some best
practices.

Steve




On Tue, Sep 17, 2019 at 3:28 AM 'Bohms, H.M. (Michel)' via TopBraid Suite
Users  wrote:

> - stability
>
> - security
>
> -performance
>
>
>
> Indeed all good reasons to do things locally. True.
>
>
>
> Still we see (even I engineering context) a trend towards distribution ie
> using the web it was meant to be. Clearly one needs more (pre)harmonization
> of modelling and linking approaches and agree on “who does what semantics”.
> This process is actually going on in NL.
>
>
>
> Anyway, the envisioned network/ecosystem of ontologies/datasets is surely
> hard to get to for all reasons you mentioned. So it will surely depend on
> the actual use case.
>
>
>
> WRT qudt: certain that Steve is having/working on a negotiating server
> that gives the latest version when no version is mentioned. Guess just some
> small issues left in the files (like 2.0/2.1 mixup for qudt scheme, some
> names spaces included but not used and no dereferencing of qudt scheme).
> Hopefully soon resolved so that the great stuff of qudt can finally be
> applied.
>
>
>
> Gr Michel
>
>
>
>
>
> Dr. ir. H.M. (Michel) Böhms
> Senior Data Scientist
>
> T +31888663107
> M +31630381220
> E michel.bo...@tno.nl
>
> Location
> <https://www.google.com/maps/place/TNO+-+Locatie+Delft+-+Stieltjesweg/@52.000788,4.3745183,17z/data=!3m1!4b1!4m5!3m4!1s0x47c5b58c52869997:0x56681566be3b8c88!8m2!3d52.000788!4d4.376707>
>
>
>
> <http://www.tno.nl/>
>
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use
> it and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
>
>
>
>
>
>
>
>
>
> *Van:* topbraid-users@googlegroups.com  
> *Namens
> *dprice
> *Verzonden:* Tuesday, September 17, 2019 12:14 PM
> *Aan:* topbraid-users@googlegroups.com
> *CC:* Steve Ray 
> *Onderwerp:* Re: [topbraid-users] qudt2.1 use issue
>
>
>
>
>
>
>
> On 17 Sep 2019, at 09:53, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <
> topbraid-users@googlegroups.com> wrote:
>
>
>
> Thx David for your extensive feedback. I see all your points (esp. from an
> IDE viewpoint). At the same time we see a trend away from data
> copy/import/exchange to sharing via publication ie more decentral
> approaches (for both data and structure). And yes those approaches come
> with issues like uncontrolled change etc. So I guess we always have to find
> a balance.
>
>
>
> Given how I know you, I assume the “structure” you mention will mostly be
> used in an engineering environment.
>
>
>
> FWIW I would not allow “uncontrolled change” to happen on any
> project/programme in the engineering world over which I had any control wrt
> defining its semantics. Data/structure for human i

Re: [topbraid-users] RE: dereferencing ok?

[Steve Ray]

Michel,
I believe the difference you are seeing is because of how you reference the
definition.

When you ask for http://qudt.org/2.1/vocab/unit, you get a graph with base
URI of http://qudt.org/2.1/vocab/unit
In that graph, unit:M specifies:
rdfs:isDefinedBy  ;

When you ask for http://qudt.org/vocab/unit, you get "the latest version"
of the graph, with base URI of http://qudt.org/vocab/unit
In that graph, unit:M specifies:
rdfs:isDefinedBy  ;
rdfs:isDefinedBy  ;

This is as I intended, because both statements are true, since 2.1 is the
latest version at present.

The QUDT 2.1 catalog at http://www.qudt.org/2.1/catalog/qudt-catalog.html is
intended for a human audience, and it shows you the 2.1 version of
definitions via html pages. (You can also visit earlier versions of the
catalog from the QUDT homepage at http://qudt.org/)
The resolvable URIs for "unit" discussed earlier in this message are
intended for a machine audience, where Turtle files are delivered rather
than html files.

I'm open to suggestions from the community as to how this should behave if
not the above.

Steve




On Fri, Sep 13, 2019 at 4:00 AM 'Bohms, H.M. (Michel)' via TopBraid Suite
Users  wrote:

> Ok, I found: its untyped.
>
>
>
> But is this to be expected?
>
>
>
> In example I have:
>
>
>
> ex2:ClearOpeningHeight_1
>
>   a ex2:ClearOpeningHeight ;
>
>   bs:hasUnit unit:M ;
>
>   bs:hasValue 2.40 ;
>
> .
>
>
>
> Where the not-imported resource is:
>
> @prefix unit:  .
>
>
>
> This unit gets me to a file on the web in which is defined:
>
>
>
> 
>
>   a  ;
>
>   a  ;
>
>   a  ;
>
>   a  ;
>
>    "m" ;
>
>    "1090" ;
>
>    "1"^^xsd:double ;
>
>    "0.0"^^xsd:double ;
>
>    "The metric and SI base unit
> of distance.   The meter is equal to approximately 1.093 613 3 yards, 3.280
> 840 feet, or 39.370 079 inches."^^rdf:HTML ;
>
>    <
> http://qudt.org/vocab/quantitykind/Length> ;
>
>    "U000E1090" ;
>
>    "The metric and SI base
> unit of distance.  The 17th General Conference on Weights and Measures in
> 1983 defined the meter as that distance that makes the speed of light in a
> vacuum equal to exactly 299 792 458 meters per second. The speed of light
> in a vacuum, $c$, is one of the fundamental constants of nature. The meter
> is equal to approximately 1.093 613 3 yards, 3.280 840 feet, or 39.370 079
> inches." ;
>
>    "m" ;
>
>    "M" ;
>
>    "m" ;
>
>    "M" ;
>
>    "m" ;
>
>    "MTR" ;
>
>   rdfs:isDefinedBy  ;
>
> rdfs:isDefinedBy  ;
>
>   rdfs:label "Meter" ;
>
>    <
> http://dbpedia.org/resource/Metre> ;
>
>    "meter" ;
>
>    <
> http://en.wikipedia.org/wiki/Metre?oldid=495145797> ;
>
> .
>
>
>
>
>
>
>
> Ps Steve, the file above is diff. from the one, one could download:
>
>
>
> IN HERE it says (using the prefix):
>
>
>
> unit:M
>
>   a qudt:BaseUnit ;
>
>   a qudt:LengthUnit ;
>
>   a qudt:MKS-Unit ;
>
>   a qudt:Unit ;
>
>   qudt:abbreviation "m" ;
>
>   qudt:code "1090" ;
>
>   qudt:conversionMultiplier "1"^^xsd:double ;
>
>   qudt:conversionOffset "0.0"^^xsd:double ;
>
>   qudt:description "The metric and SI base unit of distance.   The meter
> is equal to approximately 1.093 613 3 yards, 3.280 840 feet, or 39.370 079
> inches."^^rdf:HTML ;
>
>   qudt:hasQuantityKind quantitykind:Length ;
>
>   qudt:id "U000E1090" ;
>
>   qudt:longDescription "The metric and SI base unit of distance.  The 17th
> General Conference on Weights and Measures in 1983 defined the meter as
> that distance that makes the speed of light in a vacuum equal to exactly
> 299 792 458 meters per second. The speed of light in a vacuum, $c$, is one
> of the fundamental constants of nature. The meter is equal to approximately
> 1.093 613 3 yards, 3.280 840 feet, or 39.370 079 inches." ;
>
>   qudt:symbol "m" ;
>
>   qudt:ucumCaseInsensitiveCode "M" ;
>
>   qudt:ucumCaseSensitiveCode "m" ;
>
>   qudt:ucumCode "M" ;
>
>   qudt:ucumCode "m" ;
>
>   qudt:uneceCommonCode 

Re: [topbraid-users] Re: qudt revisited

[Steve Ray]

Michel,
Try declaring QuantityKind a subclass of rdfs:Datatype

Steve




On Thu, Sep 5, 2019 at 12:04 AM 'Bohms, H.M. (Michel)' via TopBraid Suite
Users  wrote:

>
>
>
>
> Sounds great Steve!
>
> Will do testing asp.
>
>
>
> Small quick question:
>
> What would be the simplest way to be able to use te quantitykinds as
> datatypes?
>
> (we now use CDT/UCUM here but I want to have aQUDT2.1
> alternative/replacement).
>
>
>
> So I can do:
>
> :MyInstance :height “12.5 M”^^quantitykind:Length .
>
>
>
> (earlier for qudt the unit was used that way in one of the use casese:
>
> :MyInstance :height “12.5”^^unit:M .
>
> )
>
>
>
>
>
>
>
>
>
> Dr. ir. H.M. (Michel) Böhms
> Senior Data Scientist
>
> T +31888663107
> M +31630381220
> E michel.bo...@tno.nl
>
> Location
> <https://www.google.com/maps/place/TNO+-+Locatie+Delft+-+Stieltjesweg/@52.000788,4.3745183,17z/data=!3m1!4b1!4m5!3m4!1s0x47c5b58c52869997:0x56681566be3b8c88!8m2!3d52.000788!4d4.376707>
>
>
>
> <http://www.tno.nl/>
>
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use
> it and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
>
>
>
>
>
>
>
>
>
> *From:* topbraid-users@googlegroups.com  *On
> Behalf Of *Steve Ray
> *Sent:* Wednesday, September 4, 2019 10:02 PM
> *To:* TopBraid Suite Users 
> *Subject:* Re: [topbraid-users] Re: qudt revisited
>
>
>
> Michel,
>
>
>
> The URIs have been cleaned up, so now you can resolve the prefixes, and
> none of them contain the extraneous "all".
>
>
> Steve
>
>
>
>
>
> On Tue, Sep 3, 2019 at 11:59 PM 'Bohms, H.M. (Michel)' via TopBraid Suite
> Users  wrote:
>
> All clear, thx
>
>
>
> And yes link works here too so example was not ok
>
>
>
> Guess your system works but still the all’s might better go making
> baseURIs and prefix the same?
>
>
>
> Greetings Michel
>
>
>
>
>
>
>
>
>
>
>
> Dr. ir. H.M. (Michel) Böhms
> Senior Data Scientist
>
> T +31888663107
> M +31630381220
> E michel.bo...@tno.nl
>
> Location
> <https://www.google.com/maps/place/TNO+-+Locatie+Delft+-+Stieltjesweg/@52.000788,4.3745183,17z/data=!3m1!4b1!4m5!3m4!1s0x47c5b58c52869997:0x56681566be3b8c88!8m2!3d52.000788!4d4.376707>
>
>
>
> <http://www.tno.nl/>
>
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use
> it and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
>
>
>
>
>
>
>
>
>
> *From:* topbraid-users@googlegroups.com  *On
> Behalf Of *Steve Ray
> *Sent:* Tuesday, September 3, 2019 7:14 PM
> *To:* TopBraid Suite Users 
> *Subject:* Re: [topbraid-users] Re: qudt revisited
>
>
>
> Hi Michel,
>
> Yes, those imported 2.0 graphs haven't changed so their inclusion is
> intentional.
>
>
>
> Regarding the URI names that use the "all" in them, that is something I'm
> working on right now so that indeed the base URIs and the prefixes and
> dereferenceable. I'm a little surprised at your example,
>
> For example: unit:M (http://qudt.org/vocab/unit/M)
>
> ...because the link works fine for me, both from a browser, and from a
> terminal using curl.
>
>
>
>
> Steve
>
>
>
>
>
> On Sun, Sep 1, 2019 at 11:28 PM 'Bohms, H.M. (Michel)' via TopBraid Suite
> Users  wrote:
>
> Hi Steve,
>
>
>
> When I go to: http://www.qudt.org/2.1/catalog/qudt-catalog.html
>
>
>
> I see still see 2.0 stuff (maybe intentional)
>
>
>
>
>
> Furthermore when I download unit/all:
>
>
>
> Normally my baseURIs are the same as the prefixes (well apart from a / or
> #).
>
> So currently,
>
> For example: unit:M (http://qudt.org/vocab/unit/M)
>
>
>
> Cannot be found (is not dereferenceable).
>
>
>
> Better to adapt base URIs? Delete the “all”-part? Same for quantities...
>
>
>
> Gr Michel
>
>
>
>
>
>
>
>
>
>
>
>
>
> Dr. ir. H.M. (Michel) Böhms
> Senior Data Sci

Re: [topbraid-users] Re: qudt revisited

[Steve Ray]

Michel,

The URIs have been cleaned up, so now you can resolve the prefixes, and
none of them contain the extraneous "all".

Steve




On Tue, Sep 3, 2019 at 11:59 PM 'Bohms, H.M. (Michel)' via TopBraid Suite
Users  wrote:

> All clear, thx
>
>
>
> And yes link works here too so example was not ok
>
>
>
> Guess your system works but still the all’s might better go making
> baseURIs and prefix the same?
>
>
>
> Greetings Michel
>
>
>
>
>
>
>
>
>
>
>
> Dr. ir. H.M. (Michel) Böhms
> Senior Data Scientist
>
> T +31888663107
> M +31630381220
> E michel.bo...@tno.nl
>
> Location
> <https://www.google.com/maps/place/TNO+-+Locatie+Delft+-+Stieltjesweg/@52.000788,4.3745183,17z/data=!3m1!4b1!4m5!3m4!1s0x47c5b58c52869997:0x56681566be3b8c88!8m2!3d52.000788!4d4.376707>
>
>
>
> <http://www.tno.nl/>
>
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use
> it and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
>
>
>
>
>
>
>
>
>
> *From:* topbraid-users@googlegroups.com  *On
> Behalf Of *Steve Ray
> *Sent:* Tuesday, September 3, 2019 7:14 PM
> *To:* TopBraid Suite Users 
> *Subject:* Re: [topbraid-users] Re: qudt revisited
>
>
>
> Hi Michel,
>
> Yes, those imported 2.0 graphs haven't changed so their inclusion is
> intentional.
>
>
>
> Regarding the URI names that use the "all" in them, that is something I'm
> working on right now so that indeed the base URIs and the prefixes and
> dereferenceable. I'm a little surprised at your example,
>
> For example: unit:M (http://qudt.org/vocab/unit/M)
>
> ...because the link works fine for me, both from a browser, and from a
> terminal using curl.
>
>
>
>
> Steve
>
>
>
>
>
> On Sun, Sep 1, 2019 at 11:28 PM 'Bohms, H.M. (Michel)' via TopBraid Suite
> Users  wrote:
>
> Hi Steve,
>
>
>
> When I go to: http://www.qudt.org/2.1/catalog/qudt-catalog.html
>
>
>
> I see still see 2.0 stuff (maybe intentional)
>
>
>
>
>
> Furthermore when I download unit/all:
>
>
>
> Normally my baseURIs are the same as the prefixes (well apart from a / or
> #).
>
> So currently,
>
> For example: unit:M (http://qudt.org/vocab/unit/M)
>
>
>
> Cannot be found (is not dereferenceable).
>
>
>
> Better to adapt base URIs? Delete the “all”-part? Same for quantities...
>
>
>
> Gr Michel
>
>
>
>
>
>
>
>
>
>
>
>
>
> Dr. ir. H.M. (Michel) Böhms
> Senior Data Scientist
>
> T +31888663107
> M +31630381220
> E michel.bo...@tno.nl
>
> Location
> <https://www.google.com/maps/place/TNO+-+Locatie+Delft+-+Stieltjesweg/@52.000788,4.3745183,17z/data=!3m1!4b1!4m5!3m4!1s0x47c5b58c52869997:0x56681566be3b8c88!8m2!3d52.000788!4d4.376707>
>
>
>
> <http://www.tno.nl/>
>
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use
> it and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
>
>
>
>
>
>
>
>
>
> *From:* topbraid-users@googlegroups.com  *On
> Behalf Of *Steve Ray
> *Sent:* Thursday, August 29, 2019 5:48 PM
> *To:* TopBraid Suite Users 
> *Subject:* Re: [topbraid-users] Re: qudt revisited
>
>
>
> Michel,
>
> When did you last test the links? I'm getting the following results:
>
> Clicking the "Turtle" button for units in the 2.1 catalog delivers
> qudt.org/2.1/vocab/unit/all, which begins with:
>
> # baseURI: http://qudt.org/2.1/vocab/unit/all
>
> # imports: http://qudt.org/2.0/schema/qudt/science
>
> # imports: http://qudt.org/2.1/schema/qudt
>
> # imports: http://qudt.org/2.1/vocab/quantitykind/all
>
> # imports: http://www.linkedmodel.org/schema/vaem
>
> Is your comment about the 2.0 version of
> http://qudt.org/2.0/schema/qudt/science? We haven't updated that part of
> the schema, so it is still 2.0.
>
>
>
> Regarding your second question, perhaps you can help me figure out the
> following issue:
>
>
>
> We want the unit: prefix to expand to http://qudt.org/vocab/unit
>
&g

Re: [topbraid-users] Re: qudt revisited

[Steve Ray]

Hi Michel,
Yes, those imported 2.0 graphs haven't changed so their inclusion is
intentional.

Regarding the URI names that use the "all" in them, that is something I'm
working on right now so that indeed the base URIs and the prefixes and
dereferenceable. I'm a little surprised at your example,

For example: unit:M (http://qudt.org/vocab/unit/M)

...because the link works fine for me, both from a browser, and from a
terminal using curl.


Steve




On Sun, Sep 1, 2019 at 11:28 PM 'Bohms, H.M. (Michel)' via TopBraid Suite
Users  wrote:

> Hi Steve,
>
>
>
> When I go to: http://www.qudt.org/2.1/catalog/qudt-catalog.html
>
>
>
> I see still see 2.0 stuff (maybe intentional)
>
>
>
>
>
> Furthermore when I download unit/all:
>
>
>
> Normally my baseURIs are the same as the prefixes (well apart from a / or
> #).
>
> So currently,
>
> For example: unit:M (http://qudt.org/vocab/unit/M)
>
>
>
> Cannot be found (is not dereferenceable).
>
>
>
> Better to adapt base URIs? Delete the “all”-part? Same for quantities...
>
>
>
> Gr Michel
>
>
>
>
>
>
>
>
>
>
>
>
>
> Dr. ir. H.M. (Michel) Böhms
> Senior Data Scientist
>
> T +31888663107
> M +31630381220
> E michel.bo...@tno.nl
>
> Location
> <https://www.google.com/maps/place/TNO+-+Locatie+Delft+-+Stieltjesweg/@52.000788,4.3745183,17z/data=!3m1!4b1!4m5!3m4!1s0x47c5b58c52869997:0x56681566be3b8c88!8m2!3d52.000788!4d4.376707>
>
>
>
> <http://www.tno.nl/>
>
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use
> it and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
>
>
>
>
>
>
>
>
>
> *From:* topbraid-users@googlegroups.com  *On
> Behalf Of *Steve Ray
> *Sent:* Thursday, August 29, 2019 5:48 PM
> *To:* TopBraid Suite Users 
> *Subject:* Re: [topbraid-users] Re: qudt revisited
>
>
>
> Michel,
>
> When did you last test the links? I'm getting the following results:
>
> Clicking the "Turtle" button for units in the 2.1 catalog delivers
> qudt.org/2.1/vocab/unit/all, which begins with:
>
> # baseURI: http://qudt.org/2.1/vocab/unit/all
>
> # imports: http://qudt.org/2.0/schema/qudt/science
>
> # imports: http://qudt.org/2.1/schema/qudt
>
> # imports: http://qudt.org/2.1/vocab/quantitykind/all
>
> # imports: http://www.linkedmodel.org/schema/vaem
>
> Is your comment about the 2.0 version of
> http://qudt.org/2.0/schema/qudt/science? We haven't updated that part of
> the schema, so it is still 2.0.
>
>
>
> Regarding your second question, perhaps you can help me figure out the
> following issue:
>
>
>
> We want the unit: prefix to expand to http://qudt.org/vocab/unit
>
> …and the quantitykind prefix to expand to
> http://qudt.org/vocab/quantitykind
>
>
>
> On our website, the folder structure is:
>
>
>
> qudt.org/
>
> vocab/
>
> unit/
>
> all (the ttl file containing the unit graph)
>
> A (the ttl file containing the definition of the Ampere)
>
> A-HR (the ttle file containing the definition of the
> Ampere-Hour)
>
> …etc
>
>
>
> This structure therefore supports dereferencing:
>
> qudt.org/vocab/unit/all for the units graph
>
> qudt.org/vocab/unit/A for the definition of the Ampere
>
> etc.
>
>
>
> My problem is that the URI http://qudt.org/vocab/unit alone, dereferences
> to the folder that contains the other files (all, A, A-HR, etc…)
>
> I think I would have to do some sort of redirection of the web server to
> make http://qudt.org/vocab/unit return the “all” file.
>
>
>
> …and I’m not expert enough in web server configuration to know how to do
> that. Do you know how?
>
>
>
> Steve
>
>
>
>
>
> On Wed, Aug 28, 2019 at 11:59 PM 'Bohms, H.M. (Michel)' via TopBraid Suite
> Users  wrote:
>
> (late reply because of holidays...)
>
>
>
> Dear Steve,
>
> That is good news!
>
>
>
> Some questions:
>
>
>
> 1-when I download the unit ttl it is still called 2.0 iso 2.1, is that ok?
>
> 2-IN the file the unit prefix is http://qudt.org/vocab/unit/ ... how is
> this related to the new base URI? Is it really dereferenceable this way?
>
>
>
> I see it’s different for quantitikinds...this seems to work...why mot the
> same

Re: [topbraid-users] Re: qudt revisited

[Steve Ray]

Michel,
When did you last test the links? I'm getting the following results:
Clicking the "Turtle" button for units in the 2.1 catalog delivers
qudt.org/2.1/vocab/unit/all, which begins with:

# baseURI: http://qudt.org/2.1/vocab/unit/all
# imports: http://qudt.org/2.0/schema/qudt/science
# imports: http://qudt.org/2.1/schema/qudt
# imports: http://qudt.org/2.1/vocab/quantitykind/all
# imports: http://www.linkedmodel.org/schema/vaem

Is your comment about the 2.0 version of
http://qudt.org/2.0/schema/qudt/science? We haven't updated that part of
the schema, so it is still 2.0.

Regarding your second question, perhaps you can help me figure out the
following issue:

We want the unit: prefix to expand to http://qudt.org/vocab/unit
…and the quantitykind prefix to expand to http://qudt.org/vocab/quantitykind

On our website, the folder structure is:

qudt.org/
vocab/
unit/
all (the ttl file containing the unit graph)
A (the ttl file containing the definition of the Ampere)
A-HR (the ttle file containing the definition of the
Ampere-Hour)
…etc

This structure therefore supports dereferencing:
qudt.org/vocab/unit/all for the units graph
qudt.org/vocab/unit/A for the definition of the Ampere
etc.

My problem is that the URI http://qudt.org/vocab/unit alone, dereferences
to the folder that contains the other files (all, A, A-HR, etc…)
I think I would have to do some sort of redirection of the web server to
make http://qudt.org/vocab/unit return the “all” file.

…and I’m not expert enough in web server configuration to know how to do
that. Do you know how?

Steve




On Wed, Aug 28, 2019 at 11:59 PM 'Bohms, H.M. (Michel)' via TopBraid Suite
Users  wrote:

> (late reply because of holidays...)
>
>
>
> Dear Steve,
>
> That is good news!
>
>
>
> Some questions:
>
>
>
> 1-when I download the unit ttl it is still called 2.0 iso 2.1, is that ok?
>
> 2-IN the file the unit prefix is http://qudt.org/vocab/unit/ ... how is
> this related to the new base URI? Is it really dereferenceable this way?
>
>
>
> I see it’s different for quantitikinds...this seems to work...why mot the
> same for units: ie use prefix:
>
> http://qudt.org/2.1/vocab/unit/all for unit
>
> (I see it IS available)
>
>
>
> Thx Michel
>
>
>
>
>
>
>
>
>
>
>
> Dr. ir. H.M. (Michel) Böhms
> Senior Data Scientist
>
> T +31888663107
> M +31630381220
> E michel.bo...@tno.nl
>
> Location
> <https://www.google.com/maps/place/TNO+-+Locatie+Delft+-+Stieltjesweg/@52.000788,4.3745183,17z/data=!3m1!4b1!4m5!3m4!1s0x47c5b58c52869997:0x56681566be3b8c88!8m2!3d52.000788!4d4.376707>
>
>
>
> <http://www.tno.nl/>
>
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use
> it and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
>
>
>
>
>
>
>
>
>
> *From:* topbraid-users@googlegroups.com  *On
> Behalf Of *Steve Ray
> *Sent:* Friday, August 9, 2019 11:12 PM
> *To:* TopBraid Suite Users 
> *Subject:* Re: [topbraid-users] Re: qudt revisited
>
>
>
> Hi Michel and Anne,
>
> Please take another look at qudt.org, and check out our Release 2.1
>
> I have been busy organizing things there, and now all our units and
> quantity kinds are dereferenceable.
>
> I'm currently working on the dimension vectors.
>
> I'm hoping that what is published is at least consistent (in terms of
> qnames), and am focusing on getting a core set of units, quantity kinds and
> dimension vectors available.
>
> Then we will go back and clean up. Please let me know if there are key
> units or quantity kinds that you are particularly interested in.
>
>
>
>  - Steve Ray
>
> On Thursday, July 18, 2019 at 9:24:33 AM UTC-7, AW wrote:
>
> Thank you, Michel.   If the underlying resources are not available, that
> also seems like a barrier.
>
>
>
> On Thu, Jul 18, 2019 at 12:46 AM 'Bohms, H.M. (Michel)' via TopBraid Suite
> Users  wrote:
>
> I will.
>
> Complexity is ok imho, it’s just that it takes so long to have the
> resources available/online.
>
>
>
>
>
>
>
>
>
>
>
> Dr. ir. H.M. (Michel) Böhms
> Senior Data Scientist
>
> T +31888663107
> M +31630381220
> E michel.bo...@tno.nl
>
> Location
> <https://www.google.com/maps/place/TNO+-+Locatie+Delft+-+Stieltjesweg/@52.000788,4.3745183,17z/data=!3m1!4b1!4m5!3m4!1s0x47c5b58c52869997:0x56681566be3

Re: [topbraid-users] Re: qudt revisited

[Steve Ray]

Hi Michel and Anne,
Please take another look at qudt.org, and check out our Release 2.1
I have been busy organizing things there, and now all our units and 
quantity kinds are dereferenceable.
I'm currently working on the dimension vectors.
I'm hoping that what is published is at least consistent (in terms of 
qnames), and am focusing on getting a core set of units, quantity kinds and 
dimension vectors available.
Then we will go back and clean up. Please let me know if there are key 
units or quantity kinds that you are particularly interested in.

 - Steve Ray

On Thursday, July 18, 2019 at 9:24:33 AM UTC-7, AW wrote:
>
> Thank you, Michel.   If the underlying resources are not available, that 
> also seems like a barrier.
>
> On Thu, Jul 18, 2019 at 12:46 AM 'Bohms, H.M. (Michel)' via TopBraid Suite 
> Users > wrote:
>
>> I will.
>>
>> Complexity is ok imho, it’s just that it takes so long to have the 
>> resources available/online.
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>> Dr. ir. H.M. (Michel) Böhms
>> Senior Data Scientist
>>
>> T +31888663107
>> M +31630381220
>> E michel.bo...@tno.nl 
>>
>> Location 
>> <https://www.google.com/maps/place/TNO+-+Locatie+Delft+-+Stieltjesweg/@52.000788,4.3745183,17z/data=!3m1!4b1!4m5!3m4!1s0x47c5b58c52869997:0x56681566be3b8c88!8m2!3d52.000788!4d4.376707>
>>
>>  
>>
>> <http://www.tno.nl/>
>>
>> This message may contain information that is not intended for you. If you 
>> are not the addressee or if this message was sent to you by mistake, you 
>> are requested to inform the sender and delete the message. TNO accepts no 
>> liability for the content of this e-mail, for the manner in which you use 
>> it and for damage of any kind resulting from the risks inherent to the 
>> electronic transmission of messages. 
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>> *Van:* topbrai...@googlegroups.com  <
>> topbrai...@googlegroups.com > *Namens *AW
>> *Verzonden:* woensdag 17 juli 2019 17:06
>> *Aan:* TopBraid Suite Users >
>> *Onderwerp:* [topbraid-users] Re: qudt revisited
>>
>>  
>>
>> Hi Michel,
>>
>>  
>>
>> Just writing to say that I'm interested in following your experience with 
>> QUDT.We looked into using it at one point.The complexity was 
>> daunting, and we decided against it for something much simpler of our own 
>> design.   I hope you'll post further about your experience.
>>
>>  
>>
>> Anne
>>
>> -- 
>> 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 topbrai...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/topbraid-users/a55edefd-58d7-40dc-9ba8-7f900593dcb9%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/topbraid-users/a55edefd-58d7-40dc-9ba8-7f900593dcb9%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>> -- 
>> 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 topbrai...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/topbraid-users/f99e9bbee1d24ab1a11ed6c2f8d8a7ac%40tno.nl
>>  
>> <https://groups.google.com/d/msgid/topbraid-users/f99e9bbee1d24ab1a11ed6c2f8d8a7ac%40tno.nl?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/28e4e90b-643a-4ca5-897b-e2d02d227036%40googlegroups.com.

[topbraid-users] How to stop TBC from auto-updating .xlsx files?

[Steve Ray]

Hi,
On several projects, I have noticed that TBC-ME will automatically change
one or more .xlsx files that are in my workspace, even if I don't open
them. I'm assuming this has something to do with those files being
interpreted by TBC, but I don't want TBC to change the original .xlsx file.
Is there some preference setting that I'm unaware of to keep it from
"roundtripping" changes back to the .xlsx file?


Steve Ray
Phone: (650) 587-3780 (CA)
  (202) 362-5059 (DC)
Cell:  (202) 316-6481

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [topbraid-users] Best practices recommendation request

[Steve Ray]

Thanks for the speedy reply, Holger. Your suggestion aligns with what I was
planning to do, so that's encouraging. I just wanted to make sure I wasn't
missing anything.
And no, the script doesn't try to do any dynamic changing of the input
arguments, so I should be OK with the web service approach.

 - Steve

Steven R. Ray, Ph.D.
Distinguished Research Fellow
Carnegie Mellon University
NASA Research Park
Building 23 (MS 23-11)
P.O. Box 1
Moffett Field, CA 94305-0001
Email:   steve@sv.cmu.edu
Phone: (650) 587-3780
Cell: (202) 316-6481
Skype:  steverayconsulting


On Mon, Feb 4, 2019 at 5:43 PM Holger Knublauch 
wrote:

> Hi Steve,
>
> the sml:EnterLiteral module in your script appears to be used to enter the
> names of files that are loaded while the script executes. We have removed
> that feature because it only works in TBC but not in the more common case
> of when scripts are called as (web) services. In your case I believe you
> could turn this script into a web service too and simply declare the three
> file names as arguments. Basically define a sm:Function that has the end
> point of your script as sm:returnModule, and use spl:Arguments (at
> spin:constraint) to declare the input parameters. Then call the script from
> the URL of the SPARQLMotion servlet and pass the names in as part of the
> URL, e.g. roughly
>
>
> http://localhost:8083/tbl/sparqlmotion?...=myCircuitFile.ttl;
> ...
>
> This has the obvious advantage that people don't need to repeat the same
> strings over and over again in the input dialog, but can instead copy and
> paste and modify the URL. To make it more convenient, some of our staff
> create HTML forms with  fields where the HTML form calls the web
> service. I can outline that if you don't have much HTML skills handy.
>
> The solution above would not really work if the script were to request
> different input strings depending on the execution flow. But such
> interactive scripts take the design of SPARQLMotion to an edge that we
> probably shouldn't have supported earlier. In these cases, you'd need to
> either collect all data in advance or break the script into multiple steps.
> I don't think this is necessary in your case though.
>
> HTH
> Holger
>
>
> On 5/02/2019 5:32 am, Steve Ray wrote:
>
> Hi,
> Today I was opening up an "old" 2016 project that used to run in TBC-ME
> 5.1 I think. In it is a SPARQLMotion script that contains several
> sml:EnterLiteral modules that now bomb in TBC-ME 6.1 because I believe you
> have removed that module class. I'm asking for what might be the best
> practice to edit this script, which is quite large, so that it runs in 6.1?
>
> (The script is available in the github
> project steveraysteveray/fsgim-owlTesting  as
> input.1/buildReferenceSet.sms.ttl   if you want to dig).
>
>  - Steve
>
> Steven R. Ray, Ph.D.
> Distinguished Research Fellow
> Carnegie Mellon University
> NASA Research Park
> Building 23 (MS 23-11)
> P.O. Box 1
> Moffett Field, CA 94305-0001
> Email:   steve@sv.cmu.edu
> Phone: (650) 587-3780
> Cell: (202) 316-6481
> Skype:  steverayconsulting
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> 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 topbraid-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[topbraid-users] Best practices recommendation request

[Steve Ray]

Hi,
Today I was opening up an "old" 2016 project that used to run in TBC-ME 5.1
I think. In it is a SPARQLMotion script that contains several
sml:EnterLiteral modules that now bomb in TBC-ME 6.1 because I believe you
have removed that module class. I'm asking for what might be the best
practice to edit this script, which is quite large, so that it runs in 6.1?

(The script is available in the github
project steveraysteveray/fsgim-owlTesting  as
input.1/buildReferenceSet.sms.ttl   if you want to dig).

 - Steve

Steven R. Ray, Ph.D.
Distinguished Research Fellow
Carnegie Mellon University
NASA Research Park
Building 23 (MS 23-11)
P.O. Box 1
Moffett Field, CA 94305-0001
Email:   steve@sv.cmu.edu
Phone: (650) 587-3780
Cell: (202) 316-6481
Skype:  steverayconsulting

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[topbraid-users] Fwd: Did exports change with 6.1?

[Steve Ray]

Never mind my last posting. I had imported into my workspace at the repo
root level rather than at the individual project level. Dumb mistake.

 - Steve

Steven R. Ray, Ph.D.
Distinguished Research Fellow
Carnegie Mellon University
NASA Research Park
Building 23 (MS 23-11)
P.O. Box 1
Moffett Field, CA 94305-0001
Email:   steve@sv.cmu.edu
Phone: (650) 587-3780
Cell: (202) 316-6481
Skype:  steverayconsulting


-- Forwarded message -
From: Steve Ray 
Date: Tue, Dec 18, 2018 at 4:05 PM
Subject: Did exports change with 6.1?
To: TopBraid Suite Users 


Hi,
I'm running TBC ME 6.1, and just exported one of my projects to a zip
archive, ready to deploy to TBL on the cloud. However, this time, I noticed
that the zip file doesn't start at the project folder level, but rather two
levels higher, at the root of our git repository. TBL was not happy with
this, complaining about the lack of an appropriate .project file.

Just to be clear, previously (under TBC ME 6.0) I had:

SemanticModels . (the project folder I routinely export)
--.project
--lots of other folders


Now, the zip file contains

demandresponse .  (Our repo root)
--EPIC
SemanticModels . (the project folder I am attempting to export)
--.project
--lots of other folders

To be fair, I have also moved from a Windows environment to a Mac
environment.
Is there a configuration setting I need to adjust?

 - Steve

Steven R. Ray, Ph.D.
Distinguished Research Fellow
Carnegie Mellon University
NASA Research Park
Building 23 (MS 23-11)
P.O. Box 1
Moffett Field, CA 94305-0001
Email:   steve@sv.cmu.edu
Phone: (650) 587-3780
Cell: (202) 316-6481
Skype:  steverayconsulting

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[topbraid-users] Did exports change with 6.1?

[Steve Ray]

Hi,
I'm running TBC ME 6.1, and just exported one of my projects to a zip
archive, ready to deploy to TBL on the cloud. However, this time, I noticed
that the zip file doesn't start at the project folder level, but rather two
levels higher, at the root of our git repository. TBL was not happy with
this, complaining about the lack of an appropriate .project file.

Just to be clear, previously (under TBC ME 6.0) I had:

SemanticModels . (the project folder I routinely export)
--.project
--lots of other folders


Now, the zip file contains

demandresponse .  (Our repo root)
--EPIC
SemanticModels . (the project folder I am attempting to export)
--.project
--lots of other folders

To be fair, I have also moved from a Windows environment to a Mac
environment.
Is there a configuration setting I need to adjust?

 - Steve

Steven R. Ray, Ph.D.
Distinguished Research Fellow
Carnegie Mellon University
NASA Research Park
Building 23 (MS 23-11)
P.O. Box 1
Moffett Field, CA 94305-0001
Email:   steve@sv.cmu.edu
Phone: (650) 587-3780
Cell: (202) 316-6481
Skype:  steverayconsulting

-- 
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 topbraid-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.