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?)
|
|||||||||||||||||
|
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 ...
|
|
--
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.
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/c34d8a25-c2de-407b-a519-bc0c693a121d%40email.android.com.
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.
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. Reference2. Import3. 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/747fe58884ce49fcafb26ecfd630b135%40tno.nl.
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
|
|
|
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/1B96D256-AE74-469B-8C6A-D26EA31EFE49%40topquadrant.com.
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.
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:right?(where server-negotiation will lead to the latest version)
owl:imports <http://qudt.org/2.1/schema/qudt> ; owl:imports <http://qudt.org/2.1/vocab/quantitykind> ;
Gr michel
Dr. ir. H.M. (Michel) Böhms
Senior Data Scientist
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/1d0282848d684e62a9f1faecd7515697%40tno.nl.
- 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
|
|
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/33CEA9AF-1991-4A7B-B6E4-2C1F01D6FB73%40topquadrant.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/ab4e1838c32747a59297f7a0b30ec0ea%40tno.nl.
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
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAGUep86FGWzyKeKSQxyBK16QzODskdn%2B%2B63jtz6vfK2CD%2B%3DEfA%40mail.gmail.com.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/b72d158db5834096b9ca496d3f505a32%40tno.nl.
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)
|
|
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAGUep84f0FVW31eeGWRZmZtFpQP9byrxECeKOQpngCadM21D%2Bw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/1dc5398a36d041f8bc44ed8fd3686f1d%40tno.nl.
All clear, hopefully quick feedback and resolution!
Thx for the good work!
Let me know if you want me to test changes,
Michel
|
|
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAGUep85UUPdCWP8wOSycr%3DpK46Am0hJ0m9n0%3DcU_SzgsR4Y_Xw%40mail.gmail.com.
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?
|
|
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/33CEA9AF-1991-4A7B-B6E4-2C1F01D6FB73%40topquadrant.com.
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:a owl:Ontology ;owl:imports <http://www.w3.org/2004/02/skos/core> ;really needed to import skos?
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/4da523ad3acc427c887ac94fd3c60be9%40tno.nl.
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
|
|
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/92B48854-BA7B-484A-93CB-78D54FA74541%40topquadrant.com.
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 ?
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 importThx Michel
Dr. ir. H.M. (Michel) Böhms
Senior Data Scientist
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/0584501ec2e24a9b9771a8eeb37b76e6%40tno.nl.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/0584501ec2e24a9b9771a8eeb37b76e6%40tno.nl.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/92B48854-BA7B-484A-93CB-78D54FA74541%40topquadrant.com.
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.
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!
|
|
|
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAGUep86DGb6THqisMkU%3Dp3rNTS7a-xD8k1MDBB8H_OGPca06RQ%40mail.gmail.com.