Unable to have a graph as the body of an annotation

[azaroth42]

Requirement: Have an explicit named graph as the body of an annotation to provide a semantic, machine-readable "comment". This might be used to assign properties or relationships to the target.

Justification: In human language, a comment of "I like this" would be perfectly acceptable as the body of an annotation. In order to effectively express this concept in a semantic way, it could be encoded as a triple: fb:likes . In order to keep this triple separate from the annotation's triples, it needs to be in a separate graph.

Proposal:

Allow a named graph as the object of hasBody.

{
  "@id": "http://example.org/annos/1",
  "@type": "oa:Annotation",
  "body": {
    "@graph": {
    "@context" : "http://example.org/social/context.json",
    "@id" : "http://example.org/users/rob",
    "fb:likes": "http://example.com/logo.jpg"
    }
  },
  "target": "http://example.com/logo.jpg"
}

(JSON-LD playground link: http://tinyurl.com/jvurj2m)

[zoggy]

Your example looks like this could be implemented with motivations. Do you have another example ?

[azaroth42]

@zoggy -- Sure... the graph could be:

{
"@id": "uri/to/some/photo.jpg",
"foaf:depicts": ["person1", "person2", "person3"]
}

2015-02-18 telcon noted that it is possible to do now, without adding additional serialization specific tricks, by serializing the graph and using EmbeddedContent. Tagging defer until this is proven to be insufficient.

[azaroth42]

Closing without prejudice, given no further use cases or requirements.

[stain]

Not sure why this is called "Unable to have a graph as the body" as there should be nothing wrong with your proposed example anyway. In the default graph it would simply say

{
  "@id": "http://example.org/annos/1",
  "@type": "oa:Annotation",
  "body": "http://example.org/users/rob",
  "target": "http://example.com/logo.jpg"
}

That the graph http://example.org/users/rob happens to be included is just a convenience.

I think I agree on closing this though, as trying to formalize this is tricky with regards to annotation servers (we faced this issue in Annotopia) - as the client can use arbitrary @id for their graph without the graph content necessarily matching at all what you get if you resolve that URI. (This is covered by the RDF 1.1: On Semantics of RDF Datasets W3C note.)

[stain]

BTW, a simple way to avoid any potential graph name resolution issues for the semantics for the body here is to use an '@id' with a local # or urn:uuid: URI.