We need a vocabulary of Service Hub types

[phochste]

When sending / receiving activities out of the blue, the Orchestrator needs to guess from the actor type (or possible origin type in case of COAR) which type of service is contacting the pod. An activity from a review service might need an other rulebook than an activity from a discovery service.

Currently all the orchestrator gets is:

Some Organization is contacting me

  "actor": {
    "id": "http://meemoo.be#me",
    "type": ["Organization", "schema:Organization"],
    "name": "meemoo"  
  }

or using a COAR example

Some Service is contacting me

  "origin": {
    "id": "https://repository.org",
    "inbox": "https://repository.org/inbox/",
    "type": [
      "Service"
    ]
  }

Wouldn't it be better to have something like?

  "actor": {
    "id": "http://meemoo.be#me",
    "type": ["Organization", "schema:Organization", "mellon:ArchivingServiceHub"],
    "name": "meemoo"  
  }

[phochste]

Or better, by some way (magic) the orchestrator can find out what the service type if of a Service Hub. This is also the preference of Herbert to keep the Event messages as light as possible. We could e.g. propose that in a WebID profile a Service Hub can specify which type of services are provided.

[mielvds]

Yes, that last one seems like the preferred option. The URI in the actor is preferably the WebID or some other profile doc of the organisation.

An activity from a review service might need an other rulebook than an activity from a discovery service.

Wouldn't the notification already indicate what the ServiceHub did with the artefact? Not sure whether this is the kind information we should be deriving from the ServiceHub type. Isn't it enough to know that some ServiceHub archived my artefact without knowing what kind of servicehub it is?

[mielvds]

todo:

• what are possible service hubs?
  

• is this use case specific?
  

[phochste]

A Service Hub can have multiple roles actually. In Mellon context:

• mellon:RegistrationServiceHub
• mellon:CertificationServiceHub
• mellon:DisseminationServiceHub
• mellon:ArchivationServiceHub
• mellon:Orchestrator
• mellon:Collector
• mellon:DataPod

A Service Hub can advertize these roles in a WebId profile:

<https://hochstenbach.inrupt.net/archivator/profile/orchestrator.ttl#me>
    as:name "Archivator's Orchestrator";
    as:inbox <https://hochstenbach.inrupt.net/archivator/orchestrator/>;       
    a foaf:Service, mellon:ArchivationServiceHub.

But it can also specify the role it takes in the Activity:

{
  "@context": "https://www.w3.org/ns/activitystreams/",
  "summary": "Koninklijke Bibliotheek announces Alba dataset",
  "type": "Announce",
  "actor": {
    "id": "https://www.kb.nl#me",
    "type": ["Organization","mellon:ArchivationServiceHub"]
    "inbox": "https://www.kb.nl/inbox",
    "name": "Koninklijke Bibliotheek"    
  },
  "object": {
    "id": "https://www.kb.nl/datasets/1",
    "type": "Object",
    "name": "Dataset about WOII"    
  },
  "origin": {
    "id": "http://example.org/Adlib",
    "type": "Application"
  },
  "updated": "2021-01-28T19:56:20.114Z"
}

[mielvds]

So here is something we need to hash out: are Orchestrators, collectors and datapods? I think not, because that means they would all need to implement server requirements (aka LDN Receiver), which is too much . Can they be servers? Sure. But that is not crucial for the interoperability aspect and thus not part of the spec.

But can they have an inbox? Sure, as long as they don't host them (aka LDN Consumer), because that would mean they are servers.

[phochste]

Ok, I miscommunicated this a little. What I meant we maybe need a vocabulary of Service Hub types (and there can be many of which the mentioned ones can be a grouping). We also might need to clarify what a as:Application is in the as:origin. Is this a DashBoard ? Is this an Orchestrator?

There second thing is that orchestrators, collectors can have inboxes even when they themselves aren't services. An inbox is just a LDP Collection with some ACLs ..these inboxes can be anywhere on the web. If you can talk to the network, then you can have an inbox.

[mielvds]

Ok, I miscommunicated this a little. What I meant we maybe need a vocabulary of Service Hub types (and there can be many of which the mentioned ones can be a grouping). We also might need to clarify what a as:Application is in the as:origin. Is this a DashBoard ? Is this an Orchestrator?

Okay, then we're on the same page. Something like

subclasses of as:Service

• mellon:RegistrationServiceHub
• mellon:CertificationServiceHub
• mellon:DisseminationServiceHub
• mellon:ArchivationServiceHub

subclasses of as:Application

• mellon:Orchestrator
• mellon:Collector
• mellon:DataPod

?

There second thing is that orchestrators, collectors can have inboxes even when they themselves aren't services. An inbox is just a LDP Collection with some ACLs ..these inboxes can be anywhere on the web. If you can talk to the network, then you can have an inbox.

Indeed, 'have an inbox' is ambiguous. I find the distinction clearer when using the LDN roles sender, receiver and consumer.

[phochste]

subclasses of as:Application

• mellon:Orchestrator
• mellon:Collector
• mellon:DataPod

• mellon:DashBoard
• mellon:ScholarlyBrowser (or whatever the name is)

[mielvds]

yep yep!

What I would say is:

daen = decentralized artefact exchange network aka this generic layer we are building

subclasses of as:Service

• daen:ServiceHub

subclasses of as:Application

• daen:Orchestrator
• daen:Collector
• daen:DataPod
• daen:DashBoard
• daen:Browser

Mellon/ResearcherPod aka scholary communication use-case

subclasses of daen:ServiceHub

• mellon:RegistrationServiceHub
• mellon:CertificationServiceHub
• mellon:DisseminationServiceHub
• mellon:ArchivationServiceHub

subclasses of daen:Browser

• mellon:ScholarlyBrowser (or whatever the name is)

ErfgoedPod aka Cultural Heritage use-case

subclasses of daen:ServiceHub

• ... don't really know yet, but probably nde:RegistryServiceHub

subclasses of daen:Browser

• ... don't really know yet, but probably nde:Portal