| Lucas_Werkmeister_WMDE added a comment. |
Well, adding that test to Wikibase wouldn’t be very useful because any violations are most likely to be caused by extensions adding new entity types. The EntityId class in the Wikibase data model currently enforces a very liberal pattern:
const PATTERN = '/^:?(\w+:)*[^:]+\z/';
That is, any number of repository prefixes, and then anything that doesn’t look like a repository prefix. (\z is an escape sequence matching the end of the string, more or less like $.) Just about the only thing this blocks is consecutive runs of : characters or strings ending in them, as far as I can tell.
In the entity types we have so far (Item, Property, Lexeme, Sense, Form, MediaInfo), entity IDs conform to the pattern of one or more dash-separated components of one letter and a decimal number (I guess that would be [A-Z][1-9][0-9]*(-[A-Z][1-9][0-9])*). If we want the statement ID ⇔ URI conversion to be possible in both directions, perhaps we should think about making this stricter pattern part of the core Wikibase data model?
Side note: @Smalyshev do you know if colons in statement URIs would cause problems? We would currently escape them as dashes, which would make the conversion of statement IDs for foreign entities lossy. (That said, I’m not sure if there’s any situation where such statement IDs would actually occur: in which case would a Wikibase repository emit statements for foreign entities? As far as I’m aware they can only occur as predicates or values, but not as subjects.)
Cc: Smalyshev, Lydia_Pintscher, Liuxinyu970226, Aklapper, Lucas_Werkmeister_WMDE, ArthurPSmith, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
