Wikidata

Property talk:P7844

Latest comment: 2 years ago by MSGJ in topic Property deletion

Documentation

Joconde object type ID
identifier for object types from the Service des Musées de France Joconde authority file
Applicable "stated in" valueJoconde (Q809825)
Data typeExternal identifier
Domainartificial physical object (Q8205328)
Allowed valuesT505-[1-9]\d{1,5}|[0-9a-f]{8}(-[0-9a-f]{4}){3}-[0-9a-f]{12}
Exampleamphora (Q178401) → T505-46 (RDF)
painting (Q3305213) → T505-3343 (RDF)
hoof boot (Q490274) → T505-1651 (RDF)
cauldron (Q1317634) → 9f934015-458d-4ea2-b9e2-dcb3c82fc449 (RDF)
Sourcehttp://data.culture.fr/thesaurus/page/ark:/67717/T505/
Formatter URLhttp://data.culture.fr/thesaurus/page/ark:/67717/$1
http://data.culture.fr/thesaurus/data/ark:/67717/$1
Related to country  France (Q142) (See 638 others)
Lists
Proposal discussionProposal discussion
Current uses
Total754
Main statement749 out of 5,766 (13% complete)99.3% of uses
Qualifier40.5% of uses
Reference10.1% of uses
Search for values
[create Create a translatable help page (preferably in English) for this property to be included here]
 
Type “artificial physical object (Q8205328)”: item must contain property “instance of (P31), subclass of (P279)” with classes “artificial physical object (Q8205328)” or their subclasses (defined using subclass of (P279)). (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P7844#Type Q8205328, SPARQL
 
Format “T505-[1-9]\d{0,3}|[0-9a-f]{8}(-[0-9a-f]{4}){3}-[0-9a-f]{12}”: value must be formatted using this pattern (PCRE syntax). (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P7844#Format, SPARQL
 
Distinct values: this property likely contains a value that is different from all other items. (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P7844#Unique value, SPARQL (every item), SPARQL (by value)
 
Single value: this property generally contains a single value. (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P7844#Single value, SPARQL
 
Allowed entity types are Wikibase item (Q29934200): the property may only be used on a certain entity type (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P7844#Entity types
 
Scope is as main value (Q54828448), as reference (Q54828450): the property must be used by specified way only (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P7844#Scope, SPARQL

regex and formatterUrl exceptions edit

Latest comment: 4 years ago9 comments4 people in discussion

@DannyS712, Christelle Molinié, ArthurPSmith, 99of9, Nikola Tulechki, Crowjane7: We'll be coreferencing Nomenclature for Museum Cataloging (P7749) to Joconde object type ID (P7844) and as part of preparing for this work, I found the following problem: Most concepts match the pattern http://data.culture.fr/thesaurus/resource/ark:/67717/T505-\d but not all.

Either you need to fix the regex and formatterUrl (making them much worse):

Or someone with connections to culture.fr (Sophie Daënens and Jeannette Ivain) should push them to fix the exceptions. I've sent at http://data.culture.fr/thesaurus/contact/ark:/67717/T505, let's see what happens. --Vladimir Alexiev (talk)

  • I got a reply from Jihen LANDOLSI, Cheffe de projet maîtrise d’ouvrage, Programme Harmonisation des Données Culturelles - Référentiels (short quote): "when we create a concept in our software, a persistant identifier in the form of an ark is automatically generated and the one we use seems to respect the best practices which imply, among other things, that the "ark name" must preferably be opaque. changing this reference unfortunately does not seem to be a desirable step. Could you tell me specifically how you are concerned about this difference in ark name?"
    • I replied: Indeed, URLs are supposed to be treated as opaque, i.e. a consumer should use explicit relation triples (eg skos:inScheme) to find all concepts in a thesaurus, and should not slice and dice URLs to infer such relations.
In practice however, the form of URL does matter, in particular when you want to add these URLs to another system (as described below).
"To my knowledge, when we create a concept in our software, a persistant identifier in the form of an ark is automatically generated": All your URLs are ark's, that is not the issue. The issue is whether they use a number prefixed with the thesaurus code (T505-$1) or a GUID (random string).
The Wikidata community wants to add Joconde ID to many WD items. The way the Joconde ID property is defined is as a pure number (eg painting (Q3305213) → 3343), and there is a Formatter URL to map that to your site: http://data.culture.fr/thesaurus/page/ark:/67717/T505-$1 where "$1" is replaced with the number. There is also a regex to validate the value entered, which restricts it to a number.
If you cannot fix the exceptions then we'll have to fix the regex and formatterUrl. This will make them much worse because ANY alphanumeric string can be entered as identifier value, and there will be significant risk that identifiers for your other thesauri (3 of which we also want to map to, and I think have corresponding WD properties) will be mixed with this one.
The only reasons to leave these exceptions would be:
It there is already cultural heritage data that uses the exceptional URLs and there's no easy way to change it to use corrected URLs
If you cannot do it in your TMS (Ginco). Note: if it uses an RDF store, it's easy to fix this with a SPARQL query, I can help.
Are there exceptions in your other thesauri? I haven't checked, sorry.
If you cannot fix the exceptions, perhaps it's better to lump all your thesauri in Wikidata as one property "culture.fr thesaurus id". But this has other disadvantages, including non-uniqueness: in some cases one WD item will have to be mapped to two of your values. --Vladimir Alexiev (talk) 10:38, 21 January 2020 (UTC)Reply
I can confirm there are similar "exceptions" in all thesauri there, not a big surprise as it is built into the tool used to manage them... Sounds a bit rude to ask them to "fix" their own IRIs to match our self proclaimed formatter and id! It is however a bit disturbing they didn't use them for the initial load and thus have an awkward mix.
The easiest way to go from here is probably to just adapt our definition of the properties to accept both kind of values. Another option would be to merge the Joconde thesauri together as they have different scopes (they are similar to the facets of AAT), though we may lose some ability for type checks. I don't think however it would be a good idea to merge with other thesauri as there would be a very large overlap between e.g. Joconde object type ID (P7844) and Thésaurus de la désignation des objets mobiliers ID (P4979). I understood the whole point of the "harmonization" project (HADOC) was to have a unified thesaurus instead of application-specific ones, but until this is done (if it happens one day), I think it's better to keep them separate on our side too. By the way the latter is nicely coreferenced to AAT and DBpedia (as well as BNF's Rameau) on the source but quite messy on our side with a mix of ids with/without the vocabulary prefix (Mix'n'match has them included, while they're in the formatter in the property definition) --Nono314 (talk) 14:06, 22 January 2020 (UTC)Reply
I'm sorry @Vladimir Alexiev, Nono314: for this waste of time. I didn't noticed that there were two different forms of URL before asking for the creation of the new properties. Your proposal to create a unique property "culture.fr thesaurus id" doesn't seem to be a solution for the reason you both mention : a same value is present in several thesauri so that would create a lot of mess until the thesauri are merged (we hope one day maybe). If there is any possibility to allow the two kinds of values I think it would be the best solution, we would be able to continue to work on the alignment pending a more coherent policy from the Ginco managers. Thank you.--Christelle Molinié (talk) 17:30, 22 January 2020 (UTC)Reply
@Christelle Molinié:I hadn't imagined it either, until I stumbled upon it when starting to prepare data for authors on Mix'n'Match... I will be updating the property definitions. --Nono314 (talk) 14:16, 25 January 2020 (UTC)Reply
Thank you very much Nono314 :) This concerns the property requests I made for all the thesauri of the SMF(except "Ecole" which I did not find relevant). Concerning the authors maybe it is possible to retrieve the alignments made for the JocondeLab project as I was recently reminded by Tounoki.

List of Exceptions edit

Here's a list of all exceptions:

Merge now or later, Migrate Id values edit

Latest comment: 4 years ago5 comments3 people in discussion

@Nono314, DannyS712, Christelle Molinié, ArthurPSmith, 99of9, Nikola Tulechki:

I think it's a pity that Ginko cannot allocate sequential ids and generates URIs that dont reflect which culture.fr thesaurus they belong to. There are 20 such thesauri on one page, and it seems Christelle has pointed to 6 more. This is quite messy (I think there are many cases when it's very subjective where a concept belongs to) and I understand why culture.fr is going towards merging them (consider GND which I think is much bigger yet is a single thesaurus).

WD now has 10 culture.fr thesauri but more can be expected soon. Given this URI management by culture.fr and their future merging plans, I think we should merge now rather than later. Maybe just make 3: culture.fr concepts, culture.fr places, culture.fr people.

Nono314, no matter whether we merge or not, all Id values need to be migrated to move the thesaurus code (eg "T69-") into the Id value. Vladimir Alexiev (talk) 12:03, 1 February 2020 (UTC)Reply

@Vladimir Alexiev: sorry didn't get the ping.
Yes, values should be migrated. I did it for the newly created ones from Joconde (a couple values each). It should be done also for the heritage ones which have more usage and are already mixed as Mix'n'match was including the prefix, while the property definition did not.
Actually, I'm wondering whether it's worth at all to link to this mess, especially after the answer Christelle got here from Ginco. Why do they even go public with their thesauri if they're not stable at all? Why would we bother link to them if they can be removed/reorganized anytime soon? What would be the usefulness of such "identifiers" that are in total isolation, not even being used in their public facing applications like POP? When that one replaced the decades old interfaces of the mistral system for Joconde/Merimee/Palissy/... I had hopes it would link into the thesauri and we would be able to cross-check property values in wikidata. However they still use labels in the application, and not even the prefLabel from the thesaurus but various ones depending on who filled the notices!
So I guess I will stay away from these properties for some time, until I find some meaning in what they do... --Nono314 (talk) 12:24, 6 February 2020 (UTC)Reply
Hi Vladimir Alexiev and Nono314 I am disappointed too to discover the extent of the disaster, which is certainly the result of a lack of coordination between the Ginco, Joconde and Pop teams. We have scheduled a telephone meeting in March with the colleagues of the Ginco platform. I will tell them about our difficulties and I will certainly find out more about what they plan to do. Therefore, it's surely better to wait until the context is clarified and stabilized. Of course I'll keep you informed.--Christelle Molinié (talk) 20:25, 6 February 2020 (UTC)Reply
@Christelle Molinié: thanks for keeping communication to culture.fr! It would be great if they participate in these discussions on Wikidata. I think we should migrate the values, adjust the regex and formatterUrls, put a hold on creating new thesauri, and wait re the merging idea, as you propose.

@Nono314: don't be so hard on culture.fr, just because 1 of 30 vocabs is closed for renovations, does not make the others useless or unimportant. The more WD and GLAM link to them, the more important they will be, and culture.fr will get more motivation, justification and maybe even money to do it right. --Vladimir Alexiev (talk) 08:15, 7 February 2020 (UTC)Reply

Hi Vladimir Alexiev and Nono314 here are some news about this project. Shonagon and I had a phone call a few days ago with our colleagues at the french Ministry of Culture. They are very interested about the idea of linking their vocabularies. They are aware of the problem of having different forms for the URI and will make sure to keep it as it is. As long as they don't consider to merge their vocabularies we think that we have to keep the same logic on Wikidata so that we will respect the meaning of each concept. Maybe it's quite weird to have so many properties but we think we don't really have the choice. Good news : they are working on the linking between Ginco and POP, so sooner or later Wikidata will give access to the french national database Joconde. Concerning the thesaurus "Techniques" they are aware that it is not a good practice but it has been requested by the producer of the data...and we are still waiting for the republication...As a first test I've made the alignments for the thesaurus "Domaines" and we have sent them the list of the WD ID so that they will be able to publish it on Ginco if they want. We will inform the french contributors about this project, to carry on the alignments with the others thesauri.--Christelle Molinié (talk) 09:53, 22 April 2020 (UTC)Reply

Property deletion edit

Latest comment: 2 years ago1 comment1 person in discussion

Property was kept, please see Wikidata:Properties for deletion/Joconde — Martin (MSGJ · talk) 21:38, 15 February 2022 (UTC)Reply

Add topic
Retrieved from "https://www.wikidata.org/w/index.php?title=Property_talk:P7844&oldid=1577928599"
Return to "P7844" page.