Label for the organization that has the logo

[azaroth42]

The Presentation API has a logo property, with the definition in 2.1:

A small image that represents an individual or organization associated with the resource it is attached to. This could be the logo of the owning or hosting institution.

And almost identical in 3.0.

So there is the capability to associate a logo of an actor, but not even a label for the actor that has the logo. The label of the logo would be "Logo of X" not just "X". The attribution/requiredStatement might not be for the institution that has the logo, e.g. the requiredStatement could say "Purchased with the generous donation of J Smith." whereas the logo is for the museum. Further, the cardinality of logo is 1-many, from the discussion in #664. Even if there were multiple institutionLabels and multiple logos, you still couldn't link them together.

The logo is at the same level of presentation as summary and thumbnail -- when the manifest is being summarized in a list, such as a Collection or a search results list. This is implemented in Mirador (for example) in the "loading window" via a method that's not based on the specifications. It is useful in any context when the resource is used outside of the responsible institution's context. This would include any search/discovery environment, of which the Mirador load window is a preconfigured microcosm.

Given that the only use of logo can be for an institution, it seems a very small step to actually instantiate the identity of that institution in the data.

This is the right time to discuss, as it would be a breaking change for both Presentation and Image. It does not add significant complexity, while solving several use cases from discovery and adding accessibility to the intended use of the existing logo property. The requirement came up in the Discovery TSG on 2018-07-11 with several use cases being described.

Proposal (from Rob, not Discovery TSG):

Where ever we currently use logo, instead replace with a property that references a Person or Organization, which in turn has id, type, label, and logo. It would have the same semantics as logo does currently -- an individual or organization associated with the resource.

[tomcrane]

What would the id and type be?

"xxx" : [ {
   "id": "https://bl.uk",
   "type": "Agent",
   "label": "The British Library",
   "logo": [
      { 
          "id": "https://bl.uk/img/logo.jpg", 
          "type": "Image" 
      }
   ]
} ]

[glenrobson]

And just to open a can of worms should the id be:

https://www.wikidata.org/wiki/Q23308

or

https://viaf.org/viaf/121814978/

as then you could plot the owners on a map and get translations...

[azaroth42]

I think we should require id and type, not be opinionated about what the id should be, and type should be either always Agent or either Person / Organization.

[glenrobson]

What are the risks if we are opinionated about the id? Something similar to the rights statement in 3.0:

A string that identifies a license or rights statement that applies to the content of the resource, such as the JSON of a Manifest or the pixels of an image. The value must be drawn from the set of Creative Commons licenses, the RightsStatements.org rights statements, or those added via the extension mechanism.

I think we should at least say the id should be consistent between resources from the same institution and ideally should point to a linked data resource for the institution. Without consistency its no better than a label.

[azaroth42]

Community call of 2018-08-01: Big change, but one that has value. If we want to do it, now is the time to do it. We've lost something with attribution and this re-establishes the connection to the organizations. Accessibility is a big use case as well. Important for discovery and aggregations of manifests across organizations. Rather solve it here than externally in discovery or completely outside of IIIF. +1s all round to the general idea.

Need a concrete proposal with guidance.

[glenrobson]

Regarding the name for this property is it similar to edm:provider and if so would provider be a good name?

[beaudet]

Seems like a useful proposal and allowing multiple occurrences of this element would be good for shared attribution scenarios such as an exhibition being planned by multiple institutions.

[azaroth42]

Warning, Semantics Overload Follows

Predicate

Re edm:provider ... I think it should be broader than the definition:

The name or identifier of the organization who delivers data directly to an
aggregation service

The example shows that it's a project that collects data from institutions and then delivers it to Europeana. I think we want something more like edm:dataProvider ...

In the Europeana context this will be the name of the organization that sends
the data to Europeana, and this is not necessarily the institution that holds or
owns the original or digitized object. Where data is being supplied by an
aggregator or project edm:provider is the name of aggregator or project. The
name of the content holder can be recorded in edm:dataProvider.

However dataProvider has a domain of ore:Aggregation:( So we can't use that either.

It's close to dcterms:rightsHolder ... but that might not be exactly the case either. The "association" in logo might not be one of rights holding, just permanent custody. It could be dcterms:publisher broadly speaking:

An entity responsible for making the resource available.

It doesn't say how it's made available. It could be digitally, or physically.

It could be schema:provider:

The service provider, service operator, or service performer; the goods producer.

(It has a domain of CreativeWork, which is sufficiently vague to be the Manifest or the object it represents)

Or schema:publisher, with the exceedingly bland definition:

The publisher of the creative work.

Of those ... I like schema:provider, which we would map in the context to provider.

Class

We can either have a consistent Agent (such as dcterms:Agent), or schema's separation between Person and Organization. A single class is more flexible and makes it easier to create and consume ... it's a fixed string that doesn't need any smarts, but doesn't give us much information.

The most common case will be Organization. Indeed the definition of logo says it's an organization. So we can simply encode that in the model ... closing the door on having it refer to People (e.g. the private owner of an artwork).

Or we can trust that if a system knows it's a Person, that they'll be able to put that in to the data. Systems that don't know will normally not be wrong if they naively put Organization.

My preference is to use the two schema classes, with a note that Organization is what will be used the vast majority of the time, and that clients likely don't even need to check the type to do something reasonable.

Example

To fill out Tom's example from the comment above...

"provider" : [
 {
   "id": "https://bl.uk",
   "type": "Organization",
   "label": "The British Library",
   "logo": [
      { 
          "id": "https://bl.uk/img/logo.jpg", 
          "type": "Image" 
      }
   ]
 } 
]

[azaroth42]

Eds call: Discuss on Discovery call, then air solution on next week's tech call.

Should just use Agent as clients are not expected to do anything differently between them.

[aisaac]

Sorry it took so much time to be available for this very interesting discussion.
Of course the move for better attribution is something I applaud.

Now on the semantics overload...

In fact I'd argue that edm:dataProvider could be used, if some like it. Europeana could relax its domain of ore:Aggregation. But I'm not even sure it's needed, as I believe that every resource of type Manifest could be seen as an ore:Aggregation too. Actually I think I would even go as far as saying that sc:Manifest could be quite safely declared a subclass of ore:Aggregation. And it's easier for me to conceive a Manifest as an ore:Aggregation than a schema:CreativeWork :-)

My two cents on other proposals

• edm:provider is indeed not good.

• schema:provider is much better than schema:publisher, indeed. I would strongly argue against schema:publisher.

• I'd favor using Agent over forcing the separation/identification of Organizations and Persons. But my ultimate preference at this stage would be to make type optional and not incite data consumers to expect too much of it. For attribution purposes, the properties of the resource probably matter much more than its type.

[azaroth42]

Approval on technical community call of 2018-09-26.

[azaroth42]

Closed by #1699

[zimeon]

Approved by TRC, already merged into image-prezi-rc2.