qudt2.1 use issue

[Bohms, H.M. (Michel)]

I updated my ontologies and still got the globe:

 

 

Note that: http://qudt.org/vocab/quantitykind/Length

Is available.

 

In the imported basicsemantics-owl.ttl I added:

 

qudt:QuantityKind rdfs:subClassOf rdfs:Datatype .

 

(also in another example using the quanties and units more directly (not needing the above) I have the same issue.

 

Ideas very welcome,

Thx Michel

 

Ps

Mayb related to  http://qudt.org/schema/qudt/ not being dereferenceable. But when I use the more direct (no need for negotiation):

http://qudt.org/2.0/schema/qudt/ (that IS available)

I have the same globe....

 

Ps also noted:

http://qudt.org/2.0/schema/qudt is ok

but

http://qudt.org/2.0/schema/qudt/QuantityKind gives error (maybe related?)

 

Dr. ir. H.M. (Michel) Böhms Senior Data Scientist T +31888663107 M +31630381220 E michel...@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.

 

 

[Bohms, H.M. (Michel)]

 

When I add to basicsemantics:

 

  owl:imports <http://qudt.org/2.1/vocab/unit> ;

  owl:imports <http://qudt.org/2.1/vocab/quantitykind> ;

  owl:imports <http://qudt.org/2.0/schema/qudt> ;

 

 

all issues are solved.

 

I would however expect that this should not be necessary ...

 

 

Dr. ir. H.M. (Michel) Böhms Senior Data Scientist T +31888663107 M +31630381220 E michel...@tno.nl Location

--
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/435b5afdfdf3408d869da129d92c0bee%40tno.nl.

[dprice]

On 16 Sep 2019, at 13:10, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

In the imported basicsemantics-owl.ttl I added:

 

qudt:QuantityKind rdfs:subClassOf rdfs:Datatype .

 

(also in another example using the quanties and units more directly (not needing the above) I have the same issue.

 

That does not give QuantityKind a type, so you get the globe.

Cheers,

David

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[Bohms, H.M. (Michel)]

See my later mail...i hoped to get a type since quantitykind an unit are derefer.

.....

Op 16 sep. 2019 16:18 schreef dprice <dpr...@topquadrant.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/FCC0EE49-8BA4-42C2-9B34-02483BB26D53%40topquadrant.com.

[dprice]

On 16 Sep 2019, at 15:36, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

See my later mail...i hoped to get a type since quantitykind an unit are derefer.

That is not how Composer works. The globe means "not defined here or in any import, maybe defined on the Web somewhere".

FWIW if any ontology, including basicsemantics, uses something from other schemas it’s best to import that schema. There are, of course, exceptions like annotations such as skos:prefLabel, but those exceptions are not usually declarations of semantics. You can copy over a subset of declarations from ontologies you don’t want to import if for some reason you don’t want all of it.

Cheers,

David

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/c34d8a25-c2de-407b-a519-bc0c693a121d%40email.android.com.

[Bohms, H.M. (Michel)]

 

Mornin David, see after >

 

Van: topbrai...@googlegroups.com <topbrai...@googlegroups.com> Namens dprice
Verzonden: Monday, September 16, 2019 4:50 PM
Aan: topbrai...@googlegroups.com
Onderwerp: Re: [topbraid-users] qudt2.1 use issue

 

 

 

On 16 Sep 2019, at 15:36, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

 

See my later mail...i hoped to get a type since quantitykind an unit are derefer.

 

That is not how Composer works. The globe means "not defined here or in any import, maybe defined on the Web somewhere".

 

>ok clear, the icon legend just says: “untyped resource” so I thought TBC can in principle find its type etc.

 

 

FWIW if any ontology, including basicsemantics, uses something from other schemas it’s best to import that schema. There are, of course, exceptions like annotations such as skos:prefLabel, but those exceptions are not usually declarations of semantics. You can copy over a subset of declarations from ontologies you don’t want to import if for some reason you don’t want all of it.

 

My pref. is always in that order:

1. Reference

2. Import

3. Copy in

 

Especially in our context of defining networks of ontologies we try to stick to 1. amap.

 

But ok, I will import. Unfortunately I have some serious issues preventing that approach for qudt2.1 curently.

 

Qudt schema referenced by unit and quantity (version 2.1) is version 2.1 and the actual version that can be downloaded is 2.0.

Also qudt seems not dereferenceable yet (like unit/quantitykind), and

TBC complains about a nidr ontology it cannot import.

Hopefully Steve can clarify,

 

Greetings Michel

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/A1FF8C34-584A-4F2F-886B-D0C5B03CFAFD%40topquadrant.com.

[dprice]

On 17 Sep 2019, at 07:53, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

 

Mornin David, see after >

 

Van: topbrai...@googlegroups.com <topbrai...@googlegroups.com> Namens dprice
Verzonden: Monday, September 16, 2019 4:50 PM
Aan: topbrai...@googlegroups.com
Onderwerp: Re: [topbraid-users] qudt2.1 use issue

 

 

 

On 16 Sep 2019, at 15:36, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

 

See my later mail...i hoped to get a type since quantitykind an unit are derefer.

 

That is not how Composer works. The globe means "not defined here or in any import, maybe defined on the Web somewhere".

 

>ok clear, the icon legend just says: “untyped resource” so I thought TBC can in principle find its type etc.

 

 

FWIW if any ontology, including basicsemantics, uses something from other schemas it’s best to import that schema. There are, of course, exceptions like annotations such as skos:prefLabel, but those exceptions are not usually declarations of semantics. You can copy over a subset of declarations from ontologies you don’t want to import if for some reason you don’t want all of it.

 

My pref. is always in that order:

1. Reference

2. Import

3. Copy in

Composer is an IDE (i.e. ontologies are components in software, just like Java code). Having any general purpose tool blindly bring classes into scope from the Web is very bad software/semantics development practice. 

One major problem with doing so is that in order to complete the semantics of a referenced class, Composer would have to also bring into scope every superclass of the class - and that is *impossible* in many cases.  There is no way for Composer to find all those superclasses because they are very often in graphs other than the graph in which the referenced class is defined.  So, Composer lets you use reference’d items but it is not going to try and do the semantic analysis necessary to complete the definition of that item because in most cases that it does not have enough information to be able to do that reliably. You as the user have to do that semantic analysis and either import or copy over what is necessary for you use of that referenced item in your scope - or just accept the untyped item in your scope (maybe your software app can has a way to know your scope, what graphs are in play and can resolve those references for you?).

A second major problem is that the referenced item definition could change at any time completely outside your control. That, in general, is a dangerous practice (e.g. all data based on your ontologies could suddenly become invalid/inconsistent).

The cases I’ve seen where untyped but referenced items are used successfully is where external class hierarchies, that are not core to the semantics of an instance, are used from a Reference Data Library (RDL).  However, in those cases the untyped but referenced item appears only in data, not in the semantic definitions/ontologies. Also, in those cases the apps typically know which RDL servers and graphs are involved as background information, something the ontologies cannot “know" because the ontologies are designed to be used in multiple organisations that may each have their own RDL server.

 

Especially in our context of defining networks of ontologies we try to stick to 1. amap.

Defining semantics with that assumption is not a best practice for the reasons I’ve explained. From a software IDE or ontology/semantic tool perspective, that approach assumes the tool can do the impossible in many cases. 

IMO the best practice order when defining semantics to be used in real software apps is:

1 - import of sensibly partitioned graphs designed for reuse

2 - local copy and subsetting of graphs where the graph partitioning does not satisfy your needs (i.e. delete the items you do not want)

3 - copy in for cases where the graph partitioning does not satisfy your needs and you only need a few items

4 - untyped references (i.e. no import or copy)

 

But ok, I will import. Unfortunately I have some serious issues preventing that approach for qudt2.1 curently.

There are often issues when migrating to new versions of libraries/ontologies - and that’s why using a tool like Composer is good practice because at least it’s identifying those issues for you. 

Over to Steve Ray to get those questions resolved. 

Cheers,

David

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/747fe58884ce49fcafb26ecfd630b135%40tno.nl.

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[Bohms, H.M. (Michel)]

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.

 

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:

 

# 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#> .

@prefix owl: <http://www.w3.org/2002/07/owl#> .

@prefix 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)

Gr michel

 

 

 

 

Dr. ir. H.M. (Michel) Böhms Senior Data Scientist T +31888663107 M +31630381220 E michel...@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.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/1B96D256-AE74-469B-8C6A-D26EA31EFE49%40topquadrant.com.

[dprice]

On 17 Sep 2019, at 09:53, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@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#> .

@prefix owl: <http://www.w3.org/2002/07/owl#> .

@prefix 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). If you recall, the V-Con ontologies not being on a server with content negotiation was the rationale for the project making the very bad decision to include the serialisation form in the ontology URIs - so this is a common issue. Looking quickly at the qudt.org Web site I don’t see un-versioned forms of the ontologies and I see this inside the ontologies:

 owl:imports <http://qudt.org/2.1/schema/qudt> ;
 owl:imports <http://qudt.org/2.1/vocab/quantitykind> ;

so seems versioned form is the expectation wrt use. Maybe un-versioned forms do exist - I don’t know. Over to Steve R I guess.

FWIW I’m sure qudt.org also has no performance guarantees - yet another reason not to use structure off the Web in your apps.

Again, to be safe it’s best to take control of the ontologies/structures that are important to an app. In your case, if you’re only publishing an ontology for others to take and use in their apps, then referencing ontologies from the Web is fine. You’re pushing these problems down to the folks implementing the apps that use them, which is also fine in most cases. However, I will add that in my experience most enterprises tightly control the access their internal servers/apps have to the Internet, and so the referencing from the Web approach will not be allowed. It violates security policies.

Cheers,

David

Gr michel

 

 

 

 

Dr. ir. H.M. (Michel) Böhms Senior Data Scientist T +31888663107 M +31630381220 E michel...@tno.nl Location

<image001.gif>

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/1d0282848d684e62a9f1faecd7515697%40tno.nl.

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[Bohms, H.M. (Michel)]

- 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...@tno.nl Location

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/33CEA9AF-1991-4A7B-B6E4-2C1F01D6FB73%40topquadrant.com.

[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

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/ab4e1838c32747a59297f7a0b30ec0ea%40tno.nl.

[Bohms, H.M. (Michel)]

Hi Steve, see after >

 

> My goals is to get qudt2.1 working without importing files (knowing that I will have untypes stuff in tbc).

So be able to use units, quantitykind by reference. To be able to make its possible to use both of them(also)  as datatypes I added 2 triples in my own file to make them subClassOf rdfs:Datatype.

 

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 )

 

in browser:

http://qudt.org/vocab/unit/M works fine

http://qudt.org/vocab/quantitykind/Length works fine too

http://qudt.org/schema/Unit does however not resolve

 

 

 

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.

 

> in unit.ttl it says:

> # imports: http://qudt.org/2.1/schema/qudt

> while there is only a file with baseURI: # baseURI: http://qudt.org/2.0/schema/qudt

 

Finally in quantitykind.ttl there is an import:

# imports: http://qudt.org/2.0/vocab/nidr

 

Where TBC complains it cannot find (its seems also not used in that file)

 

Maybe its all ok, maybe its related to the issue I experience with qudt schema usage...

Thx for checking! Michel

 

Steve

 

 

On Tue, Sep 17, 2019 at 3:28 AM 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> 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...@tno.nl Location

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAGUep86FGWzyKeKSQxyBK16QzODskdn%2B%2B63jtz6vfK2CD%2B%3DEfA%40mail.gmail.com.

[Steve Ray]

Michel,

in browser:

http://qudt.org/vocab/unit/M works fine

http://qudt.org/vocab/quantitykind/Length works fine too

http://qudt.org/schema/Unit does however not resolve

I haven't yet tackled updating the schema files, so this will go on my list.

> in unit.ttl it says:

> # imports: http://qudt.org/2.1/schema/qudt

> while there is only a file with baseURI: # baseURI: http://qudt.org/2.0/schema/qudt

Nice catch, thanks. 

In the near term, I have uploaded http://qudt.org/2.1/schema/qudt so that it resolves. 

However, the catalog and the html pages do not yet reflect the latest qudt schema file, so that's on my list also

 

Finally in quantitykind.ttl there is an import:

# imports: http://qudt.org/2.0/vocab/nidr

Where TBC complains it cannot find (its seems also not used in that file)

I think this may be obsolete. I should remove the nidr import reference from the quantitykind file. On the list.

Steve

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/b72d158db5834096b9ca496d3f505a32%40tno.nl.

[Bohms, H.M. (Michel)]

Great, thanks!

 

Ps

In the meantime I see that the qudt scheme (http://www.qudt.org/schema/qudt) now resolves to an RDF file (not a Turtle file)

 

 

 

Dr. ir. H.M. (Michel) Böhms Senior Data Scientist T +31888663107 M +31630381220 E michel...@tno.nl Location

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAGUep84f0FVW31eeGWRZmZtFpQP9byrxECeKOQpngCadM21D%2Bw%40mail.gmail.com.

[Steve Ray]

That is correct. As I mentioned, I haven't started cleaning up the schema section yet.

Also, as David had mentioned, "one common way of managing the versioning of ontologies … version numbers in the graph URIs, no version numbers in the class URIs"

The question I am looking for community guidance on is whether an un-versioned URI (such as http://www.qudt.org/schema/qudt) should resolve to a graph that has a versioned base URI, or a "clone" that is mostly like the versioned one, but with an un-versioned base URI.

Steve

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/1dc5398a36d041f8bc44ed8fd3686f1d%40tno.nl.

[Bohms, H.M. (Michel)]

 

All clear, hopefully quick feedback and resolution!

Thx for the good work!

 

Let me know if you want me to test changes,

Michel

 

 

Dr. ir. H.M. (Michel) Böhms Senior Data Scientist T +31888663107 M +31630381220 E michel...@tno.nl Location

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAGUep85UUPdCWP8wOSycr%3DpK46Am0hJ0m9n0%3DcU_SzgsR4Y_Xw%40mail.gmail.com.

[Bohms, H.M. (Michel)]

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?

 

 

 

Dr. ir. H.M. (Michel) Böhms Senior Data Scientist T +31888663107 M +31630381220 E michel...@tno.nl Location

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/33CEA9AF-1991-4A7B-B6E4-2C1F01D6FB73%40topquadrant.com.

[dprice]

On 19 Sep 2019, at 08:36, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@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

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/4da523ad3acc427c887ac94fd3c60be9%40tno.nl.

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[Bohms, H.M. (Michel)]

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...@tno.nl Location

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/92B48854-BA7B-484A-93CB-78D54FA74541%40topquadrant.com.

[dprice]

On 19 Sep 2019, at 15:36, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> 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 ?

Not just TBC - any tool would need the same imports (or something else that does the same thing) if you were going to create data based on the ontologies, otherwise the structure is impossible to complete for the reasons I mentioned earlier.

Of course, if you’re just trying to publish an ontology for others to use, then they can add the imports, configure their apps to find ontologies on the Web, etc. themselves. So leaving the definitions incomplete (i.e. with the globe showing in Composer) is not really a big problem.

Cheers,

David

 

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...@tno.nl Location

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/0584501ec2e24a9b9771a8eeb37b76e6%40tno.nl.

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[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

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/0584501ec2e24a9b9771a8eeb37b76e6%40tno.nl.

[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

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/92B48854-BA7B-484A-93CB-78D54FA74541%40topquadrant.com.

[Bohms, H.M. (Michel)]

Clear thx

 

Decided to import in the end to be able to see /use the external info like its abbreviation etcetc, all metadata of he units and quantitykinds.

 

Greetings Michel

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAGUep87rxTrvcHP%3DqMy20HkWDPaFq1p6njDH4%3DKKb8LC73qzcA%40mail.gmail.com.

[Bohms, H.M. (Michel)]

Will keep import of scope in

Also because I want to instantiate skos:Concepts myself for basicsemantics ...

Thx Michel

 

Psif you have any updates of the qudt2.1 ..very welcome!

 

 

 

Dr. ir. H.M. (Michel) Böhms Senior Data Scientist T +31888663107 M +31630381220 E michel...@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.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAGUep86DGb6THqisMkU%3Dp3rNTS7a-xD8k1MDBB8H_OGPca06RQ%40mail.gmail.com.