Publish as annexes mappings to DPLA MAP and EDM and PCDM

zimeon commented 9 years ago

Should have annexes that describe mappings to other metadata formats:

[ ] DPLA Metadata Application Profile - DPLA MAP
[ ] Europeana Data Model - EDM
[ ] Portland Common Data Model - PCDM

anarchivist commented 8 years ago

Per conversations with @azaroth42 and @jpstroop in Philadelphia, we should target to have drafts ready for the meeting in Gent, and perhaps earlier to solicit discussion.

anarchivist commented 8 years ago

Here are my fragmentary notes from my conversation with @jpstroop in Vancouver last week.

Use case 1: Linking to manifests from objects described in EDM or DPLA MAP.

DPLA is starting to see significant uptake of IIIF within our community. As such, we'd like to a way to advertise (in metadata) that there is a manifest present that can be easily passed to a IIIF viewer through the presence of a specific property, or set thereof. In addition, this would allow us to easily build a filter within our API to have it only return results that have a manifest associated with them.

Strawperson proposal A: Devise a new predicate (e.g., iiif:hasManifest) which is a subproperty of edm:hasView. edm:hasView has a range of ore:Aggregation and a domain of edm:WebResource. Example:

@prefix dct: <http://purl.org/dc/terms/> .
@prefix dpla: <http://dp.la/about/map/> .
@prefix edm: <http://www.europeana.eu/schemas/edm/> . 
@prefix iana: <http://www.iana.org/assignments/link-relations/> .
@prefix iiif: <http://iiif.io/api/presentation/2#> . 
@prefix ore: <http://www.openarchives.org/ore/terms/> .

_:foo a ore:Aggregation ;
    edm:aggregatedCHO [
        a dpla:SourceResource ;
        dct:title "Foo" 
    ] ;
    iiif:hasManifest <http://example.org/manifest/foo> .

Pros: simple definition; leverages EDM/DPLA structure.
Cons: as a subproperty of edm:hasView, it asserts that the manifest is an edm:WebResource; a manifest may not be a "view" in an EDM sense (see Rob's note from May 2015 hackathon); manifests may contain things which are not the CHO itself (see same note)

Strawperson proposal B: Use iana:describedBy/wdrs:describedBy and explicit typing as an iiif:Manifest, as proposed by Rob in this thread with Tom Crane (related to linking resources to their manifests). Example:

@prefix dct: <http://purl.org/dc/terms/> .
@prefix dpla: <http://dp.la/about/map/> .
@prefix edm: <http://www.europeana.eu/schemas/edm/> . 
@prefix iana: <http://www.iana.org/assignments/link-relations/> .
@prefix iiif: <http://iiif.io/api/presentation/2#> . 
@prefix ore: <http://www.openarchives.org/ore/terms/> .

_:bar a ore:Aggregation ;
    edm:aggregatedCHO [
        a dpla:SourceResource ;
        dct:title "Bar" 
    ] ;
    iana:describedBy <http://example.org/manifest/bar> .

<http://example.org/manifest/bar> a iiif:Manifest .

Pros: leverages existing predicates and existing typing; previously suggested.
Cons: adds additional triples; requires additional parsing to identify relationship.

anarchivist commented 8 years ago

Use case 2: Determining whether an image resource associated with an ore:Aggregation through edm:hasView, edm:object, edm:preview, etc. is accessible over the IIIF Image API.

Given the mix of providers in DPLA, not all of them will be providing IIIF Image API access. For those that do, we may want to have them be able to advertise the presence of their Image API implementation even if they're not publishing manifests.

Strawperson A: Dereference the image URI and parse the returned link headers (see "Compliance Levels").

@prefix dct: <http://purl.org/dc/terms/> .
@prefix dpla: <http://dp.la/about/map/> .
@prefix edm: <http://www.europeana.eu/schemas/edm/> . 
@prefix ore: <http://www.openarchives.org/ore/terms/> .

<http://example.org/foo/> a ore:Aggregation ;
    edm:aggregatedCHO [
        a dpla:SourceResource ;
        dct:title "Foo" 
    ] ;
    edm:object <http://example.org/image/foo/full/,450/0/default.jpg> ; 
    edm:preview <http://example.org/image/foo/full/,150/0/default.jpg> .

$ curl -v http://example.org/image/foo/full/,450/0/default.jpg
HTTP/1.1 200 OK
Link: <http://iiif.io/api/image/2/level1.json>;rel="profile"
...

Pros: Leverages expected behavior of the Image API.
Cons: Won't (might not?) work in JavaScript-based clients.

Strawperson B: Specify a Presentation API image resource, using rdf:type=dctypes:Image and service/profile statements.

@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix dctypes: <http://purl.org/dc/dcmitype/> .
@prefix dpla: <http://dp.la/about/map/> .
@prefix edm: <http://www.europeana.eu/schemas/edm/> . 
@prefix iiif: <http://iiif.io/api/presentation/2#> .
@prefix ore: <http://www.openarchives.org/ore/terms/> .
@prefix svcs: <http://rdfs.org/sioc/services#> .

<http://example.org/foo/> a ore:Aggregation ;
    edm:aggregatedCHO [
        a dpla:SourceResource ;
        dct:title "Foo" 
    ] ;
    edm:object <http://example.org/image/foo/full/,450/0/default.jpg> ;
    edm:preview <http://example.org/image/foo/full/,150/0/default.jpg> .

<http://example.org/image/foo/full/,450/0/default.jpg> a dctypes:Image ;
    dc:format "image/jpeg" ;
    svcs:has_service <http://example.org/image/foo> . 

<http://example.org/image/foo/full/,150/0/default.jpg> a dctypes:Image ;
    dc:format "image/jpeg" ;
    svcs:has_service <http://example.org/image/foo> . 

<http://example.org/image/foo> dct:conformsTo <http://iiif.io/api/image/2/profiles/level2.json> .

Pros: Leverages existing mechanism from Presentation API; should work in JavaScript since it doesn't rely on parsing headers.
Cons: Adds noticeably more triples, especially when referring to multiple views of the same object; concerns about dereferenceability of triples.

anarchivist commented 8 years ago

BTW, I'm happy to readd these as distinct issues, should we think that's best... :)

tomcrane commented 8 years ago

(linking issues) The solution for use case 1 should be consistent with the solution for #557, whatever the solutions turn out to be.

aisaac commented 8 years ago

We have progressed (well, sort of) on our own efforts in the past weeks, in the Europeana Cloud project. We are focusing on use case 1 but it might touch on use case 2 soon.

The current discussion is mostly captured in this Google doc, which I will lack the time to sum up. https://docs.google.com/document/d/14OnHx1bjLWew4aFjH0Pd5gKZPDFpFOV8zJQcg_TfT9E/

Right now I'm thinking the best is to link to the manifest from the EDM WebResource, not the Aggregation, for reasons that are very much like Mark's con for Strawperson proposal A. For us having the manifest linked at the level of the manifestation may be hard to handle for these aggregations that bundle together sounds, video with (IIIF) images, or just two sets of IIIF resources.

In the end it appears that all this is made more difficult by the fact there is no link between an Image URI and a (canonical) manifest URL. Is such better linking is what #557 is about?

aisaac commented 8 years ago

Just to clarify: the Google doc I've pointed to is quite messy, but I don't have time to coordinate better. In the meantime you should feel entirely free to comment there. Or copy bits of our discussion here, if you think it's appropriate!

azaroth42 commented 8 years ago

Use Case 3: Linking from a Manifest to the CHO that it describes.

It is possible already to link from a Manifest to further descriptions of the object using seeAlso, however best practices are not defined. An annex could add extra information about how to best represent the object of that relationship, for example (with appropriate @context definitions and selection of key properties):

{
 "@type": "sc:Manifest",
 "seeAlso": {
    "@id": "http://europeana.example.org/object/1",
    "@type": "edm:CHO",
    "label": "..."
  }
}

azaroth42 commented 8 years ago

Rob, Mark, Jon, Simeon, Glen will all be at Ghent... who from Europeana will be there? Can we block out time to discuss it in person, rather than via issue/docs?

Alternatively, could we use a IIIF call (Weds 9am PST / 6pm Europe) to discuss if we can get the right attendees lined up?

aisaac commented 8 years ago

I'll attend Ghent Wed-Fri.

On 11/10/15 12:48 AM, Rob Sanderson wrote:

Rob, Mark, Jon, Simeon, Glen will all be at Ghent... who from Europeana will be there? Can we block out time to discuss it in person, rather than via issue/docs?

Alternatively, could we use a IIIF call (Weds 9am PST / 6pm Europe) to discuss if we can get the right attendees lined up?

— Reply to this email directly or view it on GitHub https://github.com/IIIF/iiif.io/issues/558#issuecomment-155235789.

nfreire commented 8 years ago

Here's my humble opinion about the usage in EDM, of URIs of IIIF manifest and IIIF Images. Based on my interpretation of EDM, as a data model, this is what comes to mind on a few points:

Depending on what a manifest describes it may be about a WebResource, a CHO or both at the same time. If EDM does not allow linking to a IIIF freely, then it may be limiting too much, and deny the provision of valid content for Europeana.

I don't see a reason to force data providers to provide a IIIF manifest. Neither I see a reason to disallow the linking to IIIF Manifest from a web resource. But if a manifest URI is used to identify a WebResource and/or in the aggregation properties, then the WebResource must have the dc:conformsTo property stating that it is a manifest.

Providing a IIIF image API URI is ok for a WebResource and also for the aggregation properties.

A manifest describing a single image could be a valid isShownBy value. but one describing a complex object (a digitized book, for example) may not conform to the Europeana content policy.

aisaac commented 8 years ago

The definition from 'manifest' starts with "The overall description of the structure and properties of the digital representation of an object" at http://iiif.io/api/presentation/2.0/#primary-resource-types. It seems very reasonable to link a WebResource that is in inShownBy to a manifest. But to me this definition prevents a manifest to be a valid isShownBy as a general rule. A description of a digital representation cannot be a 'view', it's the digital representation that plays this role.

nfreire commented 8 years ago

I understand your point. But if we disallow its usage in isShownBy, than we are excluding cases where the link directs the user just to the representation and nothing more.

My interpretation of isShownBy was that it could link to anything that provided a direct link to a presentation, view, or media file, and that the distinction with isShownAt, was that a isShownAt could be displayed along with metadata, for example.

JPEG, MPEG, etc... All these files contain metadata as well as the representation, just like a manifest.

(let me know if posting this discussion both in the google doc and here is confusing. I'm not sure if commenting on the google doc will go unnoticed...)

aisaac commented 8 years ago

For me JPEG, MPEG etc are the representation. They have metadata embedded, but to me they're at the same level as the URI of the image as in the IIIF Image API. Manifest provide access to representation, but this access is indirect: one has to follow an extra link. In terms of Web principle I think this is a big difference. And I really don't like to have a slot in EDM where we can have either a representation or a pure description of a representation.

The expectation for isShownBy is that allows direct access to media. Note that this doesn't forbid to have manifests in EDM. We could have isShownBy to a WebResource, and then attach a manifest to that resource (next to the flag with the IIIF protocol URI) using a dedicated property.

hugomanguinhas commented 8 years ago

Hi all, here are a couple of suggestions.

Looking at Use case 2, strawperson B, I feel that it is still missing a clean way of detecting if it’s a IIIF image without checking for conformity against all possible profile URIs. Perhaps, an interesting way would be to have dct:conformsTo linking to “http://iiif.io/api/image/2” instead, while another property would specify the actual compliance level (x?:profile), similar as it is done within the manifest but with an additional dct:conformsTo prop. I would add as "cons" the performance penalty for figuring out if it is a IIIF image specially when it is not.

About strawperson A, another “pros” is the ability to power other use cases such as searching for IIIF images within a dataset.

Still for Use Case 2, i would add yet another simpler alternative, suggested by Antoine in our document, to just have the dcf:conformsTo linking to “http://iiif.io/api/image/2” without advertising the capabilities in advance and let the viewer handle all the necessary interaction from that point on.

<http://example.org/image/foo/full/full/0/default.jpg> a dctypes:Image ;
    dc:format "image/jpeg" ;
    dct:conformsTo <http://iiif.io/api/image/2> .

If this alternative is considered, the same pattern could also apply for Use Case 1 only to state that the WebResource is a IIIF presentation manifest, potentially making this way the model more consistent.

<http://example.org/presentation/foo/manifest> a edm:WebResource ;
    dct:conformsTo <http://iiif.io/api/presentation/2> .

pros: same as in B, but potentially more consistent.
cons: same as in B.

hugomanguinhas commented 8 years ago

A better look at my first example which was taken from Use Case 2 strawperson B, makes me realize that having the ".jpg" extension in the canonical URI and the dc:format "image/jpeg" may perhaps be strange from the Image API perspective since ideally it should be agnostic to the format.

A revised version would be:

<http://example.org/image/foo> a dctypes:Image ;
    dct:conformsTo <http://iiif.io/api/image/2> .

This would be make it easier both to request for the info.json and for the canonical URI by just appending them.

anarchivist commented 8 years ago

Belatedly in response to @azaroth42:

Can we block out time to discuss it in person, rather than via issue/docs?

:+1:

aisaac commented 8 years ago

I'm willing to do block time for discussion in Ghent, but for one of the issues finding a property to link to manifests) we have to do it very soon because of Europeana's deadline. The rest can wait a bit indeed.

anarchivist commented 8 years ago

@aisaac Understood. I'll try to look at this over the next few days, as will @no-reply (especially since you'll likely be seeing him this week). If there are any areas that think demand specific feedback from us as maintainers of an EDM refinement let us know.

anarchivist commented 8 years ago

Quasi-official proposal for Use Case 3 follow's @azaroth42's comment above.

jpstroop commented 8 years ago

In "Use Case 3: Linking from a Manifest to the CHO that it describes", do we want seeAlso or the new (in 2.1) rendering predicate? Is the CHO just metadata, or an actual representation? http://iiif.io/api/presentation/2.1/#linking-properties

glenrobson commented 8 years ago

Hi,

Feel free to correct but this is what I have in my notes from last night:

Use Case 1: EDM and IIIF Manifest CHO

_:foo a ore:Aggregation
_:foo <edm:isShownBy> <http://dams.llgc.org.uk/iiif/image/2.0/1294670/full/512,/0/default.jpg>

Web Resource

<http://dams.llgc.org.uk/iiif/image/2.0/1294670/full/512,/0/default.jpg> a edm:WebResource
<http://dams.llgc.org.uk/iiif/image/2.0/1294670/full/512,/0/default.jpg> <wdrs:describedby> <http://dams.llgc.org.uk/iiif/2.0/1294670/manifest.json>

Use Case 2: EDM and IIIF Image CHO

_:foo a ore:Aggregation ;
_:foo <edm:isShownBy> <http://dams.llgc.org.uk/iiif/image/2.0/1294670/full/512,/0/default.jpg>

Web Resource

<http://dams.llgc.org.uk/iiif/image/2.0/1294670/full/512,/0/default.jpg> a edm:WebResource
<http://dams.llgc.org.uk/iiif/image/2.0/1294670/full/512,/0/default.jpg> <svcs:has_service> <http://dams.llgc.org.uk/iiif/image/2.0/1294670>

Service

<http://dams.llgc.org.uk/iiif/image/2.0/1294670> <dcterms:conformsTo> "http://iiif.io/api/image/2/level1.json"

Notes:

The ID of the Web Resource which is a link to a thumbnail provided by the content supplier. This can either be the Manifest thumbnail or if this isn't pressent the resource id of the first canvas
Using the web resource id as a thumbnail should make it fit with non IIIF resources

aisaac commented 8 years ago

Thanks, Glen! It generally matches what I remember, but the devil is in the detail and Hugo will come with a couple of questions (mostly about the conformsTo) from our side. In the meantime I have two questions:

can someone send a picture of the drawing we made? I'm sure there was at least one!
from our perspective the ID of the WebResource may be anything that the provider deems appropriate. The good thing of the pattern is that by being compatible with non-IIIF resources, it can inherit the flexibility - it could be edm:object and not edm:isShownBy. And of course the bigger, the better (then the WebResource would score high in our Content Re-use Framework.

hugomanguinhas commented 8 years ago

Hi all,

Continuing Antoine's remark about the conformsTo, we thought of suggesting two other options that we would be more confortable on supporting/implementing.

... just to make sure we all agree with this part:

@prefix svcs: <http://rdfs.org/sioc/services#> .
@prefix wdrs: <http://www.w3.org/2007/05/powder-s#> .

_:bar a ore:Aggregation ;
  edm:object <http://dams.llgc.org.uk/iiif/image/2.0/1294670/full/512,/0/default.jpg> .

<http://dams.llgc.org.uk/iiif/image/2.0/1294670/full/512,/0/default.jpg>
  a edm:WebResource ;
  wdrs:describedby <http://dams.llgc.org.uk/iiif/2.0/1294670/manifest.json> ;
  svcs:has_service <http://dams.llgc.org.uk/iiif/image/2.0/1294670> .

Our preferred option: with the value and the property we're interested in, but not using the exact property from IIIF specs (which is doap:implements)

<http://dams.llgc.org.uk/iiif/image/2.0/1294670>
  dcterms:conformsTo "http://iiif.io/api/image" .

2nd prefered option: with the value we want and the property already associated with it in IIIF specs, but prefer to avoid using a new property.

<http://dams.llgc.org.uk/iiif/image/2.0/1294670>
  doap:implements "http://iiif.io/api/image" .

3rd prefered option: the property is alright both for us and IIIF specs, but we're not so interested in having the URI with the level info - this is probably quite dynamic and again our requirement is just to know that it's a IIIF image. Mathes the option on Glen's notes.

<http://dams.llgc.org.uk/iiif/image/2.0/1294670>
  dcterms:conformsTo "http://iiif.io/api/image/2/level1.json" .

btw, I guess there is no need to add a statement for the svcs:Service, like so:

<http://dams.llgc.org.uk/iiif/image/2.0/1294670> a svcs:Service

glenrobson commented 8 years ago

Sorry for the delay but here are the diagrams I have from the meeting in Ghent.

vcharles89 commented 8 years ago

Hello, We are finalising at Europeana our solution to accomodate a simple mapping IIIF to EDM. The proposed solution (or solutions as we have tiny variations) are in the document at https://docs.google.com/document/d/14OnHx1bjLWew4aFjH0Pd5gKZPDFpFOV8zJQcg_TfT9E/edit# If we describe the IIIF service as a Service conforming to a specific protocol, we have understood that two URIs are important:

http://dams.llgc.org.uk/iiif/image/2.0/1294670 dcterms:conformsTo "http://iiif.io/api/image/2/level1.json" and http://dams.llgc.org.uk/iiif/image/2.0/1294670 doap:implements "http://iiif.io/api/image" .

On our side we don't need the two URIs as one would be enough for us to identify the resource as being a IIIF one. But we were wondering if they are important from a IIIF implementer.

If we need to accommodate both in EDM we suggest to make dcterms:conformsTO repeatable so that the needed URIs can be provided.

Any thoughts?

aisaac commented 8 years ago

Ping! We'd really like to know if our (prefered) use of dcterms:conformsTo with http://iiif.io/api/image is too unorthodox...

aisaac commented 8 years ago

I have also cleaned up the document where we keep track of the decisions and their rationale: https://docs.google.com/document/d/14OnHx1bjLWew4aFjH0Pd5gKZPDFpFOV8zJQcg_TfT9E/

zimeon commented 8 years ago

The IIIF specs use dcterms:conformsTo for the specific profile with version (as profile in JSON, see context) and doap:implements for the general protocol without specific version (as protocol in JSON). I think it would be confusing for Europeana to use dcterms:conformsTo the other way around, to indicate the general protocol without specific version. I think option #2, use of doap:implements in a way consistent with IIIF protocol would be better.

hugomanguinhas commented 8 years ago

Hello Simeon,

Thanks for your response!

We agree that option #2 is the one that is most consistent with the IIIF specs... but we are arguing that using the dcterms:conformsTo with the general protocol would make sense by looking at their definition:

dcterms:conformsTo, is defined as

An established standard to which the described resource conforms.

doap:implements, is defined as

A specification that a project implements. Could be a standard, API or legally defined level of conformance.

In fact, even though any combination of these properties could be possible, the definition for doap:implements seems more appropriate for defining a concrete implementation, and thus could be more suitable to express the compliance level than the general dcterms:conformsTo.

Shall we create a new ticket to discuss it?

aisaac commented 8 years ago

brief update: @hugomanguinhas 's message above has remained unanswered for 23 days, and we need to move on. So we have decided that our 'simple' EDM extension to ingest IIIF will follow the current IIIF usage of dcterms:conformsTo (profile) and doap:implements (protocol). For the record it's not making our life easier and we still think that IIIF uses these two properties in a slightly weird way. But we hope this will be soon alleviated by a strong flow of IIIF content being shared with Europeana and its users ;-)

aisaac commented 8 years ago

https://docs.google.com/document/d/13v32sEhYKxDFJR87YcQuzzQNmo1dT4MB-QbrD2oVfoE/ New version

azaroth42 commented 8 years ago

Agreement at LDCX (Eds plus @aisaac @kestlund @glenrobson) to swap.

Action to update the context.json for image API to swap profile/protocol, and presentation context for profile.

anarchivist commented 8 years ago

:+1: From the other room :smile_cat:

vcharles89 commented 8 years ago

Dear all,

There is now a doubt regarding the namespace of the Service class. Is it svcs:Service or sioc:Service? Does someone know?

hugomanguinhas commented 8 years ago

Hi Valentine, all,

The confusion here emerged because only the sioc prefix is defined in the spec (http://rdfs.org/sioc/spec/), but none is defined for the modules, in this case, the "SIOC Services Ontology Module" which has a different namespace URI.

I could not find it anywhere, so we were wondering if it was defined only in IIIF out of necessity? or if there is, in fact, some normative document that defines it?

Thanks for your help!

aisaac commented 8 years ago

Hi everyone,

I don't understand the problem: The JSON context at http://iiif.io/api/image/2/context.json uses a class with the URI http://rdfs.org/sioc/services#Service This class does exist in the SIOC Services Ontology Module, and the URI derefers to relevant data. Why would we care further?

Antoine

On 14/04/16 05:24, Hugo Manguinhas wrote:

Hi Valentine, all,

The confusion here emerged because only the sioc prefix is defined in the spec (http://rdfs.org/sioc/spec/), but none is defined for the modules, in this case, the "SIOC Services Ontology Module" which has a different namespace URI.

I could not find it anywhere, so we were wondering if it was defined only in IIIF out of necessity? or if there is, in fact, some normative document that defines it?

Thanks for your help!

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/IIIF/iiif.io/issues/558#issuecomment-209845672

vcharles89 commented 8 years ago

Hi,

It was more a documentation question. In the EDM documentation we refer to the svcs:Service class, and I was afraid we had made a mistake and that it should be noted sioc:Service. But it seems we are good.

Valentine

aisaac commented 8 years ago

OK I understand better. The trick is that anyone can define/use any prefix abbreviation they want, as long as it refers to the right URI prefix. This is why we have sometimes 'dc:' and sometimes 'dc11:' in W3C circles. That said it's always better to re-use established abbreviation, and I realize the Sioc spec does mention 'sioc:Service' in the text at http://rdfs.org/sioc/spec/#sec-modules

Antoine

On 14/04/16 07:41, vcharles89 wrote:

Hi,

It was more a documentation question. In the EDM documentation we refer to the svcs:Service class, and I was afraid we had made a mistake and that it should be noted sioc:Service. But it seems we are good.

Valentine

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/IIIF/iiif.io/issues/558#issuecomment-209892554

hugomanguinhas commented 8 years ago

Hi Antoine, that is true for RDF parsers... but for schemas such as EDM that relies on the RDF/XML syntax that is no longer true.

Best regards, Hugo

aisaac commented 8 years ago

This may be possible, I remember having had some discussions about it about the alignment vocabulary EDOAL. That said our EDM/XML file are very probably never going to be co-existing with SIOC XML files in a non-RDF context. The risk is very low that something would go wrong.

That said IIIF is open for a final review round feel free to raise this as a separate comment to the editor. My take is that in the IIIF context our EDM choices should abide to the IIIF ones. We shall not use a different abbreviation unless IIIF specs use a different abbreviation.

Antoine

On 14/04/16 07:54, Hugo Manguinhas wrote:

Hi Antoine, that is true for RDF parsers... but for schemas such as EDM that relies on the RDF/XML syntax that is no longer true.

Best regards, Hugo

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/IIIF/iiif.io/issues/558#issuecomment-209900775

vcharles89 commented 8 years ago

Europeana is now ready to push in production a series of updates of the EDM schema including the solutions for IIIF. The change svcs to sioc can still be done but I will need to know by the end of the week.

We just need to prefix IIIF chooses and Europeana will align.

Valentine

azaroth42 commented 8 years ago

In the Services module of SIOC, the schema defines the "sioc" prefix for the full namespace (http://rdfs.org/sioc/ns#), and doesn't define another prefix, so we made one up. If there's a better one, we can certainly change it at this end, as the mapping to RDF is not covered by semantic versioning.

That said, I agree with Antoine, that the prefix is not an important choice, and any system that relies on a particular XML serialization should be updated to something less brittle.

azaroth42 commented 7 years ago

Adding discovery tag, re chartered section 2 on IIIF to other systems links.

azaroth42 commented 6 years ago

How do we close this issue?

aisaac commented 6 years ago

As far as EDM is concerned we have a way to represent the availability of IIIF resources in EDM: https://pro.europeana.eu/page/edm-profiles We are also working on mappings to populate IIIF Manifests from EDM data (https://docs.google.com/spreadsheets/d/1UQNV_GDIKFvazDRMZ67sypPYgSucLsW4Lxpw8k2GE2g/) But I'm really not sure how these should refered from the IIIF space - which i guess was the original question, which triggered all the work on the mappings themselves ;-).

azaroth42 commented 6 years ago

Per the decision for #1089, the place for these is in the cookbook, and not a IIIF specific process. Closing.

IIIF / api

Publish as annexes mappings to DPLA MAP and EDM and PCDM #558