E22_Man-Made_Object image URIs mapped as P138i_has_representation/E51_Contact_Point/rdfs:label

[cbutcosk]

In the NPG set, URIs for images of E22_Man-Made_Objects are currently mapped as:

_:object a crm:E22_Man-Made_Object;
     crm:P138i_has_representation _:object:url .

_:object:url a E51_Contact_Point;
     crm:P2_has_type _:thesaurus:url;
     rdfs:label "http://foo.bar/image.jpg";
     rdfs:label "http://foo.bar/url_to_object_in_collection_page/";

_:thesaurus:url a E55_Type;
     rdfs:label "URL"

Is this weird from a usability perspective? It means SPARQL results can't return URIs from queries without an explicit cast, Pubby and other open-source result tools aren't aware that those results are URIs, etc. Also it does not distinguish semantically between these two different kinds of contact point (a JPEG and an HTML/CSS page).

An alternate approach might be to map images as:

_:object a crm:E22_Man-Made_Object;
     crm:P138i_has_representation <http://foo.bar/image.jpg>.

<http://foo.bar/image.jpg> a crm:E51_Contact_Point;
   rdfs:label "http://foo.bar/image.jpg";
  crm:P2_has_type _:thesaurus:term_for_URL.

_:thesaurus:term_for_URL a crm:E55_Type2;
   rdfs:label "URL";

And to do a similar mapping for the HTML/CSS pages (to a different thesaurus term indicating the kind of resource it points to). But perhaps I'm missing something as to why that wouldn't make sense, or some magic SPARQL to ensure the E51_ContactPoint -> URI cast?

[workergnome]

Yeah...That's a bizarre CIDOC-CRM thing (that I disagree with). Because the CRM is designed in a self-contained universe where nothing else exists except strings and numbers, they've decided that URLs are a 'type of address'. http://www.cidoc-crm.org/html/5.0.4/cidoc-crm.html#_Toc310250760

Which means that if you were going to follow that logic and scope note, all URLs would need to be contact points for the institution, which makes no sense at all.

That being said, you can't use "has_representation" to map to a contact point, so the given mapping is invalid.

The pattern I recommend for images is:

?entity_uri a crm:E22_Man-Made_Object ;
  crm:P138i_has_representation _:image .

_:image a crm:E38_Image ;
  rdfs:label ?description ;                                                 # optional
  crm:P67i_is_referred_to_by _:rights_statement_class ;   # optional
  crm:P104_is_subject_to _:right .                                   # optional

_:right a crm:E30_Right ;
  owl:sameAs ?right .

_:rights_statement_class a crm:E33_Linguistic_Object ;
  crm:P2_has_type <http://vocab.getty.edu/aat/300055547> ;
  owl:sameAs ?rights_statement_class ;
  rdf:value ?rights_statement .

In this, _:image would be the actual URL of the JPG. That's the pattern currently used by the British Museum, YCBA, and SAAM, and I don't see any reason to change from that.

For webpages, I've suggested

?entity_uri a crm:E22_Man-Made_Object ;
  foaf:homepage ?website_url .

?website_url rdfs:label ?website_label.    #optional

for the main webpage about an object, and foaf:page for other websites about the object.

[cbutcosk]

Ah, that's a good pragmatic solution--I have no love (esp. from a query compexity perspective) for the additional indirection of E51_Contact_Point. Would the E38_Image then carry a predicate (rdf:type? crm:P2_Type?) to indicate if the URL supports IIIF? Is an IIIF identifier an E38_Image?

Is it going to be possible to amend these already mapped datasets? It looks like the recent Autry mapping follows something like the pattern you suggest, but PUAM and NPG do not.

[workergnome]

I believe the PUAM and NPG will be remapped to follow this.

We haven't done a IIIF marker yet—When YCBA does this (and @edgartdata can jump in if I'm misrepresenting), they also consider it a depiction. I'd use something like dc:format to indicate that it supports IIIF, but I don't think that's a settled decision yet. I know @szeke is working on a mapping for IIIF, and I'm sure @azaroth42 will have opinions about that, too.

[cbutcosk]

👍🏼

Happily your response made me realize that the YCBA represents IIIF URIs w/ dcterms:conformsTo predicates. The broader IIIF tagging question seems like it's beyond the scope of the NPG data in particular, so I'll close this.