{:db/id 1234
 :concert/id "x"
 :concert/sound-engineer {:db/id 5678
                          :person/id "johndoe"}}

[1234 :concert/sound-engineer 5678 900000 true]

{:db/ident :concert/sound-engineer
 :db/valueType :db.type/ref
 :db/cardinality :db.cardinality/one}

So "sound engineer" should/could be the attribute ?

Makes sense to me. You could model it the other way around as well, but that feels less natural to me.

What would be "the other way around" ?

Something like :sound-engineer/responsible-engineer or some such. On the person

:person/sound-engineering-concerts

heh, like I said - more awkward

With my first suggestion, you could find all the concerts John Doe has been the sound engineer at with:

(def john-doe (d/entity (d/db conn) [:person/id "johndoe"]))
(:concert/_sound-engineer john-doe)

So specific roles played by persons should/could be represented as the attribute - some might say that roles could/should be the value where the attribute is :role, but then you would need more than single datom to represent the fact I guess..

(Datomic data modeler newbie..)

Yes. This is just one suggestion, a very straight-forward one. If you want more detail then you’d need to represent the role as an entity as well

Do you agree to what is being said here @U09R86PA4?

There are many ways to model this, my suggestion is simplistic. I don’t know at what depth you want/need to model your concerts 🙂

For instance, it is not uncommon for a concert to have more than one sound engineer.

I have plenty of roles associated with the concerts..

You could model “sound engineering” as an entity also:

{:concert/sound-engineer
 {:sound-engineer/person {:person/id "johndoe"}
  :sound-engineer/payment 500}}

{:concert/workers
 [{:concert.worker/person {:person/id "johndoe"}
   :concert.worker/role :concert.role/sound-engineer
   :concert.worker/payment 500}]}

I generally prefer to keep things explicit and not overly generic. So I’d want at least a :concert/sound-engineer (or :concert/sound-engineers ) attribute, even if it points to an entity with role-like information.

Keep in mind that you can also be both specific on some things and at the same time generic on others - and you can mix and match attribute namespaces. For instance, you probably don’t want to model a bunch of :X/payment attributes that are essentially the same, so this is fine:

{:concert/sound-engineer
 {:sound-engineer/get-in "..."
  :concert.worker/person {:person/id "johndoe"}
  :concert.worker/payment 500
  }}

Sorry, I don't use Datomic so I'm a bit unsure what in your code represents what in a Datom..

These are entity maps. You can pass them directly to d/transact and let Datomic break them down into datoms for you. Here’s how it goes:

;; This is the same as
[{:db/id 1234
  :concert/sound-engineer
  {:db/id 5678
   :sound-engineer/get-in "..."
   :concert.worker/person {:db/id 9876
                           :person/id "johndoe"}
   :concert.worker/payment 500
   }}]

;; ...this
[[1234 :concert/sound-engineer 5678]
 [5678 :sound-engineer/get-in "..."]
 [5678 :concert.worker/person 9876]
 [5678 :concert.worker/payment 500]
 [9876 :person/id "johndoe"]]

I would advise you to become intimately familiar with how these shapes relate, it’s essential to understanding Datomic and making good use of it.

Thanks. At the moment I'm working on a triple-based model in FileMaker and taking inspiration from Datomic. What I'm envisioning is a master attribute set that would work across multiple domains and for every system built one would take a subset of that attribute set to model the domain at hand..

> Do you agree to what is being said here @U09R86PA4? yes

The aspect that I'm struggling with is combing 1) declarative roles like "John Doe is a sound engineer", with 2) contextual roles like "John Doe is the sound engineer at Concert X". It appears that "sound engineer" needs to be represented both as an entity and as an attribute, which is confusing to me...

What does it mean to be a sound engineer in "John Doe is a sound engineer"? That he has that skillset? That he has a sound engineering job? Find out what you mean by that and model that. If all you really need to know is that he's a sound engineer at the specific concert, then the above discussion gives plenty answers. You may want to model more sound engineering aspects though.

If you only model that John sound engineers specific concerts, you can use Datomic to answer the question "Is John a sound engineer?" by looking at whether he's every held a sound engineering position.

Not saying that's the only correct way to do it, just throwing it out there as something to consider.

One use of storing the fact "John Doe is a sound engineer" (based on skillset, education or whatever) could be that only persons that have this skillset/education are allowed to use this role at some event like a concert.

Sure. Several options for this as well. {:person/skills #{:skill.music/sound-engineering ,,,}} is a loose tag-like approach, {:person/skills #{{:skill/kind :skill.music/sound-engineering, :skill/blabla ",,,"}}} reifies skills as an entity, etc. Depends on how much detail you need in your system.

Would it make sense to model "sound engineer" both as an attribute and an entity to you ? (I need to better understand the construct of ":skill.music/sound-engineering"..)

:skill.music/sound-engineering is a namespaced keyword. In this context it acts like a "tag" for skills.

"Sound engineering at a concert" and "having a sound engineering skillset" are two distinct pieces of data, so it makes complete sense to model both.

Thanks ALOT for your answers!..

😊

(btw, I've been to concerts where it was evident that they certainly are two distinct pieces of data:wink:..)

Indeed 😂