Fork me on GitHub
#rdf
<
2022-05-01
>
apbleonard22:05:18

In an existential funk trying to think through the idea of decorating our existing inter microservice JSON API payloads with JSON-LD to translate from the ad hoc property names we've built up to a "better" "more carefully defined" set of names whose namespaces reflect bounded contexts and everything is amazing, for consumption by top level integrators that mix data from all wings of the business. That line of thinking led me to look for guidelines on how RDF properties should be named - which led me to these http://www-sop.inria.fr/acacia/personnel/phmartin/RDF/conventions.html#reversingRelations. There seems to be a lot of handy tips and unwritten rules in here that help constrain the wide open spaces of creativity we typically leave ourselves when it comes to property naming. Section 1.2 "Singular nouns for names whenever possible" is particularly enlightening to me. Are these conventions captured anywhere else - in a standard or a book, RDF related or otherwise? Would be a nice reference to have :)

1
Ivan09:05:32

that was as mouthful! 😄 thanks for posting this, seems interesting. Semi-related, "https://elementsofclojure.com/" by Tellman has a chapter on naming - a more philosophical approach to one of the hardest problems in computer science.

apbleonard11:05:31

Yes I have that one in hard copy :) Zach Tellman doesn't go as far as Martin to suggest suffixing with "of" for inverse relations and using nouns like "owner" and not "hasOwner" for properties, to be interpreted as "entity X has for property Y value Z", which I've never seen before. He does say "when naming functions which only transform data only use nouns wherever possible," which always surprised me, but perhaps is in keeping with the thought here. Hide how you are generating the new property and just name the transformation after the new property itself - again an unadulterated noun.