[
https://issues.apache.org/jira/browse/STANBOL-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13169381#comment-13169381
]
Reto Bachmann-Gmür commented on STANBOL-414:
--------------------------------------------
Salut Florent!
The reason that the addpart method doesn add meta-data (<ci> :hasPart <part>)
is that some parts might just be internally used for inter-enhancement engine
exchange. For instance it can be prevented that multiple engines need to do the
NLP as the NLP result can be passed along the content-item as a part. I think
non-blob parts are hardly mentioned in the metadata.
I think having a URI for the ContentItem maked the design clearer, the
ci.getUri().getUnicodeString()-construct is the way to adapt the code were a
String is expected, but in general I think even the client code should deal
with UriRef instances rather than Strings. With the old approach one need to
create a UriRef from the string-id to access meta-information about the
resource in the meta-data graph, so the new design is avoiding `new
UriRef(ci.getId)` and introducing some `ci.getUri().getUnicodeString()`, with
the consolidation of the new api the latter construct should become seldom.
Cheers.
> Refactor EnhancementEngine to support contents with multiple related parts
> --------------------------------------------------------------------------
>
> Key: STANBOL-414
> URL: https://issues.apache.org/jira/browse/STANBOL-414
> Project: Stanbol
> Issue Type: Improvement
> Reporter: Reto Bachmann-Gmür
> Attachments:
> 0001-CLEREZZA-414-changed-ContentItem-interface-and-utili.patch
>
>
> Some notes from a discussion with Rupert and Olivier
> ContentItem
> - getBlob() returns a blob of type multipart/mime iff the ContentItem was
> created from a multipart/mime content
> - ci.getBlob() eq ci.getPart(0, Blob.class)
> - ci.getUri()+"_main" eq ci.getPartUri(0)
> Rest
> /enhancer
> /enhancer/engine/<engineId>
> /enhancer/chains/<chaiId>
> - 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
