> 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 > <http://qudt.org/2.1/vocab/quantitykind> > # imports: http://qudt.org/2.0/vocab/nidr <http://qudt.org/2.0/vocab/nidr> > # imports: http://qudt.org/2.1/schema/qudt <http://qudt.org/2.1/schema/qudt> > # imports: http://qudt.org/2.1/vocab/dimension > <http://qudt.org/2.1/vocab/dimension> > # imports: http://qudt.org/2.1/vocab/unit <http://qudt.org/2.1/vocab/unit> > # imports: http://www.linkedmodel.org/schema/vaem > <http://www.linkedmodel.org/schema/vaem> > > @prefix dc: <http://purl.org/dc/elements/1.1/ > <http://purl.org/dc/elements/1.1/>> . > @prefix dct: <http://purl.org/dc/terms/ <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/ > <http://qudt.org/vocab/quantitykind/>> . > > I assumed that I in the end have it working for importing: > http://qudt.org/vocab/quantitykind <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 <http://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.bo...@tno.nl <mailto: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> > > > <image001.gif> <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 <mailto:topbraid-users@googlegroups.com> > <topbraid-users@googlegroups.com <mailto:topbraid-users@googlegroups.com>> > Namens dprice > Verzonden: Tuesday, September 17, 2019 9:44 AM > Aan: topbraid-users@googlegroups.com <mailto:topbraid-users@googlegroups.com> > CC: Steve Ray <st...@steveray.com <mailto:st...@steveray.com>> > Onderwerp: Re: [topbraid-users] qudt2.1 use issue > > > > > On 17 Sep 2019, at 07:53, 'Bohms, H.M. (Michel)' via TopBraid Suite Users > <topbraid-users@googlegroups.com <mailto:topbraid-users@googlegroups.com>> > wrote: > > > Mornin David, see after > > > Van: topbraid-users@googlegroups.com <mailto:topbraid-users@googlegroups.com> > <topbraid-users@googlegroups.com <mailto:topbraid-users@googlegroups.com>> > Namens dprice > Verzonden: Monday, September 16, 2019 4:50 PM > Aan: topbraid-users@googlegroups.com <mailto:topbraid-users@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 > <topbraid-users@googlegroups.com <mailto:topbraid-users@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 > > > > 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 <dpr...@topquadrant.com > <mailto:dpr...@topquadrant.com>>: > > > > On 16 Sep 2019, at 13:10, 'Bohms, H.M. (Michel)' via TopBraid Suite Users > <topbraid-users@googlegroups.com <mailto:topbraid-users@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 > > > -- > 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 > <mailto:topbraid-users+unsubscr...@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 > > <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 topbraid-users+unsubscr...@googlegroups.com > <mailto:topbraid-users+unsubscr...@googlegroups.com>. > 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 topbraid-users+unsubscr...@googlegroups.com > <mailto:topbraid-users+unsubscr...@googlegroups.com>. > 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 topbraid-users+unsubscr...@googlegroups.com > <mailto:topbraid-users+unsubscr...@googlegroups.com>. > 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 topbraid-users+unsubscr...@googlegroups.com > <mailto:topbraid-users+unsubscr...@googlegroups.com>. > 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 topbraid-users+unsubscr...@googlegroups.com > <mailto:topbraid-users+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/1d0282848d684e62a9f1faecd7515697%40tno.nl > > <https://groups.google.com/d/msgid/topbraid-users/1d0282848d684e62a9f1faecd7515697%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 topbraid-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/33CEA9AF-1991-4A7B-B6E4-2C1F01D6FB73%40topquadrant.com.
