The Law of Demeter focuses on man-in-the-middle code that is written for that express purpose, i.e.:
The purpose of this code is for the consumer (layer 0) to call the product class (layer 1) to access the owner data (layer 2). It's creating a bridge from layer 0 to layer 2, and that is the issue.
The fundamental notion is that a given object should assume as little as possible about the structure or properties of anything else (including its subcomponents), in accordance with the principle of "information hiding".
When you write a method such as
Product.getOwnerName() you are making these forbidden assumptions, because
Product is now assuming/requiring
Owner to have a
Name property. Therefore, if you want to change the
Owner class structure, you're stuck also having to change the
Product class accordingly, and that's bad practice.
Essentially, by not assuming anything about its subcomponents, the product should basically have a method/property which says "here's my related owner object. I don't care what its internal structure is". In other words, you simply return the owner object itself, not its internal contents directly.
You're worried about the template accessing the owner (which is 2 layers removed), but you're trying to fix it by creating
Product.getOwnerName() which connects the product with the owner's name, which is also 2 layers removed. You're actually violating LOD in trying to not violate it in another place.
The Law of Demeter does not care about chained method/property calls when each call only drills one level deep, i.e.:
The product returns the owner, and the owner returns the name/address. Each action is a single level.
The correct way to create your template is
There is nothing inherently wrong with having the owner object as a separately fetched object (as per your suggested solution), but you're not required to do this (for LOD). Neither version violates LOD, you don't need to avoid violations here.