Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

W3C annotation standard #117

Open
mfbalin opened this issue Nov 27, 2018 · 5 comments
Open

W3C annotation standard #117

mfbalin opened this issue Nov 27, 2018 · 5 comments
Labels
priority:high relation:android related to android platform relation:backend relation:frontend relation:wiki involves stuff about wiki section

Comments

@mfbalin
Copy link
Contributor

mfbalin commented Nov 27, 2018

We need to make a research about which features in the W3C standard we need
https://www.w3.org/annotation/

@eneskosr
Copy link
Contributor

@serdarada
Copy link
Contributor

There are a lot of resources which can be used for implementing a feature in w3c annotation model.

The first part of my comment is mainly for frontend team @bekir16 , @ramazanarslan

I believe our android and frontend implementations should use same resources to display annotations created by each other, so we both need to agree which ones we will be using.

After some research I think "Fragment Selector" (http://w3c.github.io/web-annotation/model/wd2/#fragment-selector) is most convenient item for our needs since we annotate part of image and text.

I also think keeping text annotations value inside the annotations instead of creating a resource id like we do for images.

I share a sample code snippet you can look into (There are 2 body items and 2 target items to show the differences for text and image, there will be one of each in actual annotation :) )

I believe we should finalize the format before implementing, so if you have anything to say, feel free to comment below.

{
  "@context": "http://www.w3.org/ns/anno.jsonld",
  "id": "http://example.org/anno1",
  "type": "Annotation",
  "creator": {
    "id": "http://example.org/user1",
    "type": "Person",
    "name": "My Pseudonym",
    "nickname": "pseudo",
  },
  "created": "2015-01-28T12:00:00Z",
  "modified": "2015-01-29T09:00:00Z",

  "body": {
    "id": "http://example.org/image1",
    "type": "Image"
    "format": "image/png"
  },
  "body": {
    "type": "TextualBody",
    "value": "Comment text",
    "format": "text/plain"
  },

 "target": {
    "source": "http://example.com/text",
    "selector": {
      "type": "FragmentSelector",
      "conformsTo": "http://tools.ietf.org/rfc/rfc5147",
      "value": "char=100,130"
    }
  }

 "target": {
    "source": "http://example.com/image",
    "selector": {
      "type": "FragmentSelector",
      "conformsTo": "http://www.w3.org/TR/media-frags/",
      "value": "xywh=25,25,50,50"
    }
  }
}

The following part is for backend team @cburakaygun @mfbalin @eneskosr

To clarify which memory-item we annotating the backend should provide IRI values of memory-title, memory-story, memory-media and comments.

Also, I would be glad if you please provide seperate endpoint for uploading annotation-media and annotation. (Because I had a lot of problems sending memory-media with other contents when creating memory posts. So I believe sending both image and text at one request is not fully stable. Maybe problems occur with Android Library I use to send requests. Nevertheless I believe this way is more convenient).

I believe you will create the 'id' , 'creator', 'created' and 'modified' elements so planning to form my request like below:

{
  "@context": "http://www.w3.org/ns/anno.jsonld",
  "type": "Annotation",
  "body": {
    "id": "http://example.org/image1",
    "type": "Image"
    "format": "image/png"
  },

 "target": {
    "source": "http://example.com/text",
    "selector": {
      "type": "FragmentSelector",
      "conformsTo": "http://tools.ietf.org/rfc/rfc5147",
      "value": "char=100,130"
    }
  }
}

@cburakaygun
Copy link
Contributor

cburakaygun commented Dec 31, 2018

Hello @serdarada,

Unfortunately, I saw your message just after I created an initial version of the Annotation Wiki Page today.

Here are some notes to consider:

  1. I modified the Requirements to state that only Memory-Story and Memory-Image can be annotated to simplify the process since we don't have much time left.
  2. created and modified keys are related to the resource the annotation belongs to, not the annotation itself. generated key is used for stating the time the annotation (serialization) is created/modified.
  3. For annotating Memory-Story, I think it is convenient to use api-endpoint for the related Memory-Post (e.g. http://history-backend.herokuapp.com/api/v1/memory_posts/1) since it is the same both for Android and Frontend. Since this api-endpoint is a JSON resource, using Text Quote Selector seems a better approach to me.

Also, I plan to implement a generic file-upload endpoint which can be used for uploading annotation media.

Have you done any work on annotations that conflicts with any of the situations I mentioned above? Also, I would like to hear any comments/suggestions regarding this message.

@serdarada
Copy link
Contributor

Hello @cburakaygun .

I can adapt my work to be in accordance with your model.

If we use api-endpoint for the related Memory-Post, in the case of Memory-Post have multiple Memory-Images how to we determine which image has been annotated?

Also thanks for the generic file-upload.

@cburakaygun
Copy link
Contributor

Api-endpoint will be used only for Memory-Story. Annotations for Memory-Story will have api-endpoint as target source and annotations for a Memory-Image will have that image's URL as target source.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority:high relation:android related to android platform relation:backend relation:frontend relation:wiki involves stuff about wiki section
Projects
None yet
Development

No branches or pull requests

8 participants