Add all top-level sweet IRI's to prefix.cc

[lewismc]

We use YASGUI over in the COR. YASGUI uses prefix.cc/ to do namespace lookup for autocompletion when writing SPARQL queries. This is of real use when prototyping query construction... it saves loads of time.

Looking at the all.file.json file., I see that two sweet entries already exist, namely

oper | "http://sweet.jpl.nasa.gov/2.0/mathOperation.owl#"

sciprov | "http://sweetontology.net/reprSciProvenance/"

The second one is fine. At this point we don't need to worry about the first one. We can just disregard it for the time being.

What I would like to ask the community here is as follows... what convention would we like for the prefix?

I think we could basically use the lower case file name. Does this sound OK?

[cmungall]

I assume you want to also register the top level 'sweet' too?

+1 to prefix.cc but I find it can be convenient to distribute the prefix-IRI mappings as actual triples (rather than syntactic headings). It looks like the best vocab for this may be shacl.

We do this for the OBO ones, see:

https://raw.githubusercontent.com/OBOFoundry/OBOFoundry.github.io/master/registry/obo_prefixes.ttl

[lewismc]

This is really helpful @cmungall thank you for that guidance.

[lewismc]

@cmungall do you have any suggestions as to the prefix for each resource? For example, what would you do for the following http://sweetontology.net/humanEnvirStandards/? Thanks

[lewismc]

From Richard Cyganiak

Prefixes can only be added one by one, not in bulk. To add a prefix “abc”, go to prefix.cc/abc and click “Add a URI for this prefix” or “Add alternative URI”. This will only be possible if the prefix meets certain syntactic restrictions that are imposed by prefix.cc, such as a maximum length and absence of punctuation. Mappings added in this way will show up in the file you mention. Note that if a different URI has already been registered for the prefix, then the new URI will have to compete with the old one, that is, it needs sufficient upvotes to be considered the best one for the prefix, or else the old mapping keeps being listed in the file.

[graybeal]

I am not sure you want to create prefixes for all the individual ontologies—the constraints make it a bit dicey. If you do, I would suggest something along the lines of military-style prefixes, HUMENVSTD in your example. There are just so many conflicts that you are unlikely to come up with a good technique that will be brief and recognizable.

Another one to consider is to make them all SWEET branded, so either SWEET-HES or SWEETHES. Then the conflicts will be drastically reduces, and you'll get more recognition out of them.

(Not sure how hyphens play in the world of prefixes, they should be OK but no telling. Could consider SWT but it is probably conflicted and in any case ambiguous.)

[lewismc]

@graybeal

...I am not sure you want to create prefixes for all the individual ontologies

My logic is that if we can use these prefixes in YASGUI (which is used widely these days) then it saves a bunch of time writing SPARQL queries which involve SWEET IRI's.

'military-style' seems to be what they have done over on OBO which works because they are short.

Another one to consider is to make them all SWEET branded

I also thought about this. I was thinking something like so... with the preceding so denoting SWEET Ontology. I'm also not sure how hyphens play but I would rather not chance it. Any more input would be appreciated, thank you John.

[graybeal]

Alas, SO is already taken as an acronym in BioPortal by the Sequence Types and Features Ontology. That wouldn't impact anything starting with SO, as long as it isn't SOY, SOCPRES, or SOPHARM.

I wouldn't say that makes it impossible even for SWEET itself, but it is confusing for users if the acronym in BioPortal doesn't match the acronym everywhere else.

[cmungall]

never thought of as military style, started that was as most are initializations, then became more word-like as the 2 letter ones ran out...

On Wed, Aug 21, 2019 at 11:39 AM Lewis John McGibbney < notifications@github.com> wrote:

@graybeal https://github.com/graybeal

...I am not sure you want to create prefixes for all the individual ontologies

My logic is that if we can use these prefixes in YASGUI (which is used widely these days) then it saves a bunch of time writing SPARQL queries which involve SWEET IRI's.

'military-style' seems to be what they have done over on OBO which works because they are short.

Another one to consider is to make them all SWEET branded

I also thought about this. I was thinking something like so... with the preceding so denoting SWEET Ontology. I'm also not sure how hyphens play but I would rather not chance it. Any more input would be appreciated, thank you John.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ESIPFed/sweet/issues/155?email_source=notifications&email_token=AAAMMOKKLIFH5COXPAQ6J6TQFWDVFA5CNFSM4IMUNS22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD42XBDA#issuecomment-523595916, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAMMONNWRBRKQ4KSZJDOTLQFWDVFANCNFSM4IMUNS2Q .

[lewismc]

The mappings now exist at https://github.com/ESIPFed/sweet/blob/master/sweetPrefixes.ttl I'll go ahead and register these in prefix.cc

[dr-shorthair]

Good luck - using the UI you can only register one ns per day ...

[lewismc]

@ESIPFed/semtech if you have 20 seconds, please select one of the entries below, then head over to prefix.cc and register it. You can only do one per day. Once an IRI and prefix has been registered please remove it from the list below.

list is complete now, thank you to all contributors

[lewismc]

The prefix.cc policy is that they do not accept bulk submissions. We therefore need to work to register these by hand.

[cmungall]

Surely you could just ask for dispensation, email them the mappings, ask them to directly add to their database as a favour, sweet is a major resource, this isn't someone's random never-used vocabulary?

On Wed, Oct 2, 2019 at 11:18 AM Lewis John McGibbney < notifications@github.com> wrote:

The prefix.cc policy is that they do not accept bulk submissions. We therefore need to work to register these by hand.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ESIPFed/sweet/issues/155?email_source=notifications&email_token=AAAMMOLUTAVN5744N3LSIUDQMTQVRA5CNFSM4IMUNS22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAFWGOQ#issuecomment-537617210, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAMMOONQFQR42Z4NYNFHALQMTQVRANCNFSM4IMUNS2Q .

[lewismc]

@cmungall verbatim response

My policy is to refuse bulk submissions. I understand the use case—you want to “own” a chunk of the prefix space, basically everything of the form soxxxx, and manage it in bulk. This is perfectly reasonable, and I wish we were able to do it. But prefix.cc lacks the technical infrastructure. It would require a setup where prefix.cc can delegate responsibility for a certain chunk of prefix space to a third party. In theory I could manually do a bulk import, but then I would feel obliged to do the same the next time someone asks, and then the people whose bulk imports I previously accepted will ask me to do updates... It wouldn't scale. I've only been able to keep prefix.cc running for 10+ years because it's really low maintenance. So my policy for the moment is to say no, until some future redesign that adds the necessary infrastructure.

I do understand the rationale... I suggested that we just crowdsource the task. I don't want to piss anyone off if I'm honest.

[dr-shorthair]

I warned you ;-)

[dr-shorthair]

Registered "sorepsmo" --> "http://sweetontology.net/reprSciModel/"

[dr-shorthair]

But http://cor.esipfed.org/ont?iri=http://sweetontology.net/reprSciModel/ is not returning anything useful ...

[carueda]

Remove the trailing slash so it's the correct IRI: http://cor.esipfed.org/ont?iri=http://sweetontology.net/reprSciModel

[graybeal]

is the implication that the list should remove all the trailing slashes?

[carueda]

No. As a namespace declaration, having the trailing slash is fine. But the resolution of corresponding ontology should be through its proper IRI.

[lewismc]

Thanks for clarifying Carlos.

[brandonnodnarb]

added "sweet" --> "http://sweetontology.net/"

(started from the bottom)

[carueda]

I'm just curious about this, why not simply register the "sweet" --> "http://sweetontology.net/" namespace (already done by Brandon)? .... anyway, just a super quick reaction.

[smrgeoinfo]

added ,[ sh:prefix "sohuea" ; sh:namespace "http://sweetontology.net/humanEnvirAssessment/"] and removed from list

[lewismc]

@carueda I thought about this... and I suppose it comes down to a user experience. Are people more likely to remember and then want to type sohuj:xyz or sweet:humanJurisdiction/xyz? I would say the former. The context for this is provided at https://github.com/ESIPFed/sweet/pull/157

[graybeal]

I think the goal is to be able to refer to specific sub-ontologies in imports and other contexts. So if you routinely use humanJurisdiction and two others, you'll have a set of short namespaces for those that you can define at top of your files and then use sohuj everywhere. So, more usability for the content developers, and a certain amount of 'branding' for the ontologies.

[brandonnodnarb]

added "sostv" --> "http://sweetontology.net/stateVisibility/"

[brandonnodnarb]

added "sosttg" --> "http://sweetontology.net/stateTimeGeologic/"

[dr-shorthair]

sosttf --> http://sweetontology.net/stateTimeFrequency/

[brandonnodnarb]

sosttc --> http://sweetontology.net/stateTimeCycle/

[brandonnodnarb]

sostti -- > http://sweetontology.net/stateTime/

[brandonnodnarb]

sostth --> http://sweetontology.net/stateThermodynamic/

[brandonnodnarb]

I have been able to add more than one entry using Tor. It should be possible to programmatically use the Tor controller to renew the IP address/credentials before each add request.

I don't have the cycles to look into this tonight, but thought it worth leaving here as ninja bait :)

[brandonnodnarb]

sostsy --> http://sweetontology.net/stateSystem/

[smrgeoinfo]

,[ sh:prefix "sohutr" ; sh:namespace "http://sweetontology.net/humanTechReadiness/"]

[carueda]

Are people more likely to remember and then want to type sohuj:xyz or sweet:humanJurisdiction/xyz? I would say the former.

And I would say the latter, but that's just IMHO ;)

[dr-shorthair]

Well, since sweet: --> http://sweetontology.net/ is registered, they can do either! Prefixes are not canonical, they are convenient shorthands for people typing text.

[graybeal]

I tend to agree with you @carueda . But thought we should try Lewis' approach to see how it would go.

@dr-shorthair many people consider prefix-cc to be canonical. As problematic as that might be…

@brandonnodnarb Do you have to re-establish the Tor network each time you want to generate a new prefix? Doesn't it just keep track of your login?!

[graybeal]

Added sorea -> http://sweetontology.net/realm/

Couldn't figure out the Tor magic to let me add another.

[brandonnodnarb]

added sostsl --> http://sweetontology.net/stateSpectralLine/

[brandonnodnarb]

added sostsb --> http://sweetontology.net/stateSpectralBand/

[brandonnodnarb]

added sostss --> http://sweetontology.net/stateSpaceScale/

[brandonnodnarb]

@graybeal --- manually, from a browser (TorBrowser), the command for a new identy is accessed via the menu, or with ctrl + shift + U (default config). I believe this refreshes the browser and rerouts the connections in the relay (instead of stop/start), but the crucial bit is procuring a new IP addy.

It's still manual, but it's something.

I'll have a look at scripting it out, but it may be more trouble than it's worth (for me at least).

[brandonnodnarb]

added sostsc --> http://sweetontology.net/stateSpaceConfiguration/

[brandonnodnarb]

added sostsp --> http://sweetontology.net/stateSpace/

[brandonnodnarb]

added sophg --> http://sweetontology.net/phenGeol/ sophgf --> http://sweetontology.net/phenGeolFault/ sophgg --> http://sweetontology.net/phenGeolGeomorphology/ sophgs --> http://sweetontology.net/phenGeolSeismicity/ sophgt --> http://sweetontology.net/phenGeolTectonic/ sophgv --> http://sweetontology.net/phenGeolVolcano/ sophhe --> http://sweetontology.net/phenHelio/ sophhy --> http://sweetontology.net/phenHydro/

[brandonnodnarb]

added soreaer --> http://sweetontology.net/realmEarthReference/ soreahb --> http://sweetontology.net/realmHydroBody/ soreala --> http://sweetontology.net/realmLandAeolian/ sorealc --> http://sweetontology.net/realmLandCoastal/ sorealf --> http://sweetontology.net/realmLandFluvial/ sorealg --> http://sweetontology.net/realmLandGlacial/ sorealo --> http://sweetontology.net/realmLandOrographic/ sorealp --> http://sweetontology.net/realmLandProtected/ sorealt --> http://sweetontology.net/realmLandTectonic/ sorealv --> http://sweetontology.net/realmLandVolcanic/ soreal --> http://sweetontology.net/realmLandform/

[brandonnodnarb]

added the remaining state files sost --> http://sweetontology.net/state/ sostb --> http://sweetontology.net/stateBiological/ sostc --> http://sweetontology.net/stateChemical/ sostdp --> http://sweetontology.net/stateDataProcessing/ sostef --> http://sweetontology.net/stateEnergyFlux/ sostf --> http://sweetontology.net/stateFluid/ sosto --> http://sweetontology.net/stateOrdinal/ sostp --> http://sweetontology.net/statePhysical/ sostre --> http://sweetontology.net/stateRealm/ sostro --> http://sweetontology.net/stateRole/ sostrb --> http://sweetontology.net/stateRoleBiological/ sostrc --> http://sweetontology.net/stateRoleChemical/ sostrg --> http://sweetontology.net/stateRoleGeographic/ sostri --> http://sweetontology.net/stateRoleImpact/ sostrr --> http://sweetontology.net/stateRoleRepresentative/ sostrt --> http://sweetontology.net/stateRoleTrust/ sostso --> http://sweetontology.net/stateSolid/

[brandonnodnarb]

there is prefix collision for sorepsc (internal to SWEET, not global) sorepsc is listed as a NS for http://sweetontology.net/reprSciComponent/ as well as http://sweetontology.net/reprSpaceCoordinate/

I have registered 'sorepsc --> http://sweetontology.net/reprSciComponent/' and amended the latter to 'sorepscd --> http://sweetontology.net/reprSpaceCoordinate/`

This change will need to be reflected in https://github.com/ESIPFed/sweet/blob/master/sweetPrefixes.ttl

---edit--- addressed in PR #160

[brandonnodnarb]

added repr files (please note previous comment for ns amendment) sorep --> http://sweetontology.net/repr/ sorepdf --> http://sweetontology.net/reprDataFormat/ sorepdm --> http://sweetontology.net/reprDataModel/ sorepdp --> http://sweetontology.net/reprDataProduct/ sorepds --> http://sweetontology.net/reprDataService/ sorepdsa --> http://sweetontology.net/reprDataServiceAnalysis/ sorepdsg --> http://sweetontology.net/reprDataServiceGeospatial/ sorepdsr --> http://sweetontology.net/reprDataServiceReduction/ sorepdsv --> http://sweetontology.net/reprDataServiceValidation/ sorepm --> http://sweetontology.net/reprMath/ sorepmf --> http://sweetontology.net/reprMathFunction/ sorepmfo --> http://sweetontology.net/reprMathFunctionOrthogonal/ sorepmg --> http://sweetontology.net/reprMathGraph/ sorepmo --> http://sweetontology.net/reprMathOperation/ sorepmso --> http://sweetontology.net/reprMathSolution/ sorepmst --> http://sweetontology.net/reprMathStatistics/ sorepsc --> http://sweetontology.net/reprSciComponent/ sorepsf --> http://sweetontology.net/reprSciFunction/ sorepsl --> http://sweetontology.net/reprSciLaw/ sorepsme --> http://sweetontology.net/reprSciMethodology/ sorepsp --> http://sweetontology.net/reprSciProvenance/ sorepsu --> http://sweetontology.net/reprSciUnits/ soreps --> http://sweetontology.net/reprSpace/ sorepscd --> http://sweetontology.net/reprSpaceCoordinate/ sorepsd --> http://sweetontology.net/reprSpaceDirection/ sorepsg --> http://sweetontology.net/reprSpaceGeometry/ sorepsg3 --> http://sweetontology.net/reprSpaceGeometry3D/ sorepsrs --> http://sweetontology.net/reprSpaceReferenceSystem/ sorept --> http://sweetontology.net/reprTime/ soreptd --> http://sweetontology.net/reprTimeDay/ sorepts --> http://sweetontology.net/reprTimeSeason/