Re: Maximally Abstract Data Model

Hi Doug,
Tags are one kind of body.

If you look at http://www.openannotation.org/spec/core/core.html#Tagging
the tag is the object of hasBody.

Normally if you have multiple Tags to apply to the same target(s) you just
create multiple 'hasBody'.
Structures such as composite or list could be applied. So you could have a
composite to say that the Tags apply as a whole.

If you need to be more specific in terms of assignment Tag-Target I think
the appropriate thing is to have multiple annotations.
Unless you want to go into the business of structured bodies.

Hope it helps,
Paolo



On Thu, Oct 16, 2014 at 12:03 AM, Doug Schepers <schepers@w3.org> wrote:

> Hi, Rob, Paolo–
>
> Are tags/keywords considered to be part of the Body? If not, where do they
> belong, and how can you specify which Target they apply to? Are they also
> formatted as a list?
>
> FWIW, I think they should be part of the Body.
>
> Regards-
> -Doug
>
>
>
> On 10/15/14 3:19 PM, Robert Sanderson wrote:
>
>>
>> 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
>>
>
>
>


-- 
Dr. Paolo Ciccarese
Assistant Professor of Neurology, Harvard Medical School
Assistant in Neuroscience, Massachusetts General Hospital
Senior Information Scientist, MGH Biomedical Informatics Core

CONFIDENTIALITY NOTICE: This message is intended only for the addressee(s),
may contain information that is considered
to be sensitive or confidential and may not be forwarded or disclosed to
any other party without the permission of the sender.
If you have received this message in error, please notify the sender
immediately.