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<http://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 <topbraid-users@googlegroups.com<mailto:topbraid-users@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.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> [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<mailto:topbraid-users@googlegroups.com> <topbraid-users@googlegroups.com<mailto:topbraid-users@googlegroups.com>> Namens dprice Verzonden: Tuesday, September 17, 2019 12:14 PM 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 09:53, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbraid-users@googlegroups.com<mailto: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<http://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<http://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<mailto: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<https://groups.google.com/d/msgid/topbraid-users/33CEA9AF-1991-4A7B-B6E4-2C1F01D6FB73%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/ab4e1838c32747a59297f7a0b30ec0ea%40tno.nl<https://groups.google.com/d/msgid/topbraid-users/ab4e1838c32747a59297f7a0b30ec0ea%40tno.nl?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/CAGUep86FGWzyKeKSQxyBK16QzODskdn%2B%2B63jtz6vfK2CD%2B%3DEfA%40mail.gmail.com<https://groups.google.com/d/msgid/topbraid-users/CAGUep86FGWzyKeKSQxyBK16QzODskdn%2B%2B63jtz6vfK2CD%2B%3DEfA%40mail.gmail.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. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/b72d158db5834096b9ca496d3f505a32%40tno.nl.