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 [email protected]<mailto:[email protected]>

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>



[cid:[email protected]]<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: [email protected] <[email protected]> Namens 
dprice
Verzonden: Tuesday, September 17, 2019 9:44 AM
Aan: [email protected]
CC: Steve Ray <[email protected]>
Onderwerp: Re: [topbraid-users] qudt2.1 use issue




On 17 Sep 2019, at 07:53, 'Bohms, H.M. (Michel)' via TopBraid Suite Users 
<[email protected]<mailto:[email protected]>> wrote:


Mornin David, see after >

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



On 16 Sep 2019, at 15:36, 'Bohms, H.M. (Michel)' via TopBraid Suite Users 
<[email protected]<mailto:[email protected]>> 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



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

Cheers,
David

.....

Op 16 sep. 2019 16:18 schreef dprice 
<[email protected]<mailto:[email protected]>>:


On 16 Sep 2019, at 13:10, 'Bohms, H.M. (Michel)' via TopBraid Suite Users 
<[email protected]<mailto:[email protected]>> 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


--
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 
[email protected]<mailto:[email protected]>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/FCC0EE49-8BA4-42C2-9B34-02483BB26D53%40topquadrant.com<https://groups.google.com/d/msgid/topbraid-users/FCC0EE49-8BA4-42C2-9B34-02483BB26D53%40topquadrant.com?utm_medium=email&utm_source=footer>.

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 
[email protected]<mailto:[email protected]>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/c34d8a25-c2de-407b-a519-bc0c693a121d%40email.android.com<https://groups.google.com/d/msgid/topbraid-users/c34d8a25-c2de-407b-a519-bc0c693a121d%40email.android.com?utm_medium=email&utm_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 
[email protected]<mailto:[email protected]>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/A1FF8C34-584A-4F2F-886B-D0C5B03CFAFD%40topquadrant.com<https://groups.google.com/d/msgid/topbraid-users/A1FF8C34-584A-4F2F-886B-D0C5B03CFAFD%40topquadrant.com?utm_medium=email&utm_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 
[email protected]<mailto:[email protected]>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/747fe58884ce49fcafb26ecfd630b135%40tno.nl<https://groups.google.com/d/msgid/topbraid-users/747fe58884ce49fcafb26ecfd630b135%40tno.nl?utm_medium=email&utm_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 
[email protected]<mailto:[email protected]>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/1B96D256-AE74-469B-8C6A-D26EA31EFE49%40topquadrant.com<https://groups.google.com/d/msgid/topbraid-users/1B96D256-AE74-469B-8C6A-D26EA31EFE49%40topquadrant.com?utm_medium=email&utm_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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/1d0282848d684e62a9f1faecd7515697%40tno.nl.

Reply via email to