Daniel Sissman

I think "carried_by" should actually be "is_about" which is more in the range of a Propositional Object rather than a Symbolic Object.

Gregg Garcia

One other thing I see... can we make the body of the relationship go from the HMO LOD record instead of the TMS ID?  This means I can make a query of things that relate to the LOD Object really easily.

Adam Brin

Certainly, this could be changed. As a question, should we not be making the `body` -> `id` property point to the LOD record in all cases? (There is a separate lookup between TMS ID and LOD URL) – it seems like for our LOD purposes, that the LOD URL is the canonical ID for the resource?

Also to comment on Gregg's note, yes, it makes more sense to use the "aboutness" relationship, so that will be changed in the Transform to use the `DigitalObject` entity's `about` property (`crm:P129_is_about`).

To me -- it seems like most of the links in the IDM should go to the LOD URL, but I think that's because I don't use anything that touches the L1 data.  Gregg-- do we have a convention here about what to link to when? Should we?

I would say in this case it should be the LOD URL. As Daniel notes, we have other lookups that connect source system IDs to LOD, but as a convention, it depends upon the purpose. In this case, the purpose is to connect together resources in our LOD infrastructure rather than trying to trace that connection back to the source system.

Happy to adjust the mappings we have setup in IDM currently to mostly use the LOD URL as the body.id (there will always be a TMS ID -> LOD URL entry as well to facilitate that use-case); if I was to make this adjustment, what impact would it have on your systems Adam? How are you making use of the existing IDM lookups and which are you using to know which we can safely change, or should the LOD URL body.id links be added alongside what we have now?

@Daniel -- we don't use the IDM for anything except for the slugs at this points, and we create those, so I think we're good if you just make the change.

Thanks, I will go ahead and make this change as part of the 1.2.1 update.

I like this. The different audio files in different languages would be listed under the "digitally_carried_by" property which represents the actual content.

If I'm understanding this fully -- would that mean that all 13 of the translations are part of a single LOD record?  (a) is that ok? (b) if so, perhaps we should move the filename and other important identifiers down into the LinguisticObject?

Yes, I think having the 13 translations in a single LOD record is the proper way to model it. You can think of it as 13 renditions of the same conceptual content.
Yes, you are probably right that any information that specifically identifies aspects of the audio file itself should go in the Digital Object of the access point itself.

My question is, should we get rid of the top level Digital Object and just go with the Linguistic Object itself? Daniel, what did Rod say about that?

To follow up on Adam's questions, yes I think it is ok, and actually I think it is helpful as this way we can semantically group the various translations of the same content rather than having to keep track of them across disparate records. The LOD record to represent them all will be fairly small, so I don't think it is a data volume issue, and seems a far more practical approach than creating the myriad individual records we would otherwise need to and the correspondingly large number of dereferences that would be involved with the latter approach.

I am still researching the best top-level entity type. I think Gregg's suggestion of using `LinguisticObject` is the right one, and has some additional benefits. See the third version of the example Media LOD Gateway record below which is able to take advantage of the `LinguisticObject` entity type's `translated` property, which appears to be the most semantically correct property for the meaning we are trying to convey.

Furthermore, yes, any audio file-specific metadata will be moved down to that level of the record if it has not already happened. I will make sure the modeling and transform reflects this consistently.

Daniel, this looks really nice! Much easier to work with too!

Yes, I think we are all happy with this version. Thanks, Daniel!

Thank you for the feedback. I will get this version implemented. For cases when there is just one version of an audio (which will almost certainly be in English), I assume it is fine for the `translated` property to contain just the one entry? The rest of the structure would be the same, and the entry would still carry the language classifier, even if it is the only version.

I haven't heard back from Rob yet on this, and I know its more of an ask to have him review a whole document and modeling pattern when he is so busy than to just answer a few quick questions. Having studied the entity types we have available in CRM/Linked.art and their corresponding properties and based on the feedback we have received, I think this is a sensible option that gets us to where we want to be in a semantically sound way.

Yep, using the single entry will keep it consistent.