Examples towards Embedded Body discussion

Examples towards a discussion on the topic tomorrow morning at TPAC:

1.  Just a string literal:
    {"hasBody": "This is the comment"}

2.  String literal and Language
    {"hasBody": {"@value" : "This is the comment",
                         "@language": "en"}}

3.  String literal and format as data type
    {"hasBody": {"@value": "<span>This is the comment</span>",
                         "@type": "rdf:HTML"}}

4.  Embedded string, as a resource:
    {"hasBody": {"rdf:value": "This is the comment"}}

5.  Embedded String and format as media type
    {"hasBody": {"rdf:value": "<span>This is the comment</span>",
                         "dc:format": "text/html"}}

6.  Embedded String and language as property rather than tag
  {"hasBody": {"rdf:value": "This is the comment",
                       "dc:language": "en"}}

7.  Embedded String, format and language
   {"hasBody": {"rdf:value": "<span>This is the comment</span>",
                        "dc:format": "text/html",
                        "dc:language": "en"}}

8a.  Simple URI when string literals are not allowed (4-7)
    {"hasBody" : "http://example.org/index.html"}

8b.  Simple URI when string literals are allowed (1-3)
    {"hasBody" : {"@id": "http://example.org/index.html"}}


Notes:
* 7 cannot be done with @value/@type/@language, as RDF does not allow
datatype and language tag on the same literal.  Thus 7 is the only possible
model for when all three are required at once.
* 3 requires a URI for the format, whereas 5 and 7 require a media type
registration.  Some content may have neither, such as Markdown.
* For 1,2 and 3 the body is a literal. For 4, 5, 6 and 7 the body is a
resource.  Literals cannot have other properties associated with them, such
as creator, created date, or other provenance, and thus these must use the
resource pattern.  When the literal is used by itself (1-3), *it has no
provenance information* beyond that of the graph, which is likely not
correct.
* If the value of the string in 1-3 was a URI, then it is *not* the
resource identified by that URI, it is just a string that happens to look
like a URI.  For the URI case, it would have to be as per 8b.


The consideration is, in my opinion:

Does the simplicity of 1 outweigh the complexity of having to deal with all
of the options, and especially requiring the structure always be present
when the body is a resource with its own URI? If String literals are not
allowed, then the consistent pattern is that of 4 through 8a.  If they are,
then the client must deal with all 1-7 plus 8b.


Thanks, and see many of you tomorrow :)

Rob

-- 
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305