Thanks for the pointer Walter.
I don't know Aperture for now, so if you can have a look and give some
pointers on it, it could be perfect !
++
On 10/20/2011 01:28 PM, Walter Kasper wrote:
Hi Florent
NMO is part of the Aperture framework and so (in principle) already
available by the Metaxa engine. In the current default configuration of
Metaxa (defined by the extractionregistry.xml file) the Aperture Mail
handler is not enabled. I never used it but I can have a look at it next
week whether there are special requisites necessary to adding the
handler and what RDF it produces. Then it should become accessible in
the ContentItems's metadata-graph in the same fashion as the other
Metaxa annotations.
Best regards,
Walter
florent andré wrote:
maybe this one : http://www.semanticdesktop.org/ontologies/nmo/
What do you think about that ? Others more suitable ?
++
On 10/20/2011 10:35 AM, florent andré wrote:
Hi,
Fabian, your memory is good and I actually work on such chains with the
help of Apache Camel EIP / route capabilities [1] (jira ticket and code
soon).
With camel Route you have a splitter [2] build in and as a counter part
an aggregator [3].
For both you can define particular split/aggregate business logic.
This idea will be not so hard to implement then :
>> One could also add some additional triples that link the attachment
with
>> the Mail and that the content of the Mail is available as a text and
>> html version.
There is some particular / recommended / standard type of triples for
describe :
- attachment graph is link to Mail graph
- content available as text and html
?
Thanks.
[1] : http://camel.apache.org/enterprise-integration-patterns.html
[2] : http://camel.apache.org/splitter.html
[3] : http://camel.apache.org/aggregator2.html
On 10/20/2011 09:07 AM, Fabian Christ wrote:
Hi,
if I remember correctly, we had the idea to allow different chains of
enhancement engines to be configured under different URLs. Maybe
Florent's use case is interesting for this. Florent could create an
engine that is able to split the different content types and then
start enhancement with different chains for each content type. If
chains can call other chains, it would be possible to define such
complex workflows for content enhancement.
Best,
- Fabian
2011/10/19 Rupert Westenthaler<[email protected]>:
Hi florent
I would create use two enhancement request
1. for the Text and
2. for the Attachment.
and then merge the returned RDF graphs with the enhancements. One
could also add some additional triples that link the attachment with
the Mail and that the content of the Mail is available as a text and
html version.
best
Rupert
On Wed, Oct 19, 2011 at 6:22 PM, florent andré
<[email protected]> wrote:
Hi Stanbolers !
Imagine a classical html mail with attachment.
This mail is in fact composed by (at least) 3 parts :
* text/plain mail body
* html mail body
* attachment.
One html mail + attachment can be considered as one CI - one piece of
information/knowledge send by a guy.
In fact, text plain and html will have (pretty much*) the same
metadatas and
keeping both is interesting :
- text plain for processing and annotations positions
- html for keep the source and be able to enhance the html with rdfa,
links,...
And attachment, will mostly have a different metadata, but this
metadatas
are in a way related to the mail body's one...
It could be domageable - IMO - to manage attachment and mail body
metadatas
in a totally disconnected way (aka two different Content Item).
Note that this usecase also match with CMS articles with files (pdf,
odt...)
to downloads for further reading.
And now the real question :
How can we manage nicely this kind of "composed things" ?
Insights are very welcome ! :)
Have a good day
++
* pretty much because when can imagine be able to extract some more
metatadas from html (color, font size, rdfa, ...)
--
| Rupert Westenthaler [email protected]
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
