Submit your DefinedNamespaces

[nicholascar]

As of rdflib 6.0.0, we have DefinedNamespaces which contain the elements of a namespace (ontology/vocabulary/profile etc) and make them available for type hinting and warning-based validation.

If people would like to create DefinedNamespaces for interesting/important/their favourite namespaces, we can include them in rdflib's rdflib.namespace package. This will make your namesapces more visible and less prone to error in use.

If you are interested, have a look at those already there and put a PR in to add yours.

[dwinston]

I would be interested in a DefinedNamespace for QUDT. @nicholascar you mentioned on the rdflib-dev list that you are on the Tech Advisory Board of QUDT, so I presume you would be interested in this inclusion as well. Are you planning to do this soon-ish anyway? I don't have much free time to start a PR at the moment, but I can see myself attempting one at some point. It is quite a large namespace / set of namespaces, but I would find its inclusion highly useful!

[dwinston]

Also, uhh...I'm seeing a default "If you're seeing this, you've successfully installed Tomcat. Congratulations!" page at qudt.org right now, so to be clear, I mean this: https://lov.linkeddata.es/dataset/lov/vocabs/qudt, or equivalently, the family of qudt*.ttl files I have stashed here.

[nicholascar]

Looks like QUDT is back now! I suspect they updated their server to the latest version of TopQuadrant's EDG and there was just a momentary boo boo while they did.

I would be interested in a DefinedNamespace for QUDT. @nicholascar you mentioned on the rdflib-dev list that you are on the Tech Advisory Board of QUDT, so I presume you would be interested in this inclusion as well.

Great, yes I and and yes I am! Silly I didn't think of that namespace before...

We have used a script to auto-process ontologies into DefinedNamespace but in this case there are multiple QUDT files so it might be easier just to SPARQL query them. I'll have a go.

[westurner]

I share the same concerns about inlining vocabs into rdflib core; even for autocompletion in an IDE.

• REF: DefinedNamespaces SHOULD/MUST be versioned. Vocabs do change and it'll be super annoying when there's only the old version in rdflib and there is no nam_esp_ace version in the import expression so everything has to be REFactored.
• PERF: How much slower is it to import this at runtime than to just fail at typing the correct URLs in the source?

[nicholascar]

Hi @westurner yes, there are concerns here, I don't mean to indicate there are not! We've been a bit lucky with easy - pretty static - namespaces to date. But it's really helpful to have the ability to have more out of the box in some form, even if we have to do more thinking than we've done so far to represent them well.

Agree with the versioning, not sure how to represent all the concerns perhaps. Some issues are dealt with I think:

• if there's an old version of a vocab you want in there, put in a PR to update it
• you can still now, with DefinedNamespace, use a namespace term not in the list, you just won't be IDE prompted for it and you'll get a warning, not an error
  • this is why DefinedNamespace was implemented to replace/extend ClosedNamespace. ClosedNamespace will error on a non-existing term

So you won't be prevented from using terms not in an RDFlib namespace, just not assisted until someone updated the DefinedNamespace. I did this for PROV and XSD recently: the copies we had missed some terms. In both cases it was because those namespaces are compounded from multiple sources, i.e. not just one ontology/vocabulary.

[westurner]

How should versions be represented? IMHO, now would be the best time to:

• rename
• nest things under a per-version module
• ask everybody what a good way to version vocabs independent of the rdflib version would be?
  • should there be an rdflib_vocabs v2021.8.24 package that depends upon e.g. rdflib.vocabs.qudt >= 1.1, rdflib.vocabs._name == 1.0?

While we often hope that vocab changes are only additive, there are non-additive vocab modifications that will result in mismatch between the DefinedNamespace and the vocab. Which - as you point out - only really affects IDEs.

It may be infeasible to also do e.g. SHACL data validation with these DefinedNamespaces? Is there functional overlap where the will already be some maintenance burden?

If google/schemarama (mentioned in the linked gdoc) does not support dynamic forms-based validations, what would it take to support such an essential data data quality use case?

In regards to interactive data validation as a primary use case,
What are these for:
https://github.com/google/schema-dts

[westurner]

I did this for PROV and XSD recently: the copies we had missed some terms. In both cases it was because those namespaces are compounded from multiple sources, i.e. not just one ontology/vocabulary.

Is there already a way to e.g. generate the DefinedNamespace of each version of a vocab and diff?

[white-gecko]

As already pointed out on ths list I also have some doubt about including a set of defined namespaces directly into the RDFlib. Vocabularies and their terms evolve over time. This would bring in problems when we include the vocabularies as they are in the rdflib releases.

• I would suggest to separate the vocabularies from the rdflib package
• and the DefinedNamespaces should be directly generate from the vocabularies, e.g. based on https://archivo.dbpedia.org/ (which also has some concept of semantic versioning for vocabs; https://dx.doi.org/10.1007/978-3-030-59833-4_2)

We have used a script to auto-process ontologies into DefinedNamespace (@nicholascar )

Do you have this script or can you point me to it?

[nicholascar]

@edmondchuc can you please point to the script you used to make the recent DefinedNamespace instances?

[ajnelson-nist]

On how to represent vocabulary versions - would it be reasonable to require a DefinedNamespace import only owl:Ontology definitions that designate a owl:versionIRI?

[westurner]

How many of e.g. these do not (yet) depend upon OWL and so thus do not yet specify the version within the {RDFS vocabulary, or OWL ontology}? - https://lov.linkeddata.es/dataset/lov/ - https://github.com/w3c/json-ld-rc JSON-LD Recommended Context https://w3c.github.io/json-ld-rc/context.jsonld Shouldn't vocabs (with e.g. a SemVer, CalVer versions) be signed with a DID and ld-signatures?

…

On Tue, Sep 28, 2021, 16:46 Alex Nelson ***@***.***> wrote: On how to represent vocabulary versions - would it be reasonable to require a DefinedNamespace import only owl:Ontology definitions that designate a owl:versionIRI? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1415 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMNS7UEK52CD2PFOJ6IALUEISQTANCNFSM5EIR5NSQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[nicholascar]

On how to represent vocabulary versions - would it be reasonable to require a DefinedNamespace import only owl:Ontology definitions that designate a owl:versionIRI?

I don't think we could do that. We shouldn't force rdflib users to commit to an OWL property, given that rdflib is RDF general purpose. Users might have a namespace that would be a fine DefinedNamespace but doesn't use any OWL.

[nicholascar]

The DefinedNamespace generator script that was used for rdflib 6.0.0 is here: https://github.com/hsolbrig/definednamespace/

We could develop a DefinedNamespace repository with GitHub Actions or similar to processor inputs - vocabs and ontologies - into DefinedNamespaces.

Following on from my previous comment: I think we should impose essentially no requirements on users of a repo that automatically makes DefinedNamespaces, however we could certainly encourage owl:versionIRI and other ontology annotation properties.