smorrison
commented
3 years ago From the DBL perspective, we use the PT identifier for text projects and then try to shoehorn everything else into a similar format so that the identifiers are structurally similar (because our schema was written to assume that the PT identifier was the one true way of identifying projects). I don't see a need to add a DBL identifier to existing entries.
One use case that came to mind is that entries that DBL transforms (eg. format translation, filtering for licensing terms) could be identified via a distinct DBL identifier + a relationship to the entry that it's based on. But this is assuming that the transformed entry is a new thing, not a variant of an existing thing.
It seems to me that it would be more transparent to represent an entry that's been transformed as the original thing, plus a series of transformation steps applied (via recipe).
jag3773
jtauber
Our system allows multiple identifiers for the same resource in a burrito. If two systems have created identifiers, and the associated resources differ, how do we handle that? If they do not differ, why not simply use the original identifier in my system, regardless of the system that created it? What are the semantics of multiple identifiers, and what are the use cases?
We also allow a burrito to identify its source, say it is a variant, and say how it is different. That's a clear use case with clear semantics. I would like to see clear use cases and clear semantics for multiple identifiers for a given resource. If we don't have these, we might consider dropping this feature. They may well exist, but Sean and I were not able to think of good ones as we met today.