cedadev/djcharme

CHARMe project node

djcharme

CHARMe project node

See the docs directory for information on installation, the interface and examples.

djcharme's Issues

Change login to use a username instead of e-mail address

Registration details should be changed to record a username and optionally an e-mail address. Login should be based on username + password, not e-mail + password

Multiple bodyID placeholders

All entities within the CHARMe model must have an associated URI. For things like datasets, and papers with a DOI, a suitable URI already exists. In the case of a text body, a citation, or a domain keyword tag, a new entity is created, and so a corresponding URI must also be created. The CHARMe Node handles this for text bodies by creating a UUID and appending it to a base URL for the host. Code on the node itself will scan incoming annotations for the 'BodyID' placeholder, and substitute a generated URI. The current system will only work for a single body however, so there needs to be a means of inserting multiple placeholders for unique generated body URIs for all body types (not just text bodies). This might be something like BodyID1, BodyID2, BodyID3 etc.

Moderation - /advance_status URI needs refactoring

/advance_status currently expects POST'd content but does not error check for GET requests but returns silently without changing the input annotation status

OpenSearch "status" parameter return HTTP503

Query like this one

http://charme-dev.cems.rl.ac.uk:8027/search/json-ld/?status=submitted

should return all the submitted annotations. Instead actually returns

503 - Service Unavailable
• list index out of range

Update Installation Guide, ICD and D400.3

The installation guide needs updating to reflect the changes for the end of iteration 3, particularly the integration of OAuth and the changes to the security filters. The ICD and D400.3 Encodings document also need review and update since now the node does not return a complete copy of the submitted content.

Modification of annotations that have been replied to

I create an annotation 'Blah', and reply to it with 'Reply to Blah'. Then I modify the first annotation so that it is now 'Babble'. But now, 'Reply to Blah' says that its target is still 'Blah', and searching for annotations against 'Babble' returns no results, i.e. it appears to have no replies ('Reply to Blah' is now only visible by searching against 'all targets'). This not only breaks the chain of conversation, but allows users to see an out-of-date version of an annotation. Can we keep the conversation chain unbroken?

Change in 'annotatedAt' response

When viewing annotations, the value of 'http://www.w3.org/ns/oa#annotatedAt' has changed. Whereas for older annotations one object is returned, newer annotations have an array of two objects, with one of them (the order is variable) being dummy data, e.g.:

Person object in annotation graphs

When viewing an individual annotation, the graph returned includes a Person object which contains "http://xmlns.com/foaf/0.1/accountName". However, when searching the annotations against a target, the graphs returned do not include accountName in their Person objects. Please include accountName every time.

Server Error on request to 'data' service

When requesting http://charme-dev.cems.rl.ac.uk/data/5b0958f20a4f412f859fa47b4580737a an error code 500 is received.

Headers below

Accept:application/ld+json, */*; q=0.01
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-GB,en-US;q=0.8,en;q=0.6
Connection:keep-alive
Host:charme-dev.cems.rl.ac.uk
Origin:http://uk-l8071mx1.groupinfra.com:8090
Referer:http://uk-l8071mx1.groupinfra.com:8090/DAV/js/charme/plugin/plugin.html?targetId=http%3A%2F%2Flocalhost%3A8090%2FDAV%2FNASA%2FChlorophyl%2F2003%2FMY1DMM_CHLORA_2003-01.JPEG
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36

Retrieve triples by target URI

Ability to request annotations by target ID

Invoking the advance_status service results in a 403 Forbidden

Invoking the advance_status service (http://charme-dev.cems.rl.ac.uk/advance_status) results in an http response code of 403
Request Headers:

POST http://charme-dev.cems.rl.ac.uk/advance_status HTTP/1.1
Host: charme-dev.cems.rl.ac.uk
Proxy-Connection: keep-alive
Content-Length: 63
Accept: application/json, text/javascript, */*; q=0.01
Origin: http://localhost:8080
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.57 Safari/537.36
Content-Type: application/json
Referer: http://localhost:8080/CHARMe_Plugin/plugin.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6

Request Body:

annotation=d578e6a0-3124-4f12-b2e5-d213b5b27a15&toState=invalid

Response Headers:

HTTP/1.0 403 Forbidden
Date: Fri, 30 Aug 2013 13:03:51 GMT
Server: Apache/2.2.15 (Red Hat)
Content-Type: text/html; charset=UTF-8
X-Cache: MISS from cache1.uk.logica.com
X-Cache-Lookup: MISS from cache1.uk.logica.com:3128
Via: 1.0 cache1.uk.logica.com (squid/3.1.19)
Connection: close

Response body:

...

  
Forbidden (403)
  
CSRF verification failed. Request aborted.




  
More information is available with DEBUG=True.

...

'Published' timestamp for annotations is not yet implemented

Returns a fixed timestamp - "TO_BE_DONE_2011-01-21T11:05:29.511Z"

DELETE is not allowed by Access-Control-Allow-Methods

DELETE request on an annotation receives the message
"Method DELETE is not allowed by Access-Control-Allow-Methods. "

The delete request is of the form

resource/(w+)
Action: Moves the resource to the 'retired' graph
HTTP Method: DELETE

for e.g.
https://charme-dev.cems.rl.ac.uk/resource/a2d23569a7ee475ba47303348104a023

Server Error on request to 'data' service

When requesting http://charme-dev.cems.rl.ac.uk/data/5b0958f20a4f412f859fa47b4580737a an error code 500 is received.

Headers below

Accept:application/ld+json, */*; q=0.01
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-GB,en-US;q=0.8,en;q=0.6
Connection:keep-alive
Host:charme-dev.cems.rl.ac.uk
Origin:http://uk-l8071mx1.groupinfra.com:8090
Referer:http://uk-l8071mx1.groupinfra.com:8090/DAV/js/charme/plugin/plugin.html?targetId=http%3A%2F%2Flocalhost%3A8090%2FDAV%2FNASA%2FChlorophyl%2F2003%2FMY1DMM_CHLORA_2003-01.JPEG
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36

Requesting facets returns unexpected results

Requesting the facets for a particular target returns unexpected results: motivations, domains of interest and organizations that do not match the annotations against that target, with some facets missing and other facets returned that shouldn't be, e.g.:

Port test service to new endpoint

Alter dev config to run over HTTPS.

Server Error on request to 'data' service

When requesting http://charme-dev.cems.rl.ac.uk/data/5b0958f20a4f412f859fa47b4580737a an error code 500 is received.

Headers below

Accept:application/ld+json, */*; q=0.01
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-GB,en-US;q=0.8,en;q=0.6
Connection:keep-alive
Host:charme-dev.cems.rl.ac.uk
Origin:http://uk-l8071mx1.groupinfra.com:8090
Referer:http://uk-l8071mx1.groupinfra.com:8090/DAV/js/charme/plugin/plugin.html?targetId=http%3A%2F%2Flocalhost%3A8090%2FDAV%2FNASA%2FChlorophyl%2F2003%2FMY1DMM_CHLORA_2003-01.JPEG
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36

Calling the the ‘resource’ service results in a circular redirect

After listing the submitted annotations on the Node, I attempt to retrieve the 'body' content for a given text annotation. The response from the server gives a circular redirect.

Eg.

GET http://charme-dev.cems.rl.ac.uk/resource/96af8f78c2a6 HTTP/1.1
Host: charme-dev.cems.rl.ac.uk
Proxy-Connection: keep-alive
Cache-Control: no-cache
Pragma: no-cache
Accept: application/ld+json, */*; q=0.01
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.57 Safari/537.36
Referer: http://localhost:8080/CHARMe_Plugin/plugin.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6

Yields a response of:

HTTP/1.0 303 See Other
Date: Fri, 30 Aug 2013 09:10:58 GMT
Server: Apache/2.2.15 (Red Hat)
Location: http://charme-dev.cems.rl.ac.uk/resource/96af8f78c2a6
Content-Length: 0
Content-Type: text/html; charset=utf-8
X-Cache: MISS from cache1.uk.logica.com
X-Cache-Lookup: MISS from cache1.uk.logica.com:3128
Via: 1.0 cache1.uk.logica.com (squid/3.1.19)
Connection: keep-alive

As some background, this annotation was created with the following json-ld:

[
     {
           "@id":"http://localhost/96af8f78c2a6",
           "@type":"http://www.w3.org/ns/oa#Annotation",
           "http://www.w3.org/ns/oa#hasBody":
           {
                "@id":"http://localhost/3cc0dd13ca30"
           },
           "http://www.w3.org/ns/oa#hasTarget":
           {
                "@id":"http://api.jquery.com/val/"
           }
     },
     {
           "@id":"http://localhost/3cc0dd13ca30",
           "@type":[
                "http://www.w3.org/2011/content#ContentAsText",
                "http://purl.org/dc/dcmitype/Text"
                ],
           "http://purl.org/dc/elements/1.1/format":"text/plain",
           "http://www.w3.org/2011/content#chars":"Some test text"
     }
]

I am aware that the id's for the annotation and body are not correct, as they should start with http://localhost/resource/\* instead of http://localhost/\* however I have since modified my code to generate correct id's and the same issue still occurs.

Date sorting 2: This time it's pagination

Sorting doesn't work with paging. It appears that the sorting is done after paging, so that each page is sorted, but the results overall aren't. Please apply sorting before paging.

Requesting secured URIs should result in redirect to authentication endpoint

Currently, if a secured URI is accessed a short message is displayed in the HTTP response with the URI to the authentication endpoint. Instead, the required behaviour is that the security middleware should automatically redirect the client to the authentication endpoint. The latter is a login form. This page itself should give a HTTP 401 Unauthorized response. This will enable non-browser based clients to trap the fact that an authentication step is needed.

Fetch citation metadata

Support for fetching citation metadata on the server side, and persisting this with the annotation. The citation metadata would then be returned along with the annotation for subsequent requests.

Need a way of registering a user

Currently annotation authors are recorded as a unique 'foaf:person' against new annotations. Need a web service for registering users separately. Can we separate this from authentication, so that we do not have to wait for authentication to be sorted out?

Exploded annotations in graphs

Currently, when viewing an annotation which has a target that is itself an annotation, the target annotation is exploded in the graph returned by the node. Please make it so that targets of type oa#Annotation are not exploded.

Fetching citation metadata on the server side

Support for fetching citation metadata on the server side, and persisting this with the annotation. The citation metadata would then be returned along with the annotation for subsequent requests.

Link classification tags

A user creates an annotation with a link to www.notanoperationreport.com, and selects type 'Operation Report'. After saving, he realises his mistake and so modifies the annotation, changing the type to 'Service Message'. However, if you now view the annotation, both classification tags, Operation Report and Service Message, will be displayed. So the user then deletes his annotation and starts again, but when viewing the new annotation, the Operation Report tag will still be displayed.

The erroneous tag is never removed from the system, which will be frustrating for the user. Can the node be made to recognise when a particular classification type for a given URL is only included in annotations that have been deleted, or that have been replaced by modified versions?

URL stored as both citation act and link

A user includes a link in an annotation. If the user selects type 'Journal Article' or 'Conference Paper', then it is treated as a citation act, otherwise it's just a link. Also, the same URL may be given different types, e.g. Alice's annotation includes a link to www.example.com and classifies it as Journal Article. Bob then includes the same link in his annotation but calls it a Conference Report. If you now view either Alice's or Bob's annotation, both classification tags - Journal Article and Conference Paper - will be displayed. So far so good.

But then Carol includes the same link and calls it a Technical Report, Dan's annotation calls it a Validation Report, and Erin calls it a Product User Manual. Now, viewing Alice's or Bob's annotation will still display only two tags: Journal Article and Conference Paper. Viewing the annotations by Carol, Dan or Erin will display three tags: Technical Report, Validation Report and Product User Manual. The node doesn't realise that the same URL has been given five different tags, and nor will this be clear to the user, who may be confused if for example they view Alice's annotation and then Carol's.

Can the node be made to recognise when a URL has been included as both a citation act and as an ordinary link?

Counting the annotations

We need a web service that returns a count of the number of annotations for a given target so that we can show the appropriate plugin icon.
We could use the same service as for 1. However I think it makes sense to have a separate web service that returns just an annotation count or something for each target. It will be less verbose, and thus quicker to fetch. [PJK: I think this is still just an extension of the OpenSearch interface rather a new WS]

Calling the "data" service for a publication annotation type results in a server 500 error

Request:

GET http://charme-dev.cems.rl.ac.uk/data/5b0958f20a4f412f859fa47b4580737a HTTP/1.1
Host: charme-dev.cems.rl.ac.uk
Proxy-Connection: keep-alive
Accept: application/ld+json, /; q=0.01
Origin: http://uk-l8071mx1.groupinfra.com:8090
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36
Referer: http://uk-l8071mx1.groupinfra.com:8090/DAV/js/charme/plugin/plugin.html?targetId=http%3A%2F%2Flocalhost%3A8090%2FDAV%2FNASA%2FChlorophyl%2F2003%2FMY1DMM_CHLORA_2003-01.JPEG
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6

Define a "depth" for the returned triples

Returning additional fields in the annotation list, so that it’s not necessary to fetch each one individually.

ICD search specification is missing "target" parameter

The "target" specifier for the open search service is implemented, but not documented in the ICD.
eg:
/search/[rdf|ttl|json-ld]?count={count?}&startPage={startPage?}&startIndex={startIndex?}&title={a0:title?}&status={a1:status?}&depth={depth?}

'Updated' and 'Published' dates are always 'today'

It seems that the results in the atom feed from the /search/ web service have funny dates associated with each of the entries. The two dates that are returned for each annotation are the 'updated' and 'published' dates, which seem to be the same, and are almost invariably today. I say almost invariably, I have at least one entry that is yesterday, but in either case, the annotations in question were created weeks ago. Could we please have the date that the annotations were created returned along with each annotation?

Additionally, I feel that this information should be stored against the annotations themselves via triples. The open annotation standard has provision to do this via the AnnotatedAt attribute - http://www.w3.org/ns/oa#d4e284