Re: [model] Proposal: Allow motivatedBy on SpecificResource

Hi, Rob, Randall–

On 7/5/15 8:15 PM, Robert Sanderson wrote:
>
> The problem is discovering the body/bodies of the annotation.  To map
> what you're suggesting in to the data model, it would be making
> sub-properties of hasBody to encapsulate all of the different roles that
> the body can play.
>
> So:
>
> {@type: Annotation
>   comment : {value: "A comment"},
>   tag : [ {value: "tag1"}, {value: "tag2"} ]
>   target : "http://cnn.com/"
> }
>
> One might also do the same for targets, of course, for example to
> determine which target is being compared to which, or is derived from
> which, etc.
>
> If there were a very small, easily enumerable set of roles that
> *everyone* would use then this could work ... but this just isn't the
> case. This resulted in the use of SKOS concepts for motivations that you
> see now.

The number and indeterminacy of the set of possible motivations does 
seem to make Bill's proposal problematic, though I see where he's coming 
from.


> And, as Randall says, in the privacy of your own implementation, you can
> do whatever you want for optimization.  The primary concern of the
> specification is interoperability between systems, not performance
> within a single closed system.

Something about this part bothered me, and I just put my finger on it.

We need to be careful that we don't put too much of a mismatch between a 
smart internal implementation model, and the interchange format (though 
I recognize this isn't necessarily what you said).

This isn't really just an interchange format; an interchange format is 
just for transfer of data between applications, in an import/export 
operation, and it doesn't have the kind of features or performance 
characteristics that an internal data model should have.

Our data model should ideally be used in the same way as an internal 
data model. It's the format in which the annotations are published to a 
server, and what's retrieved and consumed by clients; it's what's 
searched on, bundled into collections, and shared between services.

If the format is very different to what's done internally in an 
annotation client (or an annotation server), then each annotation 
retrieved will need to be transformed into the internal model (e.g. for 
performance reasons), which is expensive for each client, both in terms 
of performance, and for coding and maintenance.

We have a set of implementers at the table here; we should be taking 
advantage of their collective experience to design the data model in 
such a way that it is a compelling implementation target for annotation 
projects; otherwise, it increases the risk that the data model won't be 
adopted, or won't be interoperable.

Regards–
–Doug

Received on Thursday, 23 July 2015 15:27:12 UTC