Is it possible to make the RDAU vocabulary less opaque?

[pgwillia]

Is it possible to make the RDAU vocabulary less opaque? ::RDF::Vocab::RDAU['/P60550'] isn't obvious what you're reasoning about in code while ::RDF::Vocab::RDAU.extent would be much better. That value is available from the triple containing "http://metadataregistry.org/uri/profile/regap/lexicalAlias". I noticed that other vocabularies are using LD patch. I'm not familiar with this (can someone suggest a good resource to learn about how it works?). Would this be a possible route to change the property names for the RDAU vocabulary?

https://github.com/ruby-rdf/rdf-vocab/blob/78f32edeeb899a2b3e8c301de759ffe4e4d23dca/lib/rdf/vocab/rdau.rb#L4723-L4729

For context

Q. Why are the IRIs unreadable?

After a great deal of discussion, the JSC (predecessor of the RDA Steering Committee) decided to use opaque IRIs for the element sets. This follows the practice established for the value vocabularies, and reflects the international environment of RDA and its translations. The RSC is also aware of the problems associated with using transparent, human-readable IRIs as a mnemonic device, especially when the properties and values of bibliographic display labels may be further developed. However, English-readable IRIs have been declared owl:sameAs to their canonical, opaque counterparts to alleviate any inconvenience this might cause for English-based linked data applications. The same facility may be developed for other languages, based on translations of RDA, in the future. The mnemonic accuracy of these IRIs is not guaranteed. http://www.rdaregistry.info/rgFAQ#faq3

[gkellogg]

Looking at it, the vocabulary namespace should be updated from http://rdaregistry.info/Elements/u to http://rdaregistry.info/Elements/u/, which could create entries such as property: "P60550", which is at least better than requiring a leading /.

The vocabulary serializer does not have a way to create alias properties right now, as RDF::Vocab::RDAU.P60550 is directly related to the PName rdau:P60550 which expands to the IRI http://rdaregistry.info/Elements/u/P60550. This level of opacity seems to be a particular design goal of the creators, as you cite above.

What you would seem to be requesting is a means of using, say, RDF::Vocab::RDAU.extent (fromrdau:extent.en), and I'm not sure what mechanism might make this happen or if it is really desirable, generally speaking.

As for LD Patch, it uses a gem (ld-patch) which is an implementation of the Linked Data Patch Format. It's use in this gem is to correct errors in the source vocabularies which are caught through semantic analysis. Typically, I try to give feedback to the maintainers of those vocabularies, but often there is no response or update, thus the patches. It wouldn't be appropriate to "patch" a vocabulary in a way that was inconsistent with the vocabulary, itself.

Another gem might implement some other alias method, which could use other properties of a vocabulary, such as rdfs:label, dc:name, skos:prefName or others to return the relevant vocabulary entry, but nothing standardized has been implemented to do this. Something like that could be used to allow a lookup from "extent.en" or http://rdaregistry.info/Elements/u/extent.en to get to the associated term, but as it is, `RDAU[:'extent.au'] would be considered an invalid term in a strict vocabulary.

Alternatively, we could consider a mechanism to add something like an alias class property for RDF::Vocabulary, which would allow to create terms that are aliases of other terms, but I'm not sure how this would be done generically, or if there are other vocabularies which would benefit from this.

You could also do this via a query, to find terms which have that relationship, and wrap that in your own accessor. For example:

def lexicalAlias(alias)
  RDF::Vocab::RDAU.properties.detect {|p| p.properties[:'http://metadataregistry.org/uri/profile/r
egap/lexicalAlias'] == RDF::Vocab::RDAU.to_uri.join(alias)}
end

In the mean time, I'll update the base URI for the vocabulary. I'm expecting to put out a new release after schema.org v12 is released.

[pgwillia]

@gkellogg Thanks for thinking about this and the information about LD Patch and some things to try. I appreciate it.