Skip to content

Latest commit

 

History

History
104 lines (67 loc) · 5.89 KB

Match-Architecture.md

File metadata and controls

104 lines (67 loc) · 5.89 KB

Matched Fragments

  • Represent matches as annotations
  • Some kinds of match can be recorded by relating two fragments to a shared concept
  • Other kinds of match may need need to be a pairwise
    • in which case only make sense within a "working set" (a consideration for the Architecture)

((GK: I think this should be developed separately as a match architecture document, and then come back and add vocabulary details. I'll add some thoughts below in this document, but suggest that anything adopted should be moved to a separate doc.))

The NiN remixer needs to be able to access fragment match candidates based on a number of criteria:

  • match criteria (e.g. deduced key signature(s), rhythmic style, etc.)
  • the current state of the work being assembled
  • selected position ("cursor") or elements in the work under construction
  • the role of the offered candidates (e.g. following item befiore cursor, preceding item after cursor, fitting between predecessor and successor at cursor, etc)
  • the extent of the insert required; e.g. single fragment, multiple fragment, etc.

Not all of these criteria are necessarily resolved by the compatibility service itself. I would initially propose an interface that indicates that uses:

  1. a desgnated fragment
  2. a compatibility model
  3. a match-before or match-after indicator

I would imagine the remixer itself would be able to use this to assemble longer sequences and/or satisfy multiple criteria.

A (partial?) REST-style interface for this could look something like:

  • a URI that embodies compatibility model and target fragment used to retrieve a list of candiate fragments (@@detail TBD, but I'm thinking of an LDP container per compatibility model (possibly simplified as GET-only))
  • candidate fragments returned as Web Annotation(s) that
    • target the indicated fragment
    • have a body that describes a candidate match (@@details TBD), including a reference to the matching fragment and any qualifying information (e.g. match before, match after, etc.)
    • a motivation that indicates the annotation designates a match
    • provenance about how the match was determined (personal annotaton, algorithm id, service reference, etc.)

Staying with the REST/LDP theme, the available compatibility model containers could themselves be enumerated in an LDP container linked from the compatibility service "API home" URI. Or maybe this container is the primary representation of the service?

I've considered here the response to a match being one match-per-annotation, which means the set of candidates would itself be a collection of some kind (an annoation container?). An alternaive might be multipk,e matches per anotation, but I feel it would be harder to leverage existing standards (e.g,. LDP, OA) for that.

This interface does not constrain how the service is implemented: your suggestion of linking fragments througn a shared concept could be an implementation and storage strategy, with the service retrieving appropriate stored responses for any given request. I do think it's important to have a uniform access interface for the remixer to access the compatibility service so that new models can be introduced without having to update the remixer code.

We also need to consider the context within which the compatibility service operates, and in particular how it knows about fragments to be considered. The current architecture diagram suggests that a working set is built from the outputs of a single NiN instance. But it may be a small step to have possibly more than one instance of NiN contributing, or a single instance feeding multiple working sets. Then, per the architecture diagram, there are two kinds of working set: one generated by NiN outputs, and another constructed using the remixer. The intent is to produce a unified structure for these so that for most purposes they are interchangeable.

@@TODO: add reference to definition/example when available

Matching Fragments interface:

Set of matches specified by:

  1. The fragment matching starts from

  2. The compatibility model selected

  3. The working set in use

How to reconcile this with LDP based architecture?

What does LDP give us?

Read/write model, but will anything be writing directly to a URI representing the combination of all 3 things?

Possible Key match representation

... @prefix nindata: http://numbersintonotes.net/meld/ @prefix key: http://purl.org/NET/c4dm/keys.owl#

a ldp:BasicContainer , ninre:WorkSet; ldp:contains , , .

a ninre:FragmentRef ; ninre:fragment nindata:d2cca69a-85f5-46c3-aded-cdb97f30199f .

a ninre:FragmentRef ; ninre:fragment nindata:a0007b2b-673c-4bf5-9ce1-aa98a1ea636a .

a ninre:FragmentRef ; ninre:fragment nindata:55a580ac-febb-49ee-b6c8-d2cca69a85f5 .

nindata:d2cca69a-85f5-46c3-aded-cdb97f30199f ninre:hasCompatibleKey key:AMinor .

nindata:55a580ac-febb-49ee-b6c8-d2cca69a85f5 nin:key key:AMinor .

Could maybe infer from this:

a oa:Annotation ; oa:hasTarget nindata:d2cca69a-85f5-46c3-aded-cdb97f30199f ; oa:hasBody [ a ninre:Match ; ninre:compatibilityType ninre:keyCompatibility ; ninre:matches nindata:55a580ac-febb-49ee-b6c8-d2cca69a85f5. ] .

Could we use oa:hasSource here?

  • A set of these could be delivered in an Annotation Container (LDP Container)

  • But I'm not sure what an Annotation Container really provides:

    • it doesn't facilitate filtering what annotations are returned
    • it allows updates, but if the annotation matches are a server generated resource then new ones wouldn't be posted to an AC, but to a container for the base data