[jira] [Updated] (STANBOL-481) Multi ContentPart RESTful API extensions

["Rupert Westenthaler (Updated) (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/STANBOL-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rupert Westenthaler updated STANBOL-481:
----------------------------------------

    Attachment: contentItemAsMultipartMime.txt

This provides detailed information on how ContentItems are serialized as Multipart MIME (see Attachment contentItemAsMultipartMime.txt).

NOTE that this describes all information of a ContentItem that can be serialized as Multipart MIME. Based on the parameters provided for the request some of such information might be filtered.


## ContentItem Multipart MIME format 

* "contentItem" is now used as "boundary" for the different parts of the ContentItem
* Content-Type of the response is "multipart/form-data; boundary=contentItem; charset=UTF-8". Note the inclusion of the "boundary" parameter!

### Metadata:

* If present this will be the first Part.
* Content is the serialized RDF Graph of the metadata. Basically the data currently returned by the Enhancer.
* "metadata" is used as name for this part 
* the URI of the contentItem is used as fileName

### Content

* If present this follows immediately to the metadata. If metadata are present this will be at the second position.
* The content is encoded as "multipart/alternate" - nested multipart.
* the boundary "contentParts" is used to separate different content versions
* the name is "content"
* no fileName is provided.

#### Content Versions

A single Content is parsed to the Enhancer, but this might be converted to other formats (e.g. "text/html" -> "text/plain") by EnhancementEngines. This alternate versions are added as ContentParts with the type Blob to the ContentItem.

All such Blobs are serialized as individual parts within the "multipart/alternate" with the name "content". They use the following properties:

* name: the URI of the contentPart
* Content-Type and charset as specified by the Blob
* Content: 1:1 copy of the InputStream provided by the Blob

Note that the metadata might (or might not) provide additional information about the Content Versions. This will be represented by triples using the URI of the contentPart as Subject.

### Other Information

ContentItem may include also content parts other than alternate versions of the Content. This are e.g. used to store metadata about the enhancement process (ExecutionMetadata and ExecutionPlan). If such contentParts are RDF graphs ( instances of Clerezza TripleCollection) they can also be added as parts of the content item.

* Other parts MUST always contained in a part with an index > of the "content". This also implies that the index > as of the "metadata"
* The URI of the content part is used as name
* The Content-Type - the RDF serialization format - will be the same as specified/used for the "metadata".
                
> Multi ContentPart RESTful API extensions
> ----------------------------------------
>
>                 Key: STANBOL-481
>                 URL: https://issues.apache.org/jira/browse/STANBOL-481
>             Project: Stanbol
>          Issue Type: Sub-task
>          Components: Enhancer
>            Reporter: Rupert Westenthaler
>            Assignee: Rupert Westenthaler
>         Attachments: contentItemAsMultipartMime.txt
>
>
> Sub-task about the implementation of the RESTful API extensions related to multipart content items
> Copied form the main Issue:
> - query params:
> Optional inputWithMetadata -> expects multipart/mime with 2 sections of which the first is rdf
> Optional outputWithContentParts[=<section-ordinal>] -> the result is multipart (instead of rdf) containing rdf as the first section and the parts in the second section, if there is more than one part this second section is itself multipart, this argument might be repated to have different sections
> Optional omitMetada -> no metadate in the result, makes only sense with outputContentParts argument, the result will correspond to the second section of the malipart returned without this argument 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira