HOMEWORK: Read the ORE Specification

dannylamb commented 8 years ago

Homework ticket. Available for multiple assignees.

Read the ORE Spec, and ask questions or tell us what you think about it. ORE is the basis to PCDM, and we should consider how it affects our thoughts on content modeling in Fedora.

whikloj commented 8 years ago

I'm in, but I might not understand.

bryjbrown commented 8 years ago

Ditto.

DiegoPino commented 8 years ago

Well, i already did, but will re-visit again

manez commented 8 years ago

Also will read and not understand +1

acoburn commented 8 years ago

There have been a number of conversations about ORE and PCDM happening on a number of different channels. I wonder if it would make sense to consolidate those conversations here, on this issue, or on a mail list? I think the important thing is to make the conversation as open as possible, especially as it may have implications for modeling decisions.

dannylamb commented 8 years ago

Let's talk here (since we're finally talking about it), and take it to the list if it gets good (or just point people to this).

So for ORE, if we wanted to comply with the spec, which would open up non-pcdm implementations for folks while still allowing for PCDM, looks like we'd have to do some things that are off the radar of the PCDM community.

Most notably the Resource Map.

From what I can tell from reading the spec, the aggregation (D8 entity) would be available in html, and the ResourceMap would be the full graph in RDF (json-ld) available through some form of content negotioation.

The question I have is where the descriptive meta data for the aggregations go. Is it something on the resource map directly, or are they on the aggregations themselves and the resource map just pulls them all in (like through a CONSTRUCT query or something)?

dannylamb commented 8 years ago

So here's the way I'm seeing things, trying to take what @acoburn has been saying to heart. I think we can model anything we need using only ore:aggregates under the following conditions.

There are only two rdf:types that can also be ore:AggregatedResource's:
- NonRDFResources
- Other Aggregates
What type of thing you aggregate is inferred by other rdf:type's used in conjunction with ore:Aggregate (think mixins or interfaces, not inheritance)
Aggregated resources either all NonRDFResources or all ore:Aggregate. Any additional types are used for inference. (like using interfaces to type an array, and we're taking advantage of polymorphism)

Basic types only need to aggregate NonRDFResources:

So for an image...

<> a ore:Aggregate, schema:Image
<> ore:aggregates <thumbnailUri>, <serviceFileUri>, etc....

Which would be the similar to a page, except pages imply order (maybe worth a class of its own, i dunno. schema.org doesn't go to this granularity)...

<> a ore:Aggregate, schema:Image
<> ore:aggregates <thumbnailUri>, <serviceFileUri>, etc....
<> iana:next <anotherPageUri>
<> iana:prev <yetAnotherPageUri>

A compound object, like a book, will aggregate ore:Aggregates of NonRDFResources (pages in this case).

<> a ore:Aggregate, schema:Book
<> ore:aggregates <page1Uri>, etc...

<page1Uri> a ore:Aggregate, schema:Image
<page1Uri> ore:aggregates <thumbnailUri>, <serviceFileUri>, etc....
<page1Uri> iana:next <anotherPageUri>
<page1Uri> iana:prev <yetAnotherPageUri>

This then leads to the question: "Well, what if my book has its own files distinct from its pages? Like a thumbnail or some other descriptive metadata that I refuse to break into RDF." To which I think we just give it another ore:Aggregate of NonRDFResources that are considered its own files. Could be disambiguated by rdf:type (e.g. not a page/image).

<> a ore:Aggregate, schema:Book
<> ore:aggregates <page1Uri>, etc... <ownFilesUri>

<page1Uri> a ore:Aggregate, schema:Image
<page1Uri> ore:aggregates <thumbnailUri>, <serviceFileUri>, etc....
<page1Uri> iana:next <anotherPageUri>
<page1Uri> iana:prev <yetAnotherPageUri>

...

<ownFilesUri> a ore:Aggregate
<ownFilesUri> ore:aggregates <thumbnailUri>, <metadataXmlUri>, etc...

Or you could even collapse the pages into a range for IIIF, etc...

I'm pretty sure we can do everything in this fashion as long as we're clear what the rdf:type in addition to ore:Aggregate implies.

kimpham54 commented 8 years ago

@dannylamb how should collection membership be expressed in oai-ore? would it be important use a seperate property to distinguish the difference between the constituent parts of a whole object as an aggregated resource vs aggregates of aggregated resources? to me it seemed like ore:aggregates is used for aggregation of aggregated resources (but I'm still learning and trying to understand the spec)

DiegoPino commented 8 years ago

I have the same question/idea that @kimpham54 has. I don't see that a collection membership is semantically the same as being aggregated to a resource, looks like a different layer of knowledge. We could research on dcterms or dcmi predicates, re-look at PCDM and the decisions they took on this or also see how EDM does this.

dannylamb commented 8 years ago

That's a great question @kimpham54. You can aggregate anything so long as its got an rdf:type of ore:AggregatedResource. But the question remains, what does ore:aggregate mean vs dcterms:hasPart (which it refines)? I don't know the answer to that. I know @acoburn thinks that ore:aggregate means that the part is essential to the whole. And removing that part would mean the ore:Aggregate is not complete.

And @DiegoPino, just for the record in case others don't know. EDM mean what?

acoburn commented 8 years ago

@kimpham54 I have wondered this exact thing, too. As I see it (i.e. in the context of the repository resources that I currently manage), there are two kinds of collections: collections with a strong sense of membership and collections with a weak sense of membership. For instance, I've got an "Art & Architecture Collection": it contains 130,000 resources. I feel that adding or removing resources from that collection doesn't change the identity of that collection, so I see those members as weakly contained (i.e. dcterms:isPartOf / dcterms:hasPart). There are also other collections -- i.e. manuscripts that were physically located in a particular box. This collection contains a set of resources in a different sense -- if I were to add or remove a resource from that collection, I feel that the identity of that collection really changes. That second collection (in my mind) would ore:aggregates the contained resources.

DiegoPino commented 8 years ago

@daniel-dgi EDM == Europeana Data Model, which subclasses pretty much from ORE, which is also the basis for DP.LA's one. http://pro.europeana.eu/share-your-data/data-guidelines/edm-documentation

Please read this Ontology, it's really fun to read Ontologies: 😁 https://github.com/europeana/corelib/blob/v2.3/corelib-edm-definitions/src/main/resources/eu/rdf/edm.owl

dannylamb commented 8 years ago

Closing since sprint is over. We can open another ticket to 'revisit' this concept later if required.

Islandora / documentation

HOMEWORK: Read the ORE Specification #336