Support linking or referencing related resources

[cookeac]

It could be useful to have a generalised method for referencing one event from another, and describing the relationship between the events. This is demonstrated by the desire to link feed intake events and milking events when animals are fed while they are milked #171.

We did something similar for links between spatial resources at https://github.com/Datalinker-Org/Geospatial
There we created a RelationType with the properties:

Name	Type	Description
relationship	string	How the referenced resource relates to the current resource (using a well-known syntax or FOAF).
contentType	string	The name of the resource so a client knows the type of resource that is being referenced.
related	string, uri	A URI that may be used to retrieve the related resource.

We could add to these a relatedIdentifier (source and ID?) that could be used in preference to the related URI.

It would then be possible to extend icarEventCoreResouce (or even icarResource) to have an array of related resources or related events.

[alamers]

Sounds interesting. A few questions:

• the 'relationship' type's well-known syntax: this would be some standardised set of types? A quick scan of FOAF indicates that it is defined mostly for a social network context, so this would be up to ADE? I am a bit in doubt in how much a client can expect in this area: do we expect some relations to be compulsory? How do we grow from these 'loosely' defined relations to more strict relations?
• contentType: as in 'text/json'? do we have other content types or could this also refer to things outside ADE?
• related vs relatedIdentifier: I guess this is the semantic web vs 'classic' url construction again? I have a slight preference for id's since then the message is decoupled from its transport but I think we haven't really made a choice in that area.

[gra-moore]

I have a few comments:

1. have a well defined section in the entity data structure that contains all references. This allows clients to be sure what group of keys are references.

2. The contentType idea isnt ideal. Instead we should promote the idea of a type property in the data. either via a ref to Class or a promoted key such as rdf:type.

3. Agree the reltype should be a URI and so should the value. If you want to encode schemes then use URNs and map the common agri schemes to URN schemes.

4. The value should be either a single string interpreted as a URI or an array.

5. This a generalized mechanism for referencing any kinds of things, not just events.

So relationships could look like:

{
....
"refs" : {
"http://ade.org/events/parturition" : "urn:myweirdscheme:38835835863"
}
}

We should create semantic URIs for the classes and rel types.

[cookeac]

Good points:

• Yes, I would see this type being a used in a common array (well-defined section) in icarResource.json.
• I had been intending contentType as the class name. It might be better to call it class! I agree with the semantic URI idea for these if it doesn't make it too hard for others to understand (like @gra-moore's example).
• Given our heritage (many people from classic web and less from semantic web backgrounds) we need to think carefully about the semantics for value / related / relatedIdentifier... I'd like to pick up discussion of especially this part at one of our meetings.

[cookeac]

To discuss at an upcoming meeting:

• Will the changes to resources in the Streaming API project make this easy?
• We talked about a set of well-known relationship types (relationship types to be defined using URIs, perhaps with a short syntax as per types). If so, what relationships would people value? The initial example was an event occurring simultaneously (e.g. a feed or treatment during a milking visit.

[cookeac]

This was previously called "Support linking or referencing related events" because it started from linking events recorded together in time (for instance, a milking visit with a treatment or feed), or events linked by intent (for instance, linking a treatment to a prior diagnosis).

[cookeac]

Proposed mechanism to implement this in a tidy manner:

1. Update icarResourceReferenceType.json

Attribute	Type	Notes
@context	string	DEPRECATED
@id	string	DEPRECATED
@type	string	DEPRECATED
reltype	string, format uri	URI relationship type specified in relationshipCatalog.md
identifier	icarIdentifier	Unique identifier of the referenced resource - see meta.source, meta.sourceId

In V2, identifier would be a URI rather than a scheme and ID combination.

2. Add "related" : array of icarResourceReferenceType to icarResource
3. Create a file relationshipCatalog.md which defines the relationships with URIs and documents expected resourceTypes.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.