You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While building a new translator, I noticed that after having mapped "Mali" (as a string) to it's resource for the nationality property, the hxlator did not ask me to map "Mali" again for place of origin. The TTL is correct (it is using the Mali URI for the object of the place of origin predicate).
This is perfectly correct in this case. And for the case of nationality and place of origin the logic would almost always hold. The question is whether or not we want to do that for other properties with Location as an object. I could envision cases where people are displaced from, for example, "Deou" village to "Deou" APL, in which case there would be different URIs for those two properties.
The text was updated successfully, but these errors were encountered:
While building a new translator, I noticed that after having mapped "Mali" (as a string) to it's resource for the nationality property, the hxlator did not ask me to map "Mali" again for place of origin. The TTL is correct (it is using the Mali URI for the object of the place of origin predicate).
This is perfectly correct in this case. And for the case of nationality and place of origin the logic would almost always hold. The question is whether or not we want to do that for other properties with Location as an object. I could envision cases where people are displaced from, for example, "Deou" village to "Deou" APL, in which case there would be different URIs for those two properties.
The text was updated successfully, but these errors were encountered: