You’re making things confusing by treating your Request DTOs as an implementation detail that you’re trying to DRY and hide behind multiple classes instead of treating it as its intended purpose as the source of reference for your Services Contract. This makes it harder for anyone who wants to look at your Request DTO to find out what your Services accepts, who have to build a mental model in their head of multiple layers of inheritance with a schema definitions that they can’t see as they’re looking at each of your Request DTOs.
If you’re going to use inheritance I wouldn’t go more than 1-level deep. Trying to split out a base class over multiple base classes makes your API contract unnecessarily confusing whilst yielding very little benefit. Limiting it to 1-level would make things less confusing since the name of your base class would indicate it’s a base Request DTO class. If you only had 1 base class I would call it RequestBase which clearly conveys its purpose. If you multiple Request Base classes I would use a name that describes what the base class is about, e.g. if all Photo Services inherited the same base class you could call it PhotoRequestBase. Calling something CoreRequest just looks like you’re introducing an artificial name with no clear purpose.