- From: gsergiu via GitHub <sysbot+gh@w3.org>
- Date: Tue, 21 Jun 2016 09:03:50 +0000
- To: public-annotation@w3.org
> Isn't this use case solved by just supplying a named graph that contains all of the metadata I think that the named graph can be a good solution to solve the issue. However, there are a few concerns regarding the "embedded structured data": 1. standard JSON parsers should be able to understand the body as an object that carries structured data. (currently `type:Dataset` and the missing of `id` or `source` is to be interpreted as structured data) 2. dc:description and dc:format would be recommended to describe the "payload", the metadata. 3. The "structured data" might be mapped to json using a jsonld context, but it could be simply embedded in the "value" using the original formating (e.g. xml). 4. The structured data shouldn't be mixed with regular body properties. (e.g. the header(body props)-payload ("structured-data") kind of structure should be used, becasue the body and the "structured" data have different schemas, and might have different formats (e.g. json body, xml payload)) 4. The schema needed to parse the "structured data" should be written (as URI) in the body object prefferably (i.e. json client should be able to send payload to a presentation layer that is able to render the data). PS: I realize now that the are 2 major approches: 1. map schema of the "structured data" to json, 2. or embedd using original format (e.g. text/xml) Main question: Should the standard support both approaches? I would say yes! For mapping schemas through jsonld context, the examples would be fairly similar to the 107: Extension Example 2. (if the mapping is made directly into the body and not in a named graph) BR, Sergiu -- GitHub Notification of comment by gsergiu Please view or discuss this issue at https://github.com/w3c/web-annotation/issues/309#issuecomment-227382300 using your GitHub account
Received on Tuesday, 21 June 2016 09:04:07 UTC