Re: Release time is upon us again

[Dileepa Jayakody]

On Fri 12. Aug 2022 at 15:33, Karl Wright  wrote:

> Please let us know of aRny tickets that were supposed to bored   Es was e
> worked on that
> haven't yet, BEFORE I spin a release candidate.  Thanks!
>
>
> Karl
>
R

[jira] [Commented] (CONNECTORS-1181) Apache Stanbol Transformation Connector

[Dileepa Jayakody (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15363958#comment-15363958
 ] 

Dileepa Jayakody commented on CONNECTORS-1181:
--

Hi [~daddywri]

Unfortunately, I still couldn't find time to work on the stanbol client merge. 
So no progress yet on this jira.

Regards,
Dileepa

> Apache Stanbol Transformation Connector
> ---
>
> Key: CONNECTORS-1181
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1181
> Project: ManifoldCF
>  Issue Type: Wish
>Affects Versions: ManifoldCF 1.8.2, ManifoldCF 2.0.2
>Reporter: Rafa Haro
>Assignee: Rafa Haro
>Priority: Minor
>  Labels: connect, transformation
> Fix For: ManifoldCF 2.5
>
>
> Apache Stanbol (https://stanbol.apache.org/) provides a set of reusable 
> components for semantic content management. One of this component is the 
> Enhancer (https://stanbol.apache.org/docs/trunk/components/enhancer/) which 
> allows to extract features and semantic metadata from textual content like 
> entities/concepts from domain ontologies, named entities and so on.
> Apache Stanbol provides an easy-to-use REST API. The main idea behind this 
> transformation connector would be to enrich the Repository Document's 
> (string) content with a configured Stanbol processing chain. The 
> Transformation Connector would allow the user to configure the metadata that 
> will be extracted from the Enhancer result for including it as RD's metadata
> This behavior come to somehow replace the functionality of the old Apache 
> Stanbol CMS Adapter 
> (https://stanbol.apache.org/docs/trunk/components/cmsadapter/) and ContentHub 
> (https://stanbol.apache.org/docs/trunk/components/contenthub/)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CONNECTORS-1181) Apache Stanbol Transformation Connector

[Dileepa Jayakody (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15160277#comment-15160277
 ] 

Dileepa Jayakody commented on CONNECTORS-1181:
--

Hi Karl,

I had a chat with [~rafaharo] on managing and deploying the stanbol client 
artifacts to maven central. Currently I'm using jaxrs-1.1 branch of the client 
and my initial plan was to deploy those artifacts to central so that stanbol 
transformation connector build will be stable.
But Rafa suggested we may need to first merge that branch with master branch 
and resolve the conflicts as both branches have updates and then deploy the 
artifacts from master branch. This also requires changing the versions of the 
client dependency in Stanbol connector and test. 

I couldn't find some time to look into this task yet, and probably will not be 
able to do it within coming 2 weeks due to some other engagements. I will talk 
with Rafa on this and deploy the artifacts ASAP and get back to you.

Thanks,
Dileepa

> Apache Stanbol Transformation Connector
> ---
>
> Key: CONNECTORS-1181
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1181
> Project: ManifoldCF
>  Issue Type: Wish
>Affects Versions: ManifoldCF 1.8.2, ManifoldCF 2.0.2
>Reporter: Rafa Haro
>Assignee: Rafa Haro
>Priority: Minor
>  Labels: connect, transformation
> Fix For: ManifoldCF 2.4
>
>
> Apache Stanbol (https://stanbol.apache.org/) provides a set of reusable 
> components for semantic content management. One of this component is the 
> Enhancer (https://stanbol.apache.org/docs/trunk/components/enhancer/) which 
> allows to extract features and semantic metadata from textual content like 
> entities/concepts from domain ontologies, named entities and so on.
> Apache Stanbol provides an easy-to-use REST API. The main idea behind this 
> transformation connector would be to enrich the Repository Document's 
> (string) content with a configured Stanbol processing chain. The 
> Transformation Connector would allow the user to configure the metadata that 
> will be extracted from the Enhancer result for including it as RD's metadata
> This behavior come to somehow replace the functionality of the old Apache 
> Stanbol CMS Adapter 
> (https://stanbol.apache.org/docs/trunk/components/cmsadapter/) and ContentHub 
> (https://stanbol.apache.org/docs/trunk/components/contenthub/)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CONNECTORS-1181) Apache Stanbol Transformation Connector

[Dileepa Jayakody (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15144034#comment-15144034
 ] 

Dileepa Jayakody commented on CONNECTORS-1181:
--

Hi Karl,

I will proceed with the process to deploy the dependency to maven central and 
get back to you when it's deployed there.

Thanks,
Dileepa

> Apache Stanbol Transformation Connector
> ---
>
> Key: CONNECTORS-1181
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1181
> Project: ManifoldCF
>  Issue Type: Wish
>Affects Versions: ManifoldCF 1.8.2, ManifoldCF 2.0.2
>Reporter: Rafa Haro
>Assignee: Rafa Haro
>Priority: Minor
>  Labels: connect, transformation
> Fix For: ManifoldCF 2.4
>
>
> Apache Stanbol (https://stanbol.apache.org/) provides a set of reusable 
> components for semantic content management. One of this component is the 
> Enhancer (https://stanbol.apache.org/docs/trunk/components/enhancer/) which 
> allows to extract features and semantic metadata from textual content like 
> entities/concepts from domain ontologies, named entities and so on.
> Apache Stanbol provides an easy-to-use REST API. The main idea behind this 
> transformation connector would be to enrich the Repository Document's 
> (string) content with a configured Stanbol processing chain. The 
> Transformation Connector would allow the user to configure the metadata that 
> will be extracted from the Enhancer result for including it as RD's metadata
> This behavior come to somehow replace the functionality of the old Apache 
> Stanbol CMS Adapter 
> (https://stanbol.apache.org/docs/trunk/components/cmsadapter/) and ContentHub 
> (https://stanbol.apache.org/docs/trunk/components/contenthub/)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Ingestion of multimedia files in manifoldcf

[Dileepa Jayakody]

Hi All,

We are planning to integrate MICO : Media In Context
 , as a mcf transformation connector to
perform cross media analysis as part of enterprise cross media search in
our project.

The connector may require to send multimedia files to a MICO endpoint and
retrieve semantic metadata. These files could be images, videos, audios and
text files from different content repositories.

Can we please know how feasible it is to ingest large multimedia files
using ManifoldCF?

Thanks,
Dileepa

-- 

--
This message should be regarded as confidential. If you have received this 
email in error please notify the sender and destroy it immediately. 
Statements of intent shall only become binding when confirmed in hard copy 
by an authorised signatory.

Zaizi Ltd is registered in England and Wales with the registration number 
6440931. The Registered Office is Brook House, 229 Shepherds Bush Road, 
London W6 7AN. 

Re: ManifoldCF transformation connector for Apache Stanbol

[Dileepa Jayakody]

Hi All,

I have done the discussed modifications to the Stanbol connector. Now the
users can either define dereference fields or define a LDPath program to
extract entity properties from Stanbol entities and add them to the
document as fields.

The latest code is available here for your review:
https://github.com/zaizi/sensefy-connectors/tree/feature/SENSEFY-1453-modify-stanbol-connector/transformation/mcf-stanbol-connector

I have also written a blog post on how to configure the connector:
http://dileepajayakody.blogspot.com/2016/01/enhancing-documents-in-apache.html

Looking forward to your comments.

Thanks,
Dileepa


On Mon, Dec 14, 2015 at 1:18 PM, Rafa Haro <rh...@apache.org> wrote:

> Hi Karl,
>
> I will import this one, don't worry.
>
> Cheers,
> Rafa
> El El sáb, 12 dic 2015 a las 20:36, Dileepa Jayakody <djayak...@zaizi.com>
> escribió:
>
> > Hi Karl,
> >
> > Yes, I will improve the code with Rafa's reviews and then we can import
> it
> > to mcf code base.
> >
> > Thanks
> > Dileepa
> >
> > On Sat, Dec 12, 2015 at 5:26 PM, Karl Wright <daddy...@gmail.com> wrote:
> >
> > > Ok, it seems premature for me to try to import this from Github today,
> so
> > > I'll wait until the dust settles a bit further first.
> > >
> > > Karl
> > >
> > >
> > > On Fri, Dec 11, 2015 at 1:45 PM, Dileepa Jayakody <djayak...@zaizi.com
> >
> > > wrote:
> > >
> > > > Thanks a lot Rafa for pointing that out. big miss as  I didn't test
> the
> > > > LDPath configuration part yet. More improvements to be done.
> > > > I will do the required mprovements as pointed out.
> > > >
> > > > Regards,
> > > > Dileepa
> > > >
> > > >
> > > > On Fri, Dec 11, 2015 at 8:42 PM, Rafa Haro <rh...@apache.org> wrote:
> > > >
> > > > > Hi Dileepa,
> > > > >
> > > > > The problem is not in that part on the code, it is rather on this
> > part:
> > > > >
> > > > > if (entity != null) { Collection properties = entity.
> > > > > getProperties(); for (String property : properties) { String
> > > > > targetFieldName = derefFields.get(property); Set
> propValues =
> > > > > entityPropertyMap.get(targetFieldName); if (propValues == null) {
> > > > > propValues = new HashSet(); } Collection
> > > > entityPropValues =
> > > > > entity.getPropertyValues(property);
> > > propValues.addAll(entityPropValues);
> > > > > entityPropertyMap.put(targetFieldName, propValues); } }
> > > > > You are collecting from the EnhancementStructure response just only
> > the
> > > > > configured dereferenced fields and LDPath fields are ignored. Also,
> > > there
> > > > > is a potential bug in that code if there is no dereferencing field
> > > > > configured for a certain entity property here:
> > > > >
> > > > > String targetFieldName = derefFields.get(property);
> > > > >
> > > > > targetFieldName would be Null then. Instead of trying to index
> every
> > > > > property, you should just collect the configured ones by the user
> (or
> > > at
> > > > > least, if the user wants all of them, provide a configuration
> option
> > > for
> > > > > that).
> > > > >
> > > > > Anyway, going back to LDPath issue, please take into account that
> > when
> > > > you
> > > > > define a field you must use a custom Namespace and Prefix for later
> > > being
> > > > > able to retrieve that property from the entity. If you don't do
> that,
> > > > > Stanbol will provide a random namespace for that property. Check
> this
> > > > > example from RedLink SDK:
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/redlink-gmbh/redlink-java-sdk/blob/master/src/test/java/io/redlink/sdk/AnalysisTest.java#L423-443
> > > > >
> > > > > Hope that helps
> > > > >
> > > > > On Fri, Dec 11, 2015 at 3:57 PM Karl Wright <daddy...@gmail.com>
> > > wrote:
> > > > >
> > > > > > The next step would be to pull this code into an svn branch.
> This
> > is
> > > > > > something I can tackled after the 2.3 release candidate is put
> 

Re: ManifoldCF transformation connector for Apache Stanbol

[Dileepa Jayakody]

Hi Karl,

Yes, I will improve the code with Rafa's reviews and then we can import it
to mcf code base.

Thanks
Dileepa

On Sat, Dec 12, 2015 at 5:26 PM, Karl Wright <daddy...@gmail.com> wrote:

> Ok, it seems premature for me to try to import this from Github today, so
> I'll wait until the dust settles a bit further first.
>
> Karl
>
>
> On Fri, Dec 11, 2015 at 1:45 PM, Dileepa Jayakody <djayak...@zaizi.com>
> wrote:
>
> > Thanks a lot Rafa for pointing that out. big miss as  I didn't test the
> > LDPath configuration part yet. More improvements to be done.
> > I will do the required mprovements as pointed out.
> >
> > Regards,
> > Dileepa
> >
> >
> > On Fri, Dec 11, 2015 at 8:42 PM, Rafa Haro <rh...@apache.org> wrote:
> >
> > > Hi Dileepa,
> > >
> > > The problem is not in that part on the code, it is rather on this part:
> > >
> > > if (entity != null) { Collection properties = entity.
> > > getProperties(); for (String property : properties) { String
> > > targetFieldName = derefFields.get(property); Set propValues =
> > > entityPropertyMap.get(targetFieldName); if (propValues == null) {
> > > propValues = new HashSet(); } Collection
> > entityPropValues =
> > > entity.getPropertyValues(property);
> propValues.addAll(entityPropValues);
> > > entityPropertyMap.put(targetFieldName, propValues); } }
> > > You are collecting from the EnhancementStructure response just only the
> > > configured dereferenced fields and LDPath fields are ignored. Also,
> there
> > > is a potential bug in that code if there is no dereferencing field
> > > configured for a certain entity property here:
> > >
> > > String targetFieldName = derefFields.get(property);
> > >
> > > targetFieldName would be Null then. Instead of trying to index every
> > > property, you should just collect the configured ones by the user (or
> at
> > > least, if the user wants all of them, provide a configuration option
> for
> > > that).
> > >
> > > Anyway, going back to LDPath issue, please take into account that when
> > you
> > > define a field you must use a custom Namespace and Prefix for later
> being
> > > able to retrieve that property from the entity. If you don't do that,
> > > Stanbol will provide a random namespace for that property. Check this
> > > example from RedLink SDK:
> > >
> > >
> > >
> >
> https://github.com/redlink-gmbh/redlink-java-sdk/blob/master/src/test/java/io/redlink/sdk/AnalysisTest.java#L423-443
> > >
> > > Hope that helps
> > >
> > > On Fri, Dec 11, 2015 at 3:57 PM Karl Wright <daddy...@gmail.com>
> wrote:
> > >
> > > > The next step would be to pull this code into an svn branch.  This is
> > > > something I can tackled after the 2.3 release candidate is put
> > together.
> > > >
> > > > Thanks,
> > > > Karl
> > > >
> > > >
> > > > On Fri, Dec 11, 2015 at 9:07 AM, Dileepa Jayakody <
> djayak...@zaizi.com
> > >
> > > > wrote:
> > > >
> > > > > Hi Rafa,
> > > > >
> > > > > Thanks for reviewing my code and for your feedback. Please see my
> > > > comments
> > > > > inline below.
> > > > >
> > > > >
> > > > > On Fri, Dec 11, 2015 at 6:51 PM, Rafa Haro <rh...@apache.org>
> wrote:
> > > > >
> > > > > > Hi Dileepa,
> > > > > >
> > > > > > This seems to be going in the right direction clearly now in my
> > > > opinion.
> > > > > > Quick comments after a first review:
> > > > > >
> > > > > >
> > > > > >- Rejecting a document because it can't be enhanced is kind of
> > > > tough.
> > > > > >You are preventing a document to be finally indexed because
> the
> > > > > > enhancement
> > > > > >didn't perform correctly, probably it is better just to let
> them
> > > > > > continue
> > > > > >the workflow within the system
> > > > > >
> > > > >
> > > > > Got your point. Will remove that part from the code
> > > > >
> > > > >
> > > > > >- As I can deduce for the code, you are correctly extract

Re: ManifoldCF transformation connector for Apache Stanbol

[Dileepa Jayakody]

Hi All,

As per our discussion I have modified the Stanbol Connector so that it adds
all extracted entity URIs and entity attributes to the repository document
as fields.

On a separate branch I have committed this code to our github project
sensefy-connectors.
You can find the source code here:
https://github.com/zaizi/sensefy-connectors/tree/feature/SENSEFY-1453-modify-stanbol-connector/transformation/mcf-stanbol-connector
Let me know your feedback.

I will write a blog post on how to add it in a connection and get
ehancement results and share it with you.

Thanks,
Dileepa



On Mon, Dec 7, 2015 at 6:29 PM, Karl Wright <daddy...@gmail.com> wrote:

> Hi Dileepa,
>
> You cannot create sub-documents in a transformation connector.  And adding
> that capability to the framework is not possible; we would be missing key
> bookkeeping logic if that was allowed.
>
> Karl
>
>
> On Mon, Dec 7, 2015 at 6:59 AM, Dileepa Jayakody <djayak...@zaizi.com>
> wrote:
>
> > Hi Karl,
> >
> > Thanks a lot for the pointer.
> >
> > Stanbol doesn't update an existing document, it generates a new response
> > with requested enhancement details for the content enhansment request.
> > For example for a request like : "Paris is a city in France" following
> RDF
> > response [1] is given by Stanbol.
> >
> > In the Stanbol connector, enhancement artifacts such as TextAnnotations
> > and EntityAnnotations are extracted from the RDF response, to generate
> the
> > entity abstractions and add them to the mcf repository document.
> Currently
> > in the Stanbol connector we have added these entity abstractions as JSON
> > strings to a multi-valued 'entities' field in the repository document and
> > we parse that JSON in the SolrWrapper output connector to index in
> separate
> > Solr cores (primary documents, linked entities and entity types with
> their
> > attributes).
> >
> > Can we can have a primary repository document and create sub documents
> for
> > the extracted entities? Is it possible to generate sub documents for a
> > repo-document in a transformation connector?
> >
> > Thanks.
> > Dileepa
> >
> > [1] Sample Stanbol response
> >
> > {
> >   "@context": {
> > "dbp-ont": "http://dbpedia.org/ontology/;,
> > "dc": "http://purl.org/dc/terms/;,
> > "dc:created": {
> >   "@type": "xsd:dateTime"
> > },
> > "enhancer": "http://fise.iks-project.eu/ontology/;,
> > "enhancer:confidence": {
> >   "@type": "xsd:double"
> > },
> > "enhancer:end": {
> >   "@type": "xsd:int"
> > },
> > "enhancer:entity-reference": {
> >   "@type": "@id"
> > },
> > "enhancer:entity-type": {
> >   "@type": "@id"
> > },
> > "enhancer:extracted-from": {
> >   "@type": "@id"
> > },
> > "enhancer:start": {
> >   "@type": "xsd:int"
> > },
> > "entityhub": "
> http://stanbol.apache.org/ontology/entityhub/entityhub#
> > ",
> > "foaf": "http://xmlns.com/foaf/0.1/;,
> > "foaf:depiction": {
> >   "@type": "@id"
> > },
> > "owl": "http://www.w3.org/2002/07/owl#;,
> > "rdfs": "http://www.w3.org/2000/01/rdf-schema#;,
> > "schema": "http://schema.org/;,
> > "xsd": "http://www.w3.org/2001/XMLSchema#;
> >   },
> >   "@graph": [
> > {
> >   "@id": "http://dbpedia.org/resource/France;,
> >   "@type": [
> > "dbp-ont:Country",
> > "dbp-ont:Place",
> > "dbp-ont:PopulatedPlace",
> > "http://www.opengis.net/gml/_Feature;,
> > "owl:Thing",
> > "schema:Country",
> > "schema:Place"
> >   ],
> >   "foaf:depiction": [
> > "
> > http://upload.wikimedia.org/wikipedia/commons/c/c3/Flag_of_France.svg;,
> > "
> >
> http://upload.wikimedia.org/wikipedia/commons/thumb/c/c3/Flag_of_France.svg/200px-Flag_of_France.svg.png
> > "
> >   ],
> >   "rdfs:comment": 

Re: ManifoldCF transformation connector for Apache Stanbol

[Dileepa Jayakody]

Thanks a lot Rafa for pointing that out. big miss as  I didn't test the
LDPath configuration part yet. More improvements to be done.
I will do the required mprovements as pointed out.

Regards,
Dileepa


On Fri, Dec 11, 2015 at 8:42 PM, Rafa Haro <rh...@apache.org> wrote:

> Hi Dileepa,
>
> The problem is not in that part on the code, it is rather on this part:
>
> if (entity != null) { Collection properties = entity.
> getProperties(); for (String property : properties) { String
> targetFieldName = derefFields.get(property); Set propValues =
> entityPropertyMap.get(targetFieldName); if (propValues == null) {
> propValues = new HashSet(); } Collection entityPropValues =
> entity.getPropertyValues(property); propValues.addAll(entityPropValues);
> entityPropertyMap.put(targetFieldName, propValues); } }
> You are collecting from the EnhancementStructure response just only the
> configured dereferenced fields and LDPath fields are ignored. Also, there
> is a potential bug in that code if there is no dereferencing field
> configured for a certain entity property here:
>
> String targetFieldName = derefFields.get(property);
>
> targetFieldName would be Null then. Instead of trying to index every
> property, you should just collect the configured ones by the user (or at
> least, if the user wants all of them, provide a configuration option for
> that).
>
> Anyway, going back to LDPath issue, please take into account that when you
> define a field you must use a custom Namespace and Prefix for later being
> able to retrieve that property from the entity. If you don't do that,
> Stanbol will provide a random namespace for that property. Check this
> example from RedLink SDK:
>
>
> https://github.com/redlink-gmbh/redlink-java-sdk/blob/master/src/test/java/io/redlink/sdk/AnalysisTest.java#L423-443
>
> Hope that helps
>
> On Fri, Dec 11, 2015 at 3:57 PM Karl Wright <daddy...@gmail.com> wrote:
>
> > The next step would be to pull this code into an svn branch.  This is
> > something I can tackled after the 2.3 release candidate is put together.
> >
> > Thanks,
> > Karl
> >
> >
> > On Fri, Dec 11, 2015 at 9:07 AM, Dileepa Jayakody <djayak...@zaizi.com>
> > wrote:
> >
> > > Hi Rafa,
> > >
> > > Thanks for reviewing my code and for your feedback. Please see my
> > comments
> > > inline below.
> > >
> > >
> > > On Fri, Dec 11, 2015 at 6:51 PM, Rafa Haro <rh...@apache.org> wrote:
> > >
> > > > Hi Dileepa,
> > > >
> > > > This seems to be going in the right direction clearly now in my
> > opinion.
> > > > Quick comments after a first review:
> > > >
> > > >
> > > >- Rejecting a document because it can't be enhanced is kind of
> > tough.
> > > >You are preventing a document to be finally indexed because the
> > > > enhancement
> > > >didn't perform correctly, probably it is better just to let them
> > > > continue
> > > >the workflow within the system
> > > >
> > >
> > > Got your point. Will remove that part from the code
> > >
> > >
> > > >- As I can deduce for the code, you are correctly extracting the
> > > >configured dereferenced fields, but you are not processing at all
> > the
> > > >LDPath results
> > > >
> > > > I'm passing the LDPath program as an enhancer parameter to Stanbol to
> > > retrieve the enhancement result according to the LDPath program (which
> is
> > > given as a text string in the connector UI).
> > > If the user has not defined a LDPath program and added derefence fields
> > in
> > > the UI instead, then the enhancement request will be built using the
> > > dereference fields as enhancer parameters.
> > >
> > >
> > > If neither a LDPath or dereference fields are given in the
> transformation
> > > UI, then I just call the given enhancement chain without any other
> > enhancer
> > > paramaters.
> > >
> > > Please refer below code segment where I do this and let me know if it
> > needs
> > > more improvements.
> > >
> > > // ldpath program is given priority if it's set
> > > if (ldPath != null)
> > > {
> > > parameters =
> > >
> > >
> >
> EnhancerParameters.builder().setChain(chain).setContent(content).setLDpathProgram(ldPath).build();
> > > }
> > > 

Re: ManifoldCF transformation connector for Apache Stanbol

[Dileepa Jayakody]

Hi All,


While thanking you all for your input on Stanbol connector requirement, I
would like to continue with modifying the Stanbol connector to be
compatible with any output connector. If you guys can give some guidance on
how the entity metadata should be added to the repository document I can
modify the stanbol connector accordingly.

>From Rafa's comments, I gathered we can add the entity metadata to the
repo.doc as key value pairs.
However this idea is not yet clear to me. There could be 'N' number of
entities in a document and each of them will have some common attributes
such as name, id, type and specific attributes for particular entity type.
I'm not clear on how to maintain that structure of N number of entities
with their attributes in a repo.document as key value pairs and make them
LDPath compatible for retrieval in an output connector.

@Rafa
If you can please elaborate on your suggestion it would be greatly helpful
to me.
All other suggestions are also welcome.

Thanks,
Dileepa


On Fri, Nov 13, 2015 at 7:00 PM, Karl Wright <daddy...@gmail.com> wrote:

> I, too, agree.  Somebody will need to turn this connector into one that
> plays by the rules.  It may be possible for someone on the team here to do
> that, but it won't be me; I'm seriously overextended at the moment.  It
> would be best if someone who knew the connector well could do the necessary
> work.
>
> Karl
>
>
> On Fri, Nov 13, 2015 at 5:45 AM, Rafa Haro <rharoapa...@gmail.com> wrote:
>
> > I must agree with Antonio. When I started to work on this I was expecting
> > the connector to work by just extracting the entities and entities
> metadata
> > and put them as plain metadata of the documents, probably following
> LDPATH
> > queries configuration
> >
> >
> >
> >
> > This is probably ok for Sensefy but I don’t think this could be suitable
> > to be included in the project. But this is only my opinion. Of course, a
> > version of the connector that fully respect the ManifoldCF architecture
> > would be more than welcome in my opinion
> >
> > On Fri, Nov 13, 2015 at 11:38 AM, Antonio David Pérez Morales
> > <adperezmora...@gmail.com> wrote:
> >
> > > Hi
> > > The removal of the SolrWrapper is a must. It was a requirement for an
> > > internal project which has nothing to do here with a normal operation
> of
> > > Manifold, so forcing the users to use Solr does not fit the Manifold
> > > philosophy.
> > > In my opinion, at this moment, a Stanbol connector with such a big
> > > dependency which will not fit almost any use case is not very useful.
> > > You should think a way to convert Stanbol connector into a normal
> > > Transformation connector without assuming that a specific output
> > connector
> > > will be used.
> > > Regards
> > > 2015-11-13 11:20 GMT+01:00 Dileepa Jayakody <djayak...@zaizi.com>:
> > >> Hi guys,
> > >>
> > >> I have developed a Stanbol connector for MCF. You can check it out
> from
> > our
> > >> github repo here:
> > >>
> > >>
> >
> https://github.com/zaizi/sensefy-connectors/tree/master/transformation/mcf-stanbol-connector
> > >>
> > >> It requires the SolrWrapper output connector which indexes enhanced
> > >> documents, entities and entityTypes in separate Solr cores. Basically
> it
> > >> requires 3 separate solr cores configured with a specific Solr schema
> > for
> > >> primary documents, entities and entityTypes separately. This was done
> > for
> > >> our specific use-case.
> > >>
> > >> The SolrWrapper code is here :
> > >>
> > >>
> >
> https://github.com/zaizi/sensefy-connectors/tree/master/output/mcf-solrwrapperconnector
> > >>
> > >> Perhaps we can discuss and remove the Stanbol connector's dependency
> > with
> > >> SolrWrapper and have it working with any output connector.
> > >> Please note that the Stanbol connector currently has a bug in the UI
> > >> (editSpecification) which I'm working on at the moment. After fixing
> > that I
> > >> will update here. And also I will provide documentations for
> configuring
> > >> the connector.
> > >>
> > >> Thanks,
> > >> Dileepa
> > >>
> > >> On Thu, Jul 9, 2015 at 8:36 PM, Antonio David Pérez Morales <
> > >> adperezmora...@gmail.com> wrote:
> > >>
> > >> > Hi Joshua
> > >> >
> > >> > It is not the list for that, but

Re: ManifoldCF transformation connector for Apache Stanbol

[Dileepa Jayakody]

e limits
largely unchanged since 1860, has an estimated population of 2,211,297
and a metropolitan population of 12,089,098, and is one of the most
populated metropolitan areas in Europe."
  },
  "rdfs:label": [

{
  "@language": "en",
  "@value": "Paris"
},
{
  "@language": "fr",
  "@value": "Paris"
},
  ]
},
   }
{
  "@id": "urn:enhancement-8db13707-1ecd-b4df-90ad-52447c8f2c84",
  "@type": [
"enhancer:Enhancement",
"enhancer:TextAnnotation"
  ],
  "dc:created": "2015-12-07T11:22:07.740Z",
  "dc:creator":
"org.apache.stanbol.enhancer.engines.opennlp.impl.NamedEntityExtractionEnhancementEngine",
  "dc:type": "dbp-ont:Place",
  "enhancer:confidence": 0.6017613,
  "enhancer:end": 5,
  "enhancer:extracted-from":
"urn:content-item-sha1-c8ae372ed26679df14da13050dd432fd32c527e3",
  "enhancer:selected-text": {
"@language": "en",
"@value": "Paris"
  },
  "enhancer:selection-context": {
"@language": "en",
"@value": "Paris is in France"
  },
  "enhancer:start": 0
},
{
  "@id": "urn:enhancement-b282-0e46-62f5-cd33-9f84ab32e547",
  "@type": [
"enhancer:Enhancement",
"enhancer:EntityAnnotation"
  ],
  "dc:created": "2015-12-07T11:22:07.748Z",
  "dc:creator":
"org.apache.stanbol.enhancer.engines.entitytagging.impl.NamedEntityTaggingEngine",
  "dc:relation": "urn:enhancement-e9c9c187-2d69-2c1f-6552-e76111430d4a",
  "enhancer:confidence": 1.0,
  "enhancer:entity-label": {
"@language": "en",
"@value": "France"
  },
  "enhancer:entity-reference": "http://dbpedia.org/resource/France;,
  "enhancer:entity-type": [
"dbp-ont:Country",
"dbp-ont:Place",
"dbp-ont:PopulatedPlace",
"schema:Country",
"schema:Place",
"http://www.opengis.net/gml/_Feature;,
"owl:Thing"
  ],
  "enhancer:extracted-from":
"urn:content-item-sha1-c8ae372ed26679df14da13050dd432fd32c527e3",
  "entityhub:site": "dbpedia"
},
{
  "@id": "urn:enhancement-c50474e4-ea0e-03ff-5db5-a25f4c8dae45",
  "@type": [
"enhancer:Enhancement",
"enhancer:EntityAnnotation"
  ],
  "dc:created": "2015-12-07T11:22:07.748Z",
  "dc:creator":
"org.apache.stanbol.enhancer.engines.entitytagging.impl.NamedEntityTaggingEngine",
  "dc:relation": "urn:enhancement-e9c9c187-2d69-2c1f-6552-e76111430d4a",
  "enhancer:confidence": 0.25715446,
  "enhancer:entity-label": {
"@language": "en",
"@value": "Vichy France"
  },
  "enhancer:entity-reference": "http://dbpedia.org/resource/Vichy_France;,
  "enhancer:entity-type": [
"dbp-ont:Country",
"dbp-ont:Place",
"dbp-ont:PopulatedPlace",
"schema:Country",
"schema:Place",
"http://www.opengis.net/gml/_Feature;,
"owl:Thing"
  ],
  "enhancer:extracted-from":
"urn:content-item-sha1-c8ae372ed26679df14da13050dd432fd32c527e3",
  "entityhub:site": "dbpedia"
},
{
  "@id": "urn:enhancement-de07bc41-e4a1-f510-3f93-99ebfd8c39f4",
  "@type": [
"enhancer:Enhancement",
"enhancer:EntityAnnotation"
  ],
  "dc:created": "2015-12-07T11:22:07.748Z",
  "dc:creator":
"org.apache.stanbol.enhancer.engines.entitytagging.impl.NamedEntityTaggingEngine",
  "dc:relation": "urn:enhancement-8db13707-1ecd-b4df-90ad-52447c8f2c84",
      "enhancer:confidence": 0.1493264,
  "enhancer:entity-label": {
"@language": "en",
"@value": "Paris Commune"
  },
  "enhancer:entity-reference": "http://dbpedia.org/resource/Paris_Commune;,
  "enhancer:entity-type": [
"dbp-ont:Country",
"dbp-

Re: ManifoldCF transformation connector for Apache Stanbol

[Dileepa Jayakody]

Hi Rafa, Karl,

Thanks again for all the pointers. Apparently I have missed several replies
before sending my reply to Karl's earlier email :)

Regards,
Dileepa

On Mon, Dec 7, 2015 at 5:29 PM, Dileepa Jayakody <djayak...@zaizi.com>
wrote:

> Hi Karl,
>
> Thanks a lot for the pointer.
>
> Stanbol doesn't update an existing document, it generates a new response
> with requested enhancement details for the content enhansment request.
> For example for a request like : "Paris is a city in France" following RDF
> response [1] is given by Stanbol.
>
> In the Stanbol connector, enhancement artifacts such as TextAnnotations
> and EntityAnnotations are extracted from the RDF response, to generate the
> entity abstractions and add them to the mcf repository document. Currently
> in the Stanbol connector we have added these entity abstractions as JSON
> strings to a multi-valued 'entities' field in the repository document and
> we parse that JSON in the SolrWrapper output connector to index in separate
> Solr cores (primary documents, linked entities and entity types with their
> attributes).
>
> Can we can have a primary repository document and create sub documents for
> the extracted entities? Is it possible to generate sub documents for a
> repo-document in a transformation connector?
>
> Thanks.
> Dileepa
>
> [1] Sample Stanbol response
>
> {
>   "@context": {
> "dbp-ont": "http://dbpedia.org/ontology/;,
> "dc": "http://purl.org/dc/terms/;,
> "dc:created": {
>   "@type": "xsd:dateTime"
> },
> "enhancer": "http://fise.iks-project.eu/ontology/;,
> "enhancer:confidence": {
>   "@type": "xsd:double"
> },
> "enhancer:end": {
>   "@type": "xsd:int"
> },
> "enhancer:entity-reference": {
>   "@type": "@id"
> },
> "enhancer:entity-type": {
>   "@type": "@id"
> },
> "enhancer:extracted-from": {
>   "@type": "@id"
> },
> "enhancer:start": {
>   "@type": "xsd:int"
> },
> "entityhub": "http://stanbol.apache.org/ontology/entityhub/entityhub#;,
> "foaf": "http://xmlns.com/foaf/0.1/;,
> "foaf:depiction": {
>   "@type": "@id"
> },
> "owl": "http://www.w3.org/2002/07/owl#;,
> "rdfs": "http://www.w3.org/2000/01/rdf-schema#;,
> "schema": "http://schema.org/;,
> "xsd": "http://www.w3.org/2001/XMLSchema#;
>   },
>   "@graph": [
> {
>   "@id": "http://dbpedia.org/resource/France;,
>   "@type": [
> "dbp-ont:Country",
> "dbp-ont:Place",
> "dbp-ont:PopulatedPlace",
> "http://www.opengis.net/gml/_Feature;,
> "owl:Thing",
> "schema:Country",
> "schema:Place"
>   ],
>   "foaf:depiction": [
> 
> "http://upload.wikimedia.org/wikipedia/commons/c/c3/Flag_of_France.svg;,
> 
> "http://upload.wikimedia.org/wikipedia/commons/thumb/c/c3/Flag_of_France.svg/200px-Flag_of_France.svg.png;
>   ],
>   "rdfs:comment": {
> "@language": "en",
> "@value": "France, officially the French Republic, is a unitary 
> semi-presidential republic in Western Europe with several overseas 
> territories and islands located on other continents and in the Indian, 
> Pacific, and Atlantic oceans. Metropolitan France extends from the 
> Mediterranean Sea to the English Channel and the North Sea, and from the 
> Rhine to the Atlantic Ocean. It is often referred to as l’Hexagone because of 
> the geometric shape of its territory."
>   },
>   "rdfs:label": [
> {
>   "@language": "en",
>   "@value": "France"
> },
> {
>   "@language": "fr",
>   "@value": "France"
> },
>   ]
> },
>
> {
>   "@id": "http://dbpedia.org/resource/Paris;,
>   "@type": [
> "dbp-ont:Place",
> "dbp-ont:PopulatedPlace",
> "dbp-ont:Settlement",
> "http://www.opengis.net/gml/_Feature;,
>

Re: ManifoldCF transformation connector for Apache Stanbol

[Dileepa Jayakody]

Hi guys,

I have developed a Stanbol connector for MCF. You can check it out from our
github repo here:
https://github.com/zaizi/sensefy-connectors/tree/master/transformation/mcf-stanbol-connector

It requires the SolrWrapper output connector which indexes enhanced
documents, entities and entityTypes in separate Solr cores. Basically it
requires 3 separate solr cores configured with a specific Solr schema for
primary documents, entities and entityTypes separately. This was done for
our specific use-case.

The SolrWrapper code is here :
https://github.com/zaizi/sensefy-connectors/tree/master/output/mcf-solrwrapperconnector

Perhaps we can discuss and remove the Stanbol connector's dependency with
SolrWrapper and have it working with any output connector.
Please note that the Stanbol connector currently has a bug in the UI
(editSpecification) which I'm working on at the moment. After fixing that I
will update here. And also I will provide documentations for configuring
the connector.

Thanks,
Dileepa

On Thu, Jul 9, 2015 at 8:36 PM, Antonio David Pérez Morales <
adperezmora...@gmail.com> wrote:

> Hi Joshua
>
> It is not the list for that, but Marmotta is already integrated in Apache
> Stanbol. You can take a look at this issue
> https://issues.apache.org/jira/browse/STANBOL-1165 .
>
> Anyway, as I said this is not the list for that, so let's use the proper
> list for these things.
>
> Regards
>
>
>
> 2015-07-09 15:29 GMT+02:00 Joshua Dunham <joshua.dun...@gmail.com>:
>
> > Hey Dileepa,
> >
> >   In case you were interested, I pinged the list a few days ago
> asking
> > for integration tips for Apache Marmotta.
> >
> > I got some great tips on how to do this which could help you. Since
> > Marmotta is a drop in replacement for Clarezza on Stanbol it may be
> easier
> > for you to take this way.
> >
> > I'm not a Java programmer but I'm bringing this problem to the
> development
> > staff at my company for assistance. If you like the Marmotta approach we
> > may gain more traction solving the same integration.
> >
> > I'm also integrating Marmotta with Stanbol so the effect would be the
> same
> > except not using the Stanbol API for data import in favor of Marmotta.
> >
> > Best,
> >
> > -J
> >
> > > On Jul 9, 2015, at 1:03 AM, Dileepa Jayakody <djayak...@zaizi.com>
> > wrote:
> > >
> > > Hi all,
> > >
> > > Thanks you for the feedback and offering your help in this.
> > > Let me get back to you on where to start the code base.
> > > As the first step, I would like to start by creating a architecture
> > diagram
> > > for the connector.
> > > I will send the diagram for your review soon.
> > >
> > > Thanks,
> > > Dileepa
> > >
> > > --
> > >
> > > --
> > > This message should be regarded as confidential. If you have received
> > this
> > > email in error please notify the sender and destroy it immediately.
> > > Statements of intent shall only become binding when confirmed in hard
> > copy
> > > by an authorised signatory.
> > >
> > > Zaizi Ltd is registered in England and Wales with the registration
> number
> > > 6440931. The Registered Office is Brook House, 229 Shepherds Bush Road,
> > > London W6 7AN.
> >
>

-- 

--
This message should be regarded as confidential. If you have received this 
email in error please notify the sender and destroy it immediately. 
Statements of intent shall only become binding when confirmed in hard copy 
by an authorised signatory.

Zaizi Ltd is registered in England and Wales with the registration number 
6440931. The Registered Office is Brook House, 229 Shepherds Bush Road, 
London W6 7AN. 

[jira] [Commented] (CONNECTORS-1181) Apache Stanbol Transformation Connector

[Dileepa Jayakody (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15003807#comment-15003807
 ] 

Dileepa Jayakody commented on CONNECTORS-1181:
--

Hi All,

I have developed a Stanbol connector for MCF. You can check it out from our 
github repo here: 
https://github.com/zaizi/sensefy-connectors/tree/master/transformation/mcf-stanbol-connector

It requires the SolrWrapper output connector which indexes enhanced documents, 
entities and entityTypes in separate Solr cores. The SolrWrapper code is here : 
https://github.com/zaizi/sensefy-connectors/tree/master/output/mcf-solrwrapperconnector

The Stanbol connector currently has a bug in the UI (editSpecification) which 
I'm working on at the moment. After fixing that I will update here. And provide 
documentations for configuring the connector.


> Apache Stanbol Transformation Connector
> ---
>
> Key: CONNECTORS-1181
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1181
> Project: ManifoldCF
>  Issue Type: Wish
>Affects Versions: ManifoldCF 1.8.2, ManifoldCF 2.0.2
>Reporter: Rafa Haro
>Assignee: Rafa Haro
>Priority: Minor
>  Labels: connect, transformation
> Fix For: ManifoldCF 2.3
>
>
> Apache Stanbol (https://stanbol.apache.org/) provides a set of reusable 
> components for semantic content management. One of this component is the 
> Enhancer (https://stanbol.apache.org/docs/trunk/components/enhancer/) which 
> allows to extract features and semantic metadata from textual content like 
> entities/concepts from domain ontologies, named entities and so on.
> Apache Stanbol provides an easy-to-use REST API. The main idea behind this 
> transformation connector would be to enrich the Repository Document's 
> (string) content with a configured Stanbol processing chain. The 
> Transformation Connector would allow the user to configure the metadata that 
> will be extracted from the Enhancer result for including it as RD's metadata
> This behavior come to somehow replace the functionality of the old Apache 
> Stanbol CMS Adapter 
> (https://stanbol.apache.org/docs/trunk/components/cmsadapter/) and ContentHub 
> (https://stanbol.apache.org/docs/trunk/components/contenthub/)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Indexing Solr documents with atomic updates using manifoldcf solr connector

[Dileepa Jayakody]

Hi Karl,

Thanks a lot for the detailed explanation.

I was able to get my usecase working by configuring the solr-connector to
create solrj ContentStreamUpdateRequest where it constructs the solr update
request using the RepositoryDocumentStream.

I just had to tick Use the Extract Update Handler option in
solr-connector's schema configuration section and use /update/json handler
to index the content in Solr.

So I could create multiple child repository documents in my transformation
connector, set the content of it to a JSON and use solrj
ContentStreamUpdateRequest to send it to Solr and index the child documents
separately using /update/json handler.

Thank you very much for all the help.

Regards,
Dileepa


On Tue, Aug 11, 2015 at 11:36 AM, Karl Wright daddy...@gmail.com wrote:

 Hi Dileepa,

 The only current way for ManifoldCF to track documents that are related in
 a parent-child relationship is using the document component mechanism.
 This is appropriate when a repository is structured so that a single
 document being processed results in multiple documents being indexed.
 Document components are determined and managed by the repository connector,
 NOT by a transformation connector or output connector.  Each
 RepositoryDocument still represents a single document, never multiple
 documents, and even if you could create document components in a
 transformation connector, they would be tracked individually in MCF and
 indexed completely independently in Solr.

 So, to do what you want sounds like it would require a different approach,
 specifically the extension of RepositoryDocument to handle multiple
 atomically-related logical documents at one time.  This is something that
 would require API changes.  However, if such a thing were attempted, the
 entire set of related documents represented by a single RepositoryDocument
 would all be indexed at one time, atomically, which sounds like it also
 might not be what you want.  It sounds to me like you are still trying to
 pursue your idea of indexing individual fields independently, is that
 correct?

 Karl


 On Tue, Aug 11, 2015 at 12:44 AM, Dileepa Jayakody djayak...@zaizi.com
 wrote:

  Hi Karl,
 
  Thanks for your response. My requirement is indexing child documents
  constructed from the content repo.document as separate Solr documents. So
  adding meta-data fields to the original repository document wouldn't help
  my scenario AFAIU.
 
  My transformation connector is somewhat similar to the Stanbol
  transformation connector proposed in manifoldcf jira [1].
  What I referred as meta-data are the Named Entity Recognition data (NER)
  extracted from the repository document. So each content repository
 document
  will have multiple NER child documents. These NERs are expected to be
  indexed as separate Solr documents having a mapping to the parent content
  repository document which the NERs were extracted from.
  So apart from indexing the content repository document in Solr, I need to
  index all NER child documents with their attributes as separate documents
  in Solr.
 
  Above example is how I create a child repo document for NER. I set the
  entire NER document as the binary stream of the child repository document
  which is then sent to mcf-solr connector.
 
  In the mcf-solr connector (In HttpPoster class) when building the solr
  document from the repository document's input stream, it adds the
  inputStream String as a field to the content field of the Solr document
  configured by solr-connector as below;
 
  buildSorDocument(long length, InputStream is){
 
  if (contentAttributeName != null)
{
  Reader r = new InputStreamReader(is, Consts.UTF_8);
  StringBuilder sb = new StringBuilder((int)length);
  char[] buffer = new char[65536];
  while (true)
  {
int amt = r.read(buffer,0,buffer.length);
if (amt == -1)
  break;
sb.append(buffer,0,amt);
  }
 
  outputDoc.addField( contentAttributeName, sb.toString() );
}
  
  }
 
  Therefore the solr-connector sends the JSON update request I constructed
 in
  my connector as a field value of the  Solr document, not as the whole
 Solr
  document.
 
  Can you please give me some advice on how to index nested child documents
  in Solr using Manifold?
 
  Thanks,
  Dileepa
 
  [1] https://issues.apache.org/jira/browse/CONNECTORS-1181
 
  On Mon, Aug 10, 2015 at 6:47 PM, Karl Wright daddy...@gmail.com wrote:
 
   Hi Dileepa,
  
   In order for ManifoldCF to index metadata, you need to set metadata
 field
   values in the RepositoryDocument object, not send Solr JSON as the
   document's content.  In fact from your example it looks like you want
  zero
   content.
  
   Please read the RepositoryDocument java doc to see how you set
 metadata.
  
   Karl
  
  
   On Mon, Aug 10, 2015 at 9:05 AM, Dileepa Jayakody djayak...@zaizi.com
 
   wrote:
  
Hi All,
   
We have

Re: Indexing Solr documents with atomic updates using manifoldcf solr connector

[Dileepa Jayakody]

Hi Karl,

Thanks for your response. My requirement is indexing child documents
constructed from the content repo.document as separate Solr documents. So
adding meta-data fields to the original repository document wouldn't help
my scenario AFAIU.

My transformation connector is somewhat similar to the Stanbol
transformation connector proposed in manifoldcf jira [1].
What I referred as meta-data are the Named Entity Recognition data (NER)
extracted from the repository document. So each content repository document
will have multiple NER child documents. These NERs are expected to be
indexed as separate Solr documents having a mapping to the parent content
repository document which the NERs were extracted from.
So apart from indexing the content repository document in Solr, I need to
index all NER child documents with their attributes as separate documents
in Solr.

Above example is how I create a child repo document for NER. I set the
entire NER document as the binary stream of the child repository document
which is then sent to mcf-solr connector.

In the mcf-solr connector (In HttpPoster class) when building the solr
document from the repository document's input stream, it adds the
inputStream String as a field to the content field of the Solr document
configured by solr-connector as below;

buildSorDocument(long length, InputStream is){

if (contentAttributeName != null)
  {
Reader r = new InputStreamReader(is, Consts.UTF_8);
StringBuilder sb = new StringBuilder((int)length);
char[] buffer = new char[65536];
while (true)
{
  int amt = r.read(buffer,0,buffer.length);
  if (amt == -1)
break;
  sb.append(buffer,0,amt);
}

outputDoc.addField( contentAttributeName, sb.toString() );
  }

}

Therefore the solr-connector sends the JSON update request I constructed in
my connector as a field value of the  Solr document, not as the whole Solr
document.

Can you please give me some advice on how to index nested child documents
in Solr using Manifold?

Thanks,
Dileepa

[1] https://issues.apache.org/jira/browse/CONNECTORS-1181

On Mon, Aug 10, 2015 at 6:47 PM, Karl Wright daddy...@gmail.com wrote:

 Hi Dileepa,

 In order for ManifoldCF to index metadata, you need to set metadata field
 values in the RepositoryDocument object, not send Solr JSON as the
 document's content.  In fact from your example it looks like you want zero
 content.

 Please read the RepositoryDocument java doc to see how you set metadata.

 Karl


 On Mon, Aug 10, 2015 at 9:05 AM, Dileepa Jayakody djayak...@zaizi.com
 wrote:

  Hi All,
 
  We have a requirement to extract some meta-data from content documents
 and
  index those meta-data as separate documents into a Solr index.
  I'm writing a transformation connector where I construct a new repository
  document adding the meta-data extracted by the connector and hand it over
  to mcf-solr-connector to index in Solr.
  Currently I face some difficulties with indexing these new documents in
  Solr properly using solr-connector.
 
  The new solr document should contain some atomic updates for certain
  fields. So in my connector I create a JSON to represent the Solr atomic
  update request and set is as the binaryStream of the repository
  document.The json string for the new solr document is as below;
 
  String jsonString = [{id:http://dbpedia.org/resource/Africa
  ,label:Africa,documents:{add:sample2.txt}}];
 
 
  Then, I add an id and set above jsonString as the binary input stream of
  the repo-document as follows;
 
  repoDoc.addField( id, idString );
  InputStream inputStream = IOUtils.toInputStream( jsonString );
  repoDoc.setBinary(inputStream, jsonString.getBytes().length);
 
  The expected behavior is Solr connector sending the SolrInputDocument
  constructed from the inputStream I added to the repo-document from my
  connector. But instead it adds the JSON  string to the  'content' field
 of
  the solr-document and sends to Solr.
 
  When I monitored the HTTP request from manifold to Solr I see below;
 
  POST /solr/core1/update?wt=xmlversion=2.2 HTTP/1.1
  add
 doc boost=1.0
field name=idhttp://dbpedia.org/resource/Africa/field
field name=_root_[{id:http://dbpedia.org/resource/Africa
  ,label:Africa,documents:{add:sample2.txt}}]/field
field name=lcf_metadata_idhttp://dbpedia.org/resource/Africa
  /field
 /doc/add0
 
  Please note that the 'content' field configured in manifoldcf is
 *_root_*.
 
  But the expected Solr update request from solr-connector should be as
  below;
  add
 doc boost=1.0
  field name=idhttp://dbpedia.org/resource/Africa/field
   field name=labelAfrica/field
field name=documents update=addsample2.txt/field
   field name=lcf_metadata_idhttp://dbpedia.org/resource/Africa
  /field
 /doc/add0
 
 
  Can someone please give some advice on how to use solr atomic updates
 with
  manifoldcf solr-connector

Re: Runtime dependency issues in manifoldcf connector

[Dileepa Jayakody]

Thanks Karl, Rafa for the help.
I will use Rafa's updated version of the stanbol client and package the
client as a ant project for manifoldcf deployment purpose.

Regards,
Dileepa

On Thu, Aug 6, 2015 at 4:07 PM, Rafa Haro rharoapa...@gmail.com wrote:

 Hi Dileepa,




 At [1] you can find a version of the Stanbol Client with several additions
 and improvements above the version you are using right now. Among other
 things, it is not packaging it with all the dependencies in a single jar
 anymore. Anyway, you would still need to use ant for a proper deployment
 within ManifoldCF. If you are using Maven for creating a shaded jar and
 including it in the connector-lib folder for testing, you will probably
 have the same error again. Also at [2] you can find a branch which is using
 jax-rs 1.1 with the jersey-client implementation which probably does not
 present that problem, but it is still using a bad packaging approach.




 Cheers,

 Rafa




 [1] - https://github.com/rafaharo/apache-stanbol-client

 [2] - https://github.com/rafaharo/apache-stanbol-client/tree/jaxrs-1.0

 On Thu, Aug 6, 2015 at 12:23 PM, Karl Wright daddy...@gmail.com wrote:

  Hi Dileepa,
  If you bundle together your connector and its dependencies in a single
 jar,
  you must not override any dependencies that are in the core classloader
  area or ManifoldCF will not work properly.  Nor will your connector.
  MCF is built primarily by ant.  Look at any of the connectors we provide;
  there is a build.xml.  You can copy one of these and modify it according
 to
  your needs.  It should be relatively easy to do provided you have a full
  transitive list of dependencies available.
  Karl
  On Thu, Aug 6, 2015 at 6:17 AM, Dileepa Jayakody djayak...@zaizi.com
  wrote:
  Hi Karl,
 
  Thanks for your response.
 
  On Thu, Aug 6, 2015 at 3:36 PM, Karl Wright daddy...@gmail.com wrote:
 
   Where are you putting the new jars?
  
 
   There are two different classloader levels in ManifoldCF: the core
   classloader level, and the connector classloader level.  Jars that
 only
   connectors depend on should be placed in the connector-lib directory.
  Can
   you verify that all of your resteasy jars and their dependencies are
 in
   that directory?
  
  
  I have bundled my connector with all the dependencies as a single jar
 using
  maven assembly plugin.
  I put that jar to connector-lib.
 
 
   It's also the case that sometimes a specific technology cannot work
 with
   the ManifoldCF classloader structure very well.  If that happens, we
 are
   usually forced to move the jar and its dependencies to the core level.
  But
   before you presume that, let's figure out what in fact you are doing.
  
   If you are trying to run your connector with only a maven build, I
 would
   strongly encourage you not to do that.  Use the ant build instead,
 until
   you get things straightened out.
  
   I didn't get this part clearly. Are you suggesting to use Ant to
 build my
  connector?
  Can you please elaborate?
 
 
   Karl
  
   Thanks,
  Dileepa
 
  
   On Thu, Aug 6, 2015 at 5:11 AM, Dileepa Jayakody djayak...@zaizi.com
 
   wrote:
  
Hi All,
   
I started developing a transformation connector to Apache
 ManifoldCF to
enhance repo-documents by connecting to Apache Stanbol. In my
 connector
   I'm
using Apache Stanbol Client version 1.0-Snapshot [1] which is using
RestEasy 3.0.8.Final as a dependency. When I invoke the Stanbol
 client
   in a
standalone java class (Main method) it works with excepted results,
 but
when I use it in my ManifoldCF connector with all dependencies
  (including
RestEasy 3.0.8 related dependencies: ) I keep getting below error in
ManifoldCF runtime [2].
I think it's due to some cyclic dependency issue with ManifoldCF and
RestEasy 3.0.8 used in my component.
I tried out this in both ManifoldCF 1.8 and 2.1 both get the same
  error.
   
Can someone please advice on how I should resolve this dependency
  issue?
   
[1] https://github.com/zaizi/apache-stanbol-client
   
[2] ERROR 2015-08-05 16:07:48,401 (Worker thread '4') - Error
 enhancing
   the
document  :
   
 file:/Users/djayakody/Documents/zaizi/manifoldTest/simple/sample0.txt
javax.ws.rs.ProcessingException: Unable to invoke request
at
   
   
  
 
 org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.invoke(ApacheHttpClient4Engine.java:287)
at
   
   
  
 
 org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.invoke(ClientInvocation.java:407)
at
   
   
  
 
 org.jboss.resteasy.client.jaxrs.internal.ClientInvocationBuilder.post(ClientInvocationBuilder.java:195)
at
   
   
  
 
 org.apache.stanbol.client.rest.RestClientExecutor.post(RestClientExecutor.java:63)
at
   
   
  
 
 org.apache.stanbol.client.enhancer.impl.EnhancerImpl.enhance(EnhancerImpl.java:74

Re: Runtime dependency issues in manifoldcf connector

[Dileepa Jayakody]

Hi Karl,

Thanks for your response.

On Thu, Aug 6, 2015 at 3:36 PM, Karl Wright daddy...@gmail.com wrote:

 Where are you putting the new jars?


 There are two different classloader levels in ManifoldCF: the core
 classloader level, and the connector classloader level.  Jars that only
 connectors depend on should be placed in the connector-lib directory.  Can
 you verify that all of your resteasy jars and their dependencies are in
 that directory?


I have bundled my connector with all the dependencies as a single jar using
maven assembly plugin.
I put that jar to connector-lib.


 It's also the case that sometimes a specific technology cannot work with
 the ManifoldCF classloader structure very well.  If that happens, we are
 usually forced to move the jar and its dependencies to the core level.  But
 before you presume that, let's figure out what in fact you are doing.

 If you are trying to run your connector with only a maven build, I would
 strongly encourage you not to do that.  Use the ant build instead, until
 you get things straightened out.

 I didn't get this part clearly. Are you suggesting to use Ant to build my
connector?
Can you please elaborate?


 Karl

 Thanks,
Dileepa


 On Thu, Aug 6, 2015 at 5:11 AM, Dileepa Jayakody djayak...@zaizi.com
 wrote:

  Hi All,
 
  I started developing a transformation connector to Apache ManifoldCF to
  enhance repo-documents by connecting to Apache Stanbol. In my connector
 I'm
  using Apache Stanbol Client version 1.0-Snapshot [1] which is using
  RestEasy 3.0.8.Final as a dependency. When I invoke the Stanbol client
 in a
  standalone java class (Main method) it works with excepted results, but
  when I use it in my ManifoldCF connector with all dependencies (including
  RestEasy 3.0.8 related dependencies: ) I keep getting below error in
  ManifoldCF runtime [2].
  I think it's due to some cyclic dependency issue with ManifoldCF and
  RestEasy 3.0.8 used in my component.
  I tried out this in both ManifoldCF 1.8 and 2.1 both get the same error.
 
  Can someone please advice on how I should resolve this dependency issue?
 
  [1] https://github.com/zaizi/apache-stanbol-client
 
  [2] ERROR 2015-08-05 16:07:48,401 (Worker thread '4') - Error enhancing
 the
  document  :
  file:/Users/djayakody/Documents/zaizi/manifoldTest/simple/sample0.txt
  javax.ws.rs.ProcessingException: Unable to invoke request
  at
 
 
 org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.invoke(ApacheHttpClient4Engine.java:287)
  at
 
 
 org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.invoke(ClientInvocation.java:407)
  at
 
 
 org.jboss.resteasy.client.jaxrs.internal.ClientInvocationBuilder.post(ClientInvocationBuilder.java:195)
  at
 
 
 org.apache.stanbol.client.rest.RestClientExecutor.post(RestClientExecutor.java:63)
  at
 
 
 org.apache.stanbol.client.enhancer.impl.EnhancerImpl.enhance(EnhancerImpl.java:74)
  at
 
 
 org.apache.manifoldcf.agents.transformation.stanbol.StanbolEnhancer.addOrReplaceDocumentWithException(StanbolEnhancer.java:251)
  at
 
 
 org.apache.manifoldcf.agents.incrementalingest.IncrementalIngester$PipelineAddEntryPoint.addOrReplaceDocumentWithException(IncrementalIngester.java:3221)
  at
 
 
 org.apache.manifoldcf.agents.incrementalingest.IncrementalIngester$PipelineAddFanout.sendDocument(IncrementalIngester.java:3072)
  at
 
 
 org.apache.manifoldcf.agents.incrementalingest.IncrementalIngester$MonitoredAddActivityWrapper.sendDocument(IncrementalIngester.java:3466)
  at
 
 
 org.apache.manifoldcf.agents.transformation.tika.TikaExtractor.addOrReplaceDocumentWithException(TikaExtractor.java:324)
  at
 
 
 org.apache.manifoldcf.agents.incrementalingest.IncrementalIngester$PipelineAddEntryPoint.addOrReplaceDocumentWithException(IncrementalIngester.java:3221)
  at
 
 
 org.apache.manifoldcf.agents.incrementalingest.IncrementalIngester$PipelineAddFanout.sendDocument(IncrementalIngester.java:3072)
  at
 
 
 org.apache.manifoldcf.agents.incrementalingest.IncrementalIngester$PipelineObjectWithVersions.addOrReplaceDocumentWithException(IncrementalIngester.java:2706)
  at
 
 
 org.apache.manifoldcf.agents.incrementalingest.IncrementalIngester.documentIngest(IncrementalIngester.java:756)
  at
 
 
 org.apache.manifoldcf.crawler.system.WorkerThread$ProcessActivity.ingestDocumentWithException(WorkerThread.java:1503)
  at
 
 
 org.apache.manifoldcf.crawler.system.WorkerThread$ProcessActivity.ingestDocumentWithException(WorkerThread.java:1468)
  at
 
 
 org.apache.manifoldcf.crawler.connectors.filesystem.FileConnector.processDocuments(FileConnector.java:404)
  at
 
 
 org.apache.manifoldcf.crawler.system.WorkerThread.run(WorkerThread.java:379)
 
  *Caused by: javax.ws.rs.ProcessingException: could not find writer for
  content-type text/plain type: java.io.ByteArrayInputStream

Runtime dependency issues in manifoldcf connector

[Dileepa Jayakody]

Hi All,

I started developing a transformation connector to Apache ManifoldCF to
enhance repo-documents by connecting to Apache Stanbol. In my connector I'm
using Apache Stanbol Client version 1.0-Snapshot [1] which is using
RestEasy 3.0.8.Final as a dependency. When I invoke the Stanbol client in a
standalone java class (Main method) it works with excepted results, but
when I use it in my ManifoldCF connector with all dependencies (including
RestEasy 3.0.8 related dependencies: ) I keep getting below error in
ManifoldCF runtime [2].
I think it's due to some cyclic dependency issue with ManifoldCF and
RestEasy 3.0.8 used in my component.
I tried out this in both ManifoldCF 1.8 and 2.1 both get the same error.

Can someone please advice on how I should resolve this dependency issue?

[1] https://github.com/zaizi/apache-stanbol-client

[2] ERROR 2015-08-05 16:07:48,401 (Worker thread '4') - Error enhancing the
document  :
file:/Users/djayakody/Documents/zaizi/manifoldTest/simple/sample0.txt
javax.ws.rs.ProcessingException: Unable to invoke request
at
org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.invoke(ApacheHttpClient4Engine.java:287)
at
org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.invoke(ClientInvocation.java:407)
at
org.jboss.resteasy.client.jaxrs.internal.ClientInvocationBuilder.post(ClientInvocationBuilder.java:195)
at
org.apache.stanbol.client.rest.RestClientExecutor.post(RestClientExecutor.java:63)
at
org.apache.stanbol.client.enhancer.impl.EnhancerImpl.enhance(EnhancerImpl.java:74)
at
org.apache.manifoldcf.agents.transformation.stanbol.StanbolEnhancer.addOrReplaceDocumentWithException(StanbolEnhancer.java:251)
at
org.apache.manifoldcf.agents.incrementalingest.IncrementalIngester$PipelineAddEntryPoint.addOrReplaceDocumentWithException(IncrementalIngester.java:3221)
at
org.apache.manifoldcf.agents.incrementalingest.IncrementalIngester$PipelineAddFanout.sendDocument(IncrementalIngester.java:3072)
at
org.apache.manifoldcf.agents.incrementalingest.IncrementalIngester$MonitoredAddActivityWrapper.sendDocument(IncrementalIngester.java:3466)
at
org.apache.manifoldcf.agents.transformation.tika.TikaExtractor.addOrReplaceDocumentWithException(TikaExtractor.java:324)
at
org.apache.manifoldcf.agents.incrementalingest.IncrementalIngester$PipelineAddEntryPoint.addOrReplaceDocumentWithException(IncrementalIngester.java:3221)
at
org.apache.manifoldcf.agents.incrementalingest.IncrementalIngester$PipelineAddFanout.sendDocument(IncrementalIngester.java:3072)
at
org.apache.manifoldcf.agents.incrementalingest.IncrementalIngester$PipelineObjectWithVersions.addOrReplaceDocumentWithException(IncrementalIngester.java:2706)
at
org.apache.manifoldcf.agents.incrementalingest.IncrementalIngester.documentIngest(IncrementalIngester.java:756)
at
org.apache.manifoldcf.crawler.system.WorkerThread$ProcessActivity.ingestDocumentWithException(WorkerThread.java:1503)
at
org.apache.manifoldcf.crawler.system.WorkerThread$ProcessActivity.ingestDocumentWithException(WorkerThread.java:1468)
at
org.apache.manifoldcf.crawler.connectors.filesystem.FileConnector.processDocuments(FileConnector.java:404)
at
org.apache.manifoldcf.crawler.system.WorkerThread.run(WorkerThread.java:379)

*Caused by: javax.ws.rs.ProcessingException: could not find writer for
content-type text/plain type: java.io.ByteArrayInputStream *   at
org.jboss.resteasy.core.interception.ClientWriterInterceptorContext.throwWriterNotFoundException(ClientWriterInterceptorContext.java:40)
at
org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.getWriter(AbstractWriterInterceptorContext.java:138)
at
org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:117)
at
org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.writeRequestBody(ClientInvocation.java:341)
at
org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.writeRequestBodyToOutputStream(ApacheHttpClient4Engine.java:558)
at
org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.buildEntity(ApacheHttpClient4Engine.java:524)

Thanks,
Dileepa

-- 

--
This message should be regarded as confidential. If you have received this 
email in error please notify the sender and destroy it immediately. 
Statements of intent shall only become binding when confirmed in hard copy 
by an authorised signatory.

Zaizi Ltd is registered in England and Wales with the registration number 
6440931. The Registered Office is Brook House, 229 Shepherds Bush Road, 
London W6 7AN. 

Recovering ManifoldCF from a job stuck in terminating state

[Dileepa Jayakody]

Hi All,

I'm trying out ManifoldCF 2.1 by creating a Job with a file system
repository connection, tika transformation and solr output connection.

During a job I abruptly shutdown the server. After restarting I can see
that Start up idle cleanup thread is in a loop without shutting down. See
the error log [1]
From the UI I cannot shutdown the Job as it is shown as in terminating
state. Nor can I delete the Job from the list.

Can someone please tell me how can I recover ManifoldCF from this state?

Thanks,
Dileepa


[1]
DEBUG 2015-07-17 16:29:09,736 (Idle cleanup thread) - Start up idle cleanup
thread
FATAL 2015-07-17 16:29:10,034 (Document cleanup thread '0') - Error tossed:
org.apache.solr.client.solrj.request.UpdateRequest.process(Lorg/apache/solr/client/solrj/SolrClient;)Lorg/apache/solr/client/solrj/SolrResponse;
java.lang.NoSuchMethodError:
org.apache.solr.client.solrj.request.UpdateRequest.process(Lorg/apache/solr/client/solrj/SolrClient;)Lorg/apache/solr/client/solrj/SolrResponse;
at
org.apache.manifoldcf.agents.output.solr.HttpPoster$DeleteThread.run(HttpPoster.java:1271)
FATAL 2015-07-17 16:29:10,888 (Document cleanup thread '1') - Error tossed:
org.apache.solr.client.solrj.request.UpdateRequest.process(Lorg/apache/solr/client/solrj/SolrClient;)Lorg/apache/solr/client/solrj/SolrResponse;
java.lang.NoSuchMethodError:
org.apache.solr.client.solrj.request.UpdateRequest.process(Lorg/apache/solr/client/solrj/SolrClient;)Lorg/apache/solr/client/solrj/SolrResponse;
at
org.apache.manifoldcf.agents.output.solr.HttpPoster$DeleteThread.run(HttpPoster.java:1271)
FATAL 2015-07-17 16:29:11,909 (Document cleanup thread '2') - Error tossed:
org.apache.solr.client.solrj.request.UpdateRequest.process(Lorg/apache/solr/client/solrj/SolrClient;)Lorg/apache/solr/client/solrj/SolrResponse;

-- 

--
This message should be regarded as confidential. If you have received this 
email in error please notify the sender and destroy it immediately. 
Statements of intent shall only become binding when confirmed in hard copy 
by an authorised signatory.

Zaizi Ltd is registered in England and Wales with the registration number 
6440931. The Registered Office is Brook House, 229 Shepherds Bush Road, 
London W6 7AN. 

Re: ManifoldCF transformation connector for Apache Stanbol

[Dileepa Jayakody]

Hi Rafa,

I would very much like to give it a try. And I want to contribute the
connector code fully, as it's the open source way we all work on :)
Can you please let me know more details on this? Where I can collaborate
etc?

Thanks,
Dileepa

On Wed, Jul 8, 2015 at 2:43 PM, Dileepa Jayakody djayak...@zaizi.com
wrote:

 Thank you Rafa, for your reply.
 I will come back with more questions later on the jira.


 Regards,
 Dileepa

 On Wed, Jul 8, 2015 at 1:37 PM, Rafa Haro rh...@apache.org wrote:

 Hi Dileepa,

 As you probably know, I started to think on this when I was working in the
 same company that you are working now. We all initially agreed on
 contribute it. Then someone in the company decided and ordered not to
 contribute this to ManifoldCF. That was the end of the story for long
 time.
 A couple of months ago, after discussing with Stanbol community, we
 identified this connector again as an important thing to do, so I started
 to develop it again from the scratch at my own. Now, as you also know, I'm
 working for another company and for this issue in concrete, I need to find
 some free time to finish it. If you want to give it a try by your own, I
 will be more than happy to help you only with the condition that the
 connector code is fully contributed from the beginning.

 Cheers,
 Rafa

 On Wed, Jul 8, 2015 at 9:34 AM, Karl Wright daddy...@gmail.com wrote:

  You might want to inquire right in the ticket itself, as a comment.  I
  don't know the status of this project either, but Rafa Haro is a
 committer
  and I expect he'll respond soon.
 
  Karl
 
  On Wed, Jul 8, 2015 at 3:07 AM, Dileepa Jayakody djayak...@zaizi.com
  wrote:
 
   Hi All,
  
   I'm Dileepa Jayakody a Software Engineer from Sri Lanka working on
 CMS +
   semantic web integrations. We are currently looking at Apache
 ManifoldCF
   and Stanbol for this integration.
  
   I'm interested in the concept of manifoldCF transformation connector
 for
   Stanbol : https://issues.apache.org/jira/browse/CONNECTORS-1181
  
   Can you please let me know the status of this project, repo location
 (if
   available)?
   I would like to contribute to this component.
  
   Thanks,
   Dileepa
  
   --
  
   --
   This message should be regarded as confidential. If you have received
  this
   email in error please notify the sender and destroy it immediately.
   Statements of intent shall only become binding when confirmed in hard
  copy
   by an authorised signatory.
  
   Zaizi Ltd is registered in England and Wales with the registration
 number
   6440931. The Registered Office is Brook House, 229 Shepherds Bush
 Road,
   London W6 7AN.
  
 




-- 

--
This message should be regarded as confidential. If you have received this 
email in error please notify the sender and destroy it immediately. 
Statements of intent shall only become binding when confirmed in hard copy 
by an authorised signatory.

Zaizi Ltd is registered in England and Wales with the registration number 
6440931. The Registered Office is Brook House, 229 Shepherds Bush Road, 
London W6 7AN. 

Re: ManifoldCF transformation connector for Apache Stanbol

[Dileepa Jayakody]

Thank you Rafa, for your reply.
I will come back with more questions later on the jira.


Regards,
Dileepa

On Wed, Jul 8, 2015 at 1:37 PM, Rafa Haro rh...@apache.org wrote:

 Hi Dileepa,

 As you probably know, I started to think on this when I was working in the
 same company that you are working now. We all initially agreed on
 contribute it. Then someone in the company decided and ordered not to
 contribute this to ManifoldCF. That was the end of the story for long time.
 A couple of months ago, after discussing with Stanbol community, we
 identified this connector again as an important thing to do, so I started
 to develop it again from the scratch at my own. Now, as you also know, I'm
 working for another company and for this issue in concrete, I need to find
 some free time to finish it. If you want to give it a try by your own, I
 will be more than happy to help you only with the condition that the
 connector code is fully contributed from the beginning.

 Cheers,
 Rafa

 On Wed, Jul 8, 2015 at 9:34 AM, Karl Wright daddy...@gmail.com wrote:

  You might want to inquire right in the ticket itself, as a comment.  I
  don't know the status of this project either, but Rafa Haro is a
 committer
  and I expect he'll respond soon.
 
  Karl
 
  On Wed, Jul 8, 2015 at 3:07 AM, Dileepa Jayakody djayak...@zaizi.com
  wrote:
 
   Hi All,
  
   I'm Dileepa Jayakody a Software Engineer from Sri Lanka working on CMS
 +
   semantic web integrations. We are currently looking at Apache
 ManifoldCF
   and Stanbol for this integration.
  
   I'm interested in the concept of manifoldCF transformation connector
 for
   Stanbol : https://issues.apache.org/jira/browse/CONNECTORS-1181
  
   Can you please let me know the status of this project, repo location
 (if
   available)?
   I would like to contribute to this component.
  
   Thanks,
   Dileepa
  
   --
  
   --
   This message should be regarded as confidential. If you have received
  this
   email in error please notify the sender and destroy it immediately.
   Statements of intent shall only become binding when confirmed in hard
  copy
   by an authorised signatory.
  
   Zaizi Ltd is registered in England and Wales with the registration
 number
   6440931. The Registered Office is Brook House, 229 Shepherds Bush Road,
   London W6 7AN.
  
 


-- 

--
This message should be regarded as confidential. If you have received this 
email in error please notify the sender and destroy it immediately. 
Statements of intent shall only become binding when confirmed in hard copy 
by an authorised signatory.

Zaizi Ltd is registered in England and Wales with the registration number 
6440931. The Registered Office is Brook House, 229 Shepherds Bush Road, 
London W6 7AN. 

ManifoldCF transformation connector for Apache Stanbol

[Dileepa Jayakody]

Hi All,

I'm Dileepa Jayakody a Software Engineer from Sri Lanka working on CMS +
semantic web integrations. We are currently looking at Apache ManifoldCF
and Stanbol for this integration.

I'm interested in the concept of manifoldCF transformation connector for
Stanbol : https://issues.apache.org/jira/browse/CONNECTORS-1181

Can you please let me know the status of this project, repo location (if
available)?
I would like to contribute to this component.

Thanks,
Dileepa

-- 

--
This message should be regarded as confidential. If you have received this 
email in error please notify the sender and destroy it immediately. 
Statements of intent shall only become binding when confirmed in hard copy 
by an authorised signatory.

Zaizi Ltd is registered in England and Wales with the registration number 
6440931. The Registered Office is Brook House, 229 Shepherds Bush Road, 
London W6 7AN.