- 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