The property P2_has_type should generally point to controlled vocabulary values

[rtroncy]

The following query:

select distinct ?o 
where {
  ?s ecrm:P2_has_type ?o 
}

at http://data.silknow.org/sparql yields very worrying results. This needs to be analyzed for each dataset.

[pasqLisena]

select distinct ?g count(?s) as ?count ?o 
where {
  GRAPH ?g {?s ecrm:P2_has_type ?o }
} GROUP BY ?g ?o
ORDER BY desc(count(?s))

• results

Some of them are easy to fix (like "en"@categories => "categories"@en)

[tschleider]

OK, in general maybe we need another discussion on this. The suggested change from @pasqLisena has been applied, and that was indeed a mistake.

Then there are some numbers, this should also be fixed after re-conversion, there was a typo in the code.

For the rest we need to distinguish. First of all it seems to be a problem that there is textual information in some of them. This comes from the fact that I copied @pasqLisena implementation of ecrm:E8_Acquisition from IMATEX and therefore using ecrm:P2_has_type for the acquisition type. And therefore we have values like "purchase - Diputació de Barcelona" in there. I think this is also consistent with the mapping files - or at least it's not 100% clear if we pull the value from the fields or if it is fixed. So i just extended it to other Datasets. I can work on some other solution.

Lastly, we already try to check terms with the Thesaurus, but there just do not seem to be matches. Also, it is only implemented for the method "addClassification" and not for "addObservation" or "addComplexidentifier" or just ".setType". I can change that.

[rtroncy]

For the rest we need to distinguish. First of all it seems to be a problem that there is textual information in some of them. This comes from the fact that I copied @pasqLisena implementation of ecrm:E8_Acquisition from IMATEX and therefore using ecrm:P2_has_type for the acquisition type. And therefore we have values like "purchase - Diputació de Barcelona" in there. I think this is also consistent with the mapping files - or at least it's not 100% clear if we pull the value from the fields or if it is fixed. So i just extended it to other Datasets. I can work on some other solution.

I think we need to see on a case by case basis. For each field that triggers an instance of ecrm:P2_has_type (and for each museum), what is the value you will encounter in order to know if you have to take the value as is or if you have to interpret it.

Lastly, we already try to check terms with the Thesaurus, but there just do not seem to be matches.

Which thesaurus? SILKNOW? AAT? Of course, we are talking here about creating new, typically small, controlled vocabularies so I'm not sure I understand your comment here.

[tschleider]

I think we need to see on a case by case basis. For each field that triggers an instance of ecrm:P2_has_type (and for each museum), what is the value you will encounter in order to know if
you have to take the value as is or if you have to interpret it.

Now that I understand the problem better I will go through the mappings again 1-by-1 and have an exact look if there is more interpretation necessary, maybe regex is enough to split up big text fields.

Other than that I am on the other few errors/bugs, like the thing with the language tags.

Which thesaurus? SILKNOW? AAT? Of course, we are talking here about creating new, typically small, controlled vocabularies so I'm not sure I understand your comment here.

Ok, now it makes sense to me, I just discovered in the code that there is an implementation with String2Vocabulary and the method "addClassification", that as you say makes no sense right now, but we can change it to something more useful once we have created the vocabulary.

[tschleider]

This query gives an overview of where we are standing.

All these huge strings like ["Maria P. James , Norwalk, Connecticut (until d. 1910; bequeathed to MMA)] come from MFA as the mapping suggests to split up the "Provenance" field. I tried unsuccessfully to use regex to extract the type ("Gift") and the direction of the transfer ( " P23_transferred_title_from " ) from this one field, so for the next conversion I can leave that out and it will look less messy for the P2_has_type.

@rtroncy and @pasqLisena : In general I do not know which types should be in this controlled vocabulary and which should not. One way or the other they are all coming from the mappings right now.

[pasqLisena]

So, first of all, everything should go lowercase.

Then, for sure we can firstly attack everything that has >1000 occurrences, trying also to merge multilanguage (e.g. "Description" and "Descripción") under a unique identifier
 

[tschleider]

Thanks, yes, I agree with this, but I thought more about the question of what concepts should be in it and which ones look completely wrong for this property (which means it needs to be left out of this vocabulary and we need to look at the mapping rules).