Re: Maximally Abstract Data Model

I think you're both agreeing :)

To re-express the last three axioms:

13. There is a resource which we call a Choice, which consists of some
number of other (somehow equivalent) resources, of which one should be
chosen.

14.  There is a resource which we call a Composite, which consists of some
number of other resources.

15.  There is a resource which we call a List, which consists of some
number of other resources in a specific order.


If that's clearer?


On Wed, Oct 15, 2014 at 3:56 PM, Jacob Jett <jgjett@gmail.com> wrote:

> Hi Ray,
>
> Going back to my juxtaposition example, the annotation needs the composite
> resource because it most faithfully communicates what the body is
> annotating -- the aggregation of the two resources. We still need to
> communicate what that composite is composed of so that the end user tool
> has enough information to actually fetch and render the target resources in
> the intended juxtaposition.
>
> Now there may be other ways of doing this, such as punting the aggregation
> part to some other model (like a collection model or whatnot). I'm not sure
> if that's on the table for discussion. I've certainly thought that much of
> the segmentation work in the model could be spun out because I have the
> same needs for arbitrary selectors in non-annotation contexts.
>
> Regards,
>
> On Wed, Oct 15, 2014 at 4:19 PM, Denenberg, Ray <rden@loc.gov> wrote:
>
>> Hi Jacob –
>>
>>
>>
>> I’m confused though -  if the composite is indeed a resource, why point
>> to the multiple components rather than to the single composite resource?
>>
>>
>>
>> In  15,  a list where order is significant, I can see need.
>>
>>
>>
>> But if the semantics of “composite” is that it is simply the union of the
>> components, what is the use case that requires pointing to the components
>> individually?
>>
>>
>>
>> Ray
>>
>>
>>
>> *From:* Jacob Jett [mailto:jgjett@gmail.com]
>> *Sent:* Wednesday, October 15, 2014 3:50 PM
>> *To:* Denenberg, Ray
>> *Cc:* Robert Sanderson; Web Annotation
>> *Subject:* Re: Maximally Abstract Data Model
>>
>>
>>
>> Hi Ray,
>>
>>
>>
>> This was one of the original use cases for composite. I think more
>> properly we might define it as an aggregate resource composed of multiple
>> resources. To steal from chemistry, a suspension would be a good analogy to
>> a composite resource.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Jacob
>>
>>
>>
>> On Wed, Oct 15, 2014 at 2:35 PM, Denenberg, Ray <rden@loc.gov> wrote:
>>
>> 14. A Composite is a set from which all of the resources should be used.
>>
>> 15. A List is an ordered set of resources, of which all should be used.
>>
>>
>>
>> I see “composite” as “composite resource”, in other words, it is itself a
>> resource, consisting of the “union” (if you will) of the other resources
>> which I would call “component resources”.
>>
>>
>>
>> (I don’t necessarily see “list” being modeled similarly.)
>>
>>
>>
>> Ray
>>
>>
>>
>>
>>
>> *From:* Robert Sanderson [mailto:azaroth42@gmail.com]
>> *Sent:* Wednesday, October 15, 2014 3:20 PM
>> *To:* Web Annotation
>> *Subject:* Maximally Abstract Data Model
>>
>>
>>
>>
>>
>> All,
>>
>>
>>
>> On the call today there was discussion about the data model, versus the
>> expression of the model using RDF, and then the serialization of that into
>> JSON-LD.
>>
>>
>>
>> To try and express the current abstract data model as simple statements...
>>
>>
>>
>> Annotation Baseline:
>>
>>
>>
>> 1. There is a resource which we call an Annotation, that typically
>> represents the linking between other resources.
>>
>> 2. Annotations have 0..n Body resources.
>>
>> 3. Annotations have 1..n Target resources.
>>
>> 4. Body resources are related to Target resources, and are typically
>> statements about the Target resources.
>>
>> 5. As separate resources, Annotations, Bodies and Targets have separate
>> properties, typically including provenance and descriptive metadata.
>>
>>
>>
>> Anchoring:
>>
>>
>>
>> 6.  We introduce a type of resource called a SpecificResource that
>> identifies a more specific entity (more constrained/specialized) than an
>> existing resource which is identified by a URI.
>>
>> 7.  SpecificResources have exactly 1 Source resource, that the
>> SpecificResource is more specific than (constrained/specialized from).
>>
>> 8.  The constraints on the SpecificResource are specified in 1..n
>> Specifier resources.
>>
>> 9.  A State is a type of Specifier that describes the state of a
>> resource, to allow the intended representation to be retrieved.
>>
>> 10. A Selector is a type of Specifier that describes part of a
>> representation of a resource.
>>
>> 11. A Style is a type of Specifier that describes how the resource should
>> be presented to the user.
>>
>>
>>
>> Multiplicity:
>>
>>
>>
>> 12. We introduce three methods of creating sets of resources.
>>
>> 13. A Choice is a set from which one resource should be selected for use.
>>
>> 14. A Composite is a set from which all of the resources should be used.
>>
>> 15. A List is an ordered set of resources, of which all should be used.
>>
>> 16. Multiplicity constructs can be used where-ever any resource can be
>> used.
>>
>>
>>
>>
>>
>> Additional statements welcome :)
>>
>>
>>
>> Rob
>>
>>
>>
>> --
>>
>> Rob Sanderson
>>
>> Technology Collaboration Facilitator
>>
>> Digital Library Systems and Services
>>
>> Stanford, CA 94305
>>
>>
>>
>
>


-- 
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305