New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Temporal ORE Aggregations #147

Open
azaroth42 opened this Issue Apr 9, 2018 · 4 comments

Comments

Projects
None yet
1 participant
@azaroth42
Collaborator

azaroth42 commented Apr 9, 2018

Exploring how to use ore:Aggregations to model sets of objects of various different types has led to a question about the underlying model. For many of the use cases, it works pretty much seamlessly and as expected. For example, the set of objects in an exhibition is a perfectly lovely Aggregation and we can associate exhibition specific information with the Proxy. The set of objects in an Auction lot ... equally lovely. Europeana and DPLA have demonstrated Aggregations for museum objects. All good.

However when trying to model an art dealer's inventory as an Aggregation, where the membership of the inventory is constantly changing, we run into an issue. Similarly, though at a much lower rate, museum collections themselves.

Is the semantics of ore:aggregates "current member" or is it "current or former member"?

In other words, if I add something to an Aggregation, make an assertion about it with a Proxy, and then remove it from the Aggregation, what happens? Can I even remove something from an Aggregation, once added?

We can see two possible routes:

  1. It's no longer a member so it isn't aggregated. (the "currrent member" interpretation) This means that we can't continue to make the assertion about it via the Proxy... which means we really don't want to use Proxies for assertions about resources in the context of Aggregations that they might leave.
    1b Can we retain the Proxy, even though it is no longer an Aggregated Resource? Perhaps with an alternative predicate in place of proxyIn to assert that it's really proxy-used-to-be-in

  2. Or does it stay as an Aggregated Resource, as it has once been aggregated? ( the "current or former member" interpretation). This makes it impossible to tell what the current membership is without additional information, but makes it possible to continue to express information about the resource using the Proxy.

In either scenario, we would need to have Aggregating and Disaggregating activities, whereby Aggregated Resources join and leave Aggregations. This would allow the computation of the current set of members of the Aggregation ... which could be cached on the Aggregation somehow. These activities can refer to the Proxy, given a nice linking mechanism. They can also express more domain semantics of why the resource as aggregated -- e.g. the painting was acquired by the dealer, or the painting was added to the exhibition.

Our current preference is option 2. If it's not, then we would need something like option 1b to be true to avoid losing the information.

It would result in something like:

_:Collection a Aggregation ;
    aggregates _:a, _:b, _:c, ... _:zzzzzz ;
    current_state [
        a Aggregation ;
        aggregates _:a, _:c, _:e, _:gg ]

_:a a ManMadeObject .
_:proxy-a a Proxy ;
  proxyFor _:a ;
  proxyIn _:Collection ;
  identified_by [
       a Identifier ;
       value "K-1234" ] ;
  created_by [
    a Aggregating ;
    timespan [ ... ] ] ;
  finished_by [
    a Disaggregating ;
    timespan [ ...] ] .

@azaroth42 azaroth42 added the model label Apr 9, 2018

@azaroth42

This comment has been minimized.

Collaborator

azaroth42 commented Apr 9, 2018

azaroth42 marks this issue as being discussed in slack

@azaroth42

This comment has been minimized.

Collaborator

azaroth42 commented Apr 9, 2018

To provide an example of Option 1b:

_:Collection a Aggregation ;
    aggregates _:a, _:c, _:e, _:gg ]

_:bbb a ManMadeObject .     // note that bbb is not aggregated by Collection
_:proxy-bbb a Proxy ;
  proxyFor _:bbb ;
  proxyIn _:Collection ;
  identified_by [
       a Identifier ;
       value "K-1234" ] ;
  created_by [
    a Aggregating ;
    timespan [ ... ] ] ;
  finished_by [
    a Disaggregating ;
    timespan [ ...] ] .
@azaroth42

This comment has been minimized.

Collaborator

azaroth42 commented Apr 9, 2018

Noting (from slack discussion) that the set of objects which are currently "on view" is a good example of this, especially given the same object can be on view at one point, taken off view, then put back on view with a different label. Meaning multiple proxies for the same object in the same aggregation.

@azaroth42

This comment has been minimized.

Collaborator

azaroth42 commented Aug 31, 2018

I think this is solved by Phase, but we should check all of the use cases before closing.

@azaroth42 azaroth42 added the wontfix label Aug 31, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment