Default Namespace property?

[HolgerKnublauch]

In our platform we have a property xy:defaultNS which stores the suggested default namespace for new resources in a given graph. It is attached to the home resource of the named graph (often an owl:Ontology). It is used whenever the user creates new instances which typically starts with entering the display label, from which the system will derive a suitable URI consisting of the label as local name, and the default namespace.

It would be great if such a property shui:defaultNamespace (datatype xsd:anyURI) could be added.

[VladimirAlexiev]

Something like this is needed, but I think it needs to be generalized, See these for some examples:

• https://platform.ontotext.com/semantic-objects/5.0/soml/objects.html#soml-objects-id-generation
• https://platform.ontotext.com/semantic-objects/5.0/soml/objects.html#id-generation-using-integrated-functions

Let's think about it (inclusion syntax borrowed from above, but I don't claim it's particularly nice):

• For instances, maybe one needs a template and some URI generation functions, eg
  • https://example.org/things/${uuid()}
  • https://example.org/people/${label.urlify()} where urlify() replaces runs of punctuation with a single _
  • ${counter(1)} for "counter, start at 1, increment for each new term" (think PubMed)
  • ${counter(0,5)} for "counter of 5 digits, start at 0, increment for each new term" (think many of the OBO Foundry ontologies)
• For ontologies:
  • shui:defaultNamespace kind of mirrors vann:preferredNamespaceUri?
  • for prop URLs you need a function ${label.lowerCamelCase()} (and in fact this could be default)
  • for class URLs you need a function ${label.UpperCamelCase()} (and in fact this could be default)
  • So the URL template should be attached per node shape, not (only) per graph?

@edmondchuc , @robert-david : is URL formation already discussed for SHACL UI?

[HolgerKnublauch]

Yes, we also support UUID-based generation as well as counters. So basically it's a default namespace (or URI start) and then either

• derive localName from rdfs:label/prefLabel (e.g. "Peter Merz" -> PeterMerz)
• use UUID as localName (making sure it doesn't start with a digit)
• use a Counter and the local name of the class, e.g. Person_1

If we have a defaultNamespace property, then the URI construction method can be another, optional, property. It could perhaps be a node expression, with the display label as the focusNode, and the result of the node expression would be either the localName or the full URI.

Most users would likely just use the defaultNamespace, so we don't need to over-complicate that.

[VladimirAlexiev]

@HolgerKnublauch so you see it as discrete props, without the need for URL template + functions?

Here are particular usecases that I think call for a more flexible approach:

• class "specifically dependent continuant" -> SpecificallyDependentContinuant in an English-based ontology
• class "specifically dependent continuant" -> BFO:0000020 following the OBO tradition (7-digit counter)
• class "pylon"@en, "tragwerk"@de -> Tragwerk in a German-based ontology.
  This is an actual case from Swissgrid. Labels are trilingual but their engineering has standardized on German localnames.
• prop "specifically dependent on" -> specificallyDependentOn
• person with counter -> person/1
  Slash rather than underscore may matter a lot to me!
• person with natural key (PK) 1 -> person/1
  This is very different from a counter: it uses an attribute for part of the URL.
  I use this all the time in CSV conversions: every newly minted URI (counter or UUID) is a liability since you need to track it, and look it up to make a FK (relation)
• "Viktor Orbán" -> ViktorOrban, with accent removal.
  (Scratch that and replace it with PeterMagyar ;-)
• "Ursula von der Layen" -> Ursula_von_der_Layen with underscores instead of CamelCasing

More:

• R2RML and RML support URL templates, and I think SHACL should also
• With some trickery, perhaps the same templates can be used for validation.
  In the first example below, this is more powerful than sh:pattern

@base <https://example.org/data/>.
:id a owl:DatatypeProperty.
:id_PropShape a sh:PropertyShape;
  sh:path :id;
  sh:datatype xsd:string;
  sh:pattern "^\\d+$";
.
:Person a sh:ShapeClass;
  sh:property :id_PropShape;
  sh:uriTemplate "https://example.org/data/person/${id}"; # new, used both for generation and validation
  sh:pattern "^https://example.org/data/person/\\d+$"; # less powerful, redundant
.
:RandomPerson a sh:ShapeClass;
  # no :id needed
  sh:uriTemplate "https://example.org/data/person/${uuid()}"; # new, used both for generation and validation
  sh:pattern "^https://example.org/data/person/[a-z0-9]{4}-[a-z0-9]{6}-...-...$"; # uuid() should know the UUID patterns, so redundant
  sh:flags "i";
.

Holger, sorry to hijack your simple issue shui:defaultNamespace with these more complex features.
@edmondchuc do we have any Usecases collected for "URL generation", or is this a completely new topic?

[HolgerKnublauch]

@VladimirAlexiev I already pointed out that the URI construction policy could be a node expression, so this would give a lot of flexibility. The 3rd example with labels in multiple languages wouldn't quite work because it's unclear how to pass those multiple labels into a node expression.

In any case, this may indeed explode here and if we're getting too ambitious we may end up with nothing at all due to time constraints.

[VladimirAlexiev]

@HolgerKnublauch You are right, adding a template language if node expressions can take care of it is a bad pattern.

Could you show how the above cases can be implemented with node expressions?

• These will be excellent examples of the power of shnex, and tests
• May need extra functions, eg for counter or accent removal (I added an example)

[HolgerKnublauch]

It would be sad if writing such examples requires myself. Exercise for the reader or Graphwise staff? If something isn't clear, let's see where people are stuck so we can improve the Node Expr document.

[edmondchuc]

We had an initial discussion on this topic in last week’s UI meeting. Our thoughts are below.

We like the idea of using shui:defaultNamespace to define the namespace to use when creating new resources. We see this as one of several UI-related configuration use cases, and we would like to explore the idea of a UI configuration object that is linked from either an owl:Ontology or a sh:Specification resource. This configuration object could also include other options for overriding defaults or declaring preferences in SHACL UI-based applications, such as a preferred language. We would also like it to be extensible so that custom implementation-specific configuration can be defined there as well.

Separately, we'd also like to note that DASH provides a dash:stem constraint that could be used as a hint for the default namespace for creating new resources. Perhaps the two ideas could be used together, with dash:stem the namespace at the property level.

@VladimirAlexiev I think generating the local name is a different topic. We haven't discussed yet in the UI group, I'll bring it up this week and see if there's interest in tackling it.

@HolgerKnublauch any thoughts on how we should model the configuration object?

[edmondchuc]

Hmm, I thought I saw sh:Specification proposed somewhere, but can't seem to find it anymore.

[VladimirAlexiev]

• sh:uriPattern: use BASE or CURIEs; tie it up to sh:declare #857 proposes an extension of dash:stem

It can

• use relative URLs or CURIEs
• use regex for the rest if the URL (eg numeric, lowercase ASCII, unicorn alphanumeric...)

[HolgerKnublauch]

@edmondchuc yes a specification class can make sense, esp if these become complex and may want to be shared across graphs.