Thx Holger for both the handy link and action. (it also shows my inverse issue of what the geo prefix supposed to point to well: geosparql or wgs84 (gps)
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 Holger Knublauch Verzonden: woensdag 16 mei 2018 01:58 Aan: [email protected] Onderwerp: Re: [topbraid-users] dublin core prefixes On 15/05/2018 19:09, Bohms, H.M. (Michel) wrote: Van: [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]> Namens Holger Knublauch Verzonden: dinsdag 15 mei 2018 10:37 Aan: [email protected]<mailto:[email protected]> Onderwerp: Re: [topbraid-users] dublin core prefixes It is quite a common scenario, I am afraid - see dct and dcterms. So printing out a warning each time this is found is probably an overkill (although we do print similar warnings on the Namespaces tab when an owl:Ontology is selected). > I thought maybe a more conceptual best practice like “always use a > recommended prefix” or “always specify a recommended prefix for publishers” > etc. I could imagine a list somewhere of such prefixes. Some are obvious > (xsd, rdf, rdfs, owl) but some are not (dc, skos, geo, gsp etc.). So > especially for the non-obvious ones that are reused that often that deep > imports having alternatives are likely. See http://prefix.cc/ > I was also thinking: isn’t the situation avoidable in case a prefix is really > only locally defined and all imported prefixing stuff is always ignored > somehow. Or is that the case actually? Or do we get an explosion of prefixes > then for the importing ontology? I just know too little about this. When you save a file back to disk it will only use the locally declared prefixes, so imported duplicate prefixes would be ignored. May I ask why this issue affects you? The triples are the same when the file is re-read. Is it for cosmetic reasons? > as long as there are no other consequences (ie when querying etc.) than no > real issue indeed, only a bit strange when one view shows x and at same time > another view shows y The Source Code tab is currently indeed mixing up prefixes because it creates a plain copy of all prefixes without remembering which ones to prefer. I have just changed that behavior for 6.0 though, so that it will prefer the locally defined prefixes over imported ones. Holger -- 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]>. For more options, visit https://groups.google.com/d/optout. -- 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]. For more options, visit https://groups.google.com/d/optout.
