You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stanbol.apache.org by Rupert Westenthaler <ru...@gmail.com> on 2012/01/23 14:37:18 UTC

[Question] How to get the EnhancementEngine URI?

Hi all

STANBOL-431 [1] suggests that EnhancementEngines are available at URIs like

   http://{stanbol-host}/{rel-path}/enhancer/engine/{engine-name}

e.g.

   http://localhost:8080/enhancer/engine/langid

now lets assume that an engine would be able to return an RDF graph
that represents its configuration e.g

  http://localhost:8080/enhancer/engine/langid
    rdfs:label "langid"
    rdfs:comment "Engine that can detect the language of parsed text"
    enhancer:order "-300"^^xsd:integer

and the enhancement metadata would use the engine URI as dc:creator
values for enhancements instead of the full qualified class name as
currently used.

The problem with providing the metadata like this is that currently
the engine has no way to know that it has the URI
"http://localhost:8080/enhancer/engine/langid" but only the name
{engine-name} "langid".

I am asking for the best practice to provide this information so that
engine implementation can correctly build such graphs.

best
Rupert


[1] https://issues.apache.org/jira/browse/STANBOL-431

-- 
| Rupert Westenthaler             rupert.westenthaler@gmail.com
| Bodenlehenstraße 11                             ++43-699-11108907
| A-5500 Bischofshofen

Re: [Question] How to get the EnhancementEngine URI?

Posted by Rupert Westenthaler <ru...@gmail.com>.
On 23.01.2012, at 15:05, Fabian Christ wrote:

> Hi,
> 
> I don't know a best practice but here are my two cents:
> 
> I would not use the current Stanbol host name within the URI of an
> engine. Instead I would define a Stanbol namespace, like
> 
> http://stanbol.apache.org/enhancer/engine/<label>/<version>
> 

We do not need an URI for the type, because the bundle and the Class representing the implementation are already good enough. However we could/should provide a http URL to the documentation of the engine.

> In a dc:creator field I would like to know which engine in which
> version was the creator. I don't think it is important where the
> instance of this engine is running physically as this may change over
> time. The version might be a good additional information - not sure.
> 
Users need to know the instance. The engine type and version are not sufficient. Maybe the LangID engine was a bad example, because here the results will be the same regardless of the instance and its configuration.
But take engines like NER, Entity Linking, Keyword Extraction as examples. Here the results are much more dependent on the configuration (trained models, used thesaurus …) than the actual software version. 

> If you ask a specific instance of an engine for its configuration, you
> would get something like this.
> 
> http://localhost:8080/enhancer/engine/langid
>   rdfs:label "langid"
>   rdfs:version "1.0"
>   rdfs:url "http://stanbol.apache.org/enhancer/engine/langid/1.0"
>   rdfs:comment "Engine that can detect the language of parsed text"
>   enhancer:order "-300"^^xsd:integer
> 
> Maybe we can add an interface to Stanbol enhancer that let's you query
> the server to return an instance URI of an engine for
> "http://stanbol.apache.org/enhancer/engine/langid/1.0". That would
> return "http://localhost:8080/enhancer/engine/langid". This may be
> useful to find running instances of engines.

good idea. We could collect all such metadata in a Graph and provide a Sparql Endpoint for it under /enhancer/sparql

But to create all such information Engines and Chains need some way to lookup the Stanbol Root (e.g. "http://localhost:8080/") … 
   … so how should we do that?

I could think of:

  * System Property accessed via the bundleContext.getProperty(…)?
  * Interface/Object registered by the JerseyApplication that provides the base URI? May be just the actual URL registered as Service with some defined properties.

best
Rupert


> Am 23. Januar 2012 14:45 schrieb Alessandro Adamou <ad...@cs.unibo.it>:
>> I am interested about knowing this best practice too.
>> 
>> In OntoNet, the way we had to go was to have a configurable service
>> parameter where you'd be supposed to enter the current Stanbol host, to
>> which the service endpoints and all the other stuff would be concatenated,
>> but obviously this is just as good as you can imagine.
>> 
>> Having such a parameter shared across the entire platform would already be
>> some improvement I guess.
>> 
>> Best,
>> 
>> Alessandro
>> 
>> 
>> 
>> On 1/23/12 2:37 PM, Rupert Westenthaler wrote:
>>> 
>>> Hi all
>>> 
>>> STANBOL-431 [1] suggests that EnhancementEngines are available at URIs
>>> like
>>> 
>>>    http://{stanbol-host}/{rel-path}/enhancer/engine/{engine-name}
>>> 
>>> e.g.
>>> 
>>>    http://localhost:8080/enhancer/engine/langid
>>> 
>>> now lets assume that an engine would be able to return an RDF graph
>>> that represents its configuration e.g
>>> 
>>>   http://localhost:8080/enhancer/engine/langid
>>>     rdfs:label "langid"
>>>     rdfs:comment "Engine that can detect the language of parsed text"
>>>     enhancer:order "-300"^^xsd:integer
>>> 
>>> and the enhancement metadata would use the engine URI as dc:creator
>>> values for enhancements instead of the full qualified class name as
>>> currently used.
>>> 
>>> The problem with providing the metadata like this is that currently
>>> the engine has no way to know that it has the URI
>>> "http://localhost:8080/enhancer/engine/langid" but only the name
>>> {engine-name} "langid".
>>> 
>>> I am asking for the best practice to provide this information so that
>>> engine implementation can correctly build such graphs.
>>> 
>>> best
>>> Rupert
>>> 
>>> 
>>> [1] https://issues.apache.org/jira/browse/STANBOL-431
>>> 
>> 
>> 
>> --
>> M.Sc. Alessandro Adamou
>> 
>> Alma Mater Studiorum - Università di Bologna
>> Department of Computer Science
>> Mura Anteo Zamboni 7, 40127 Bologna - Italy
>> 
>> Semantic Technology Laboratory (STLab)
>> Institute for Cognitive Science and Technology (ISTC)
>> National Research Council (CNR)
>> Via Nomentana 56, 00161 Rome - Italy
>> 
>> 
>> "As for the charges against me, I am unconcerned. I am beyond their timid,
>> lying morality, and so I am beyond caring."
>> (Col. Walter E. Kurtz)
>> 
>> Not sent from my iSnobTechDevice
>> 
> 
> 
> 
> -- 
> Fabian
> http://twitter.com/fctwitt


Re: [Question] How to get the EnhancementEngine URI?

Posted by Fabian Christ <ch...@googlemail.com>.
Hi,

I don't know a best practice but here are my two cents:

I would not use the current Stanbol host name within the URI of an
engine. Instead I would define a Stanbol namespace, like

http://stanbol.apache.org/enhancer/engine/<label>/<version>

In a dc:creator field I would like to know which engine in which
version was the creator. I don't think it is important where the
instance of this engine is running physically as this may change over
time. The version might be a good additional information - not sure.

If you ask a specific instance of an engine for its configuration, you
would get something like this.

 http://localhost:8080/enhancer/engine/langid
   rdfs:label "langid"
   rdfs:version "1.0"
   rdfs:url "http://stanbol.apache.org/enhancer/engine/langid/1.0"
   rdfs:comment "Engine that can detect the language of parsed text"
   enhancer:order "-300"^^xsd:integer

Maybe we can add an interface to Stanbol enhancer that let's you query
the server to return an instance URI of an engine for
"http://stanbol.apache.org/enhancer/engine/langid/1.0". That would
return "http://localhost:8080/enhancer/engine/langid". This may be
useful to find running instances of engines.

Best,
 - Fabian

Am 23. Januar 2012 14:45 schrieb Alessandro Adamou <ad...@cs.unibo.it>:
> I am interested about knowing this best practice too.
>
> In OntoNet, the way we had to go was to have a configurable service
> parameter where you'd be supposed to enter the current Stanbol host, to
> which the service endpoints and all the other stuff would be concatenated,
> but obviously this is just as good as you can imagine.
>
> Having such a parameter shared across the entire platform would already be
> some improvement I guess.
>
> Best,
>
> Alessandro
>
>
>
> On 1/23/12 2:37 PM, Rupert Westenthaler wrote:
>>
>> Hi all
>>
>> STANBOL-431 [1] suggests that EnhancementEngines are available at URIs
>> like
>>
>>    http://{stanbol-host}/{rel-path}/enhancer/engine/{engine-name}
>>
>> e.g.
>>
>>    http://localhost:8080/enhancer/engine/langid
>>
>> now lets assume that an engine would be able to return an RDF graph
>> that represents its configuration e.g
>>
>>   http://localhost:8080/enhancer/engine/langid
>>     rdfs:label "langid"
>>     rdfs:comment "Engine that can detect the language of parsed text"
>>     enhancer:order "-300"^^xsd:integer
>>
>> and the enhancement metadata would use the engine URI as dc:creator
>> values for enhancements instead of the full qualified class name as
>> currently used.
>>
>> The problem with providing the metadata like this is that currently
>> the engine has no way to know that it has the URI
>> "http://localhost:8080/enhancer/engine/langid" but only the name
>> {engine-name} "langid".
>>
>> I am asking for the best practice to provide this information so that
>> engine implementation can correctly build such graphs.
>>
>> best
>> Rupert
>>
>>
>> [1] https://issues.apache.org/jira/browse/STANBOL-431
>>
>
>
> --
> M.Sc. Alessandro Adamou
>
> Alma Mater Studiorum - Università di Bologna
> Department of Computer Science
> Mura Anteo Zamboni 7, 40127 Bologna - Italy
>
> Semantic Technology Laboratory (STLab)
> Institute for Cognitive Science and Technology (ISTC)
> National Research Council (CNR)
> Via Nomentana 56, 00161 Rome - Italy
>
>
> "As for the charges against me, I am unconcerned. I am beyond their timid,
> lying morality, and so I am beyond caring."
> (Col. Walter E. Kurtz)
>
> Not sent from my iSnobTechDevice
>



-- 
Fabian
http://twitter.com/fctwitt

Re: [Question] How to get the EnhancementEngine URI?

Posted by Alessandro Adamou <ad...@cs.unibo.it>.
I am interested about knowing this best practice too.

In OntoNet, the way we had to go was to have a configurable service 
parameter where you'd be supposed to enter the current Stanbol host, to 
which the service endpoints and all the other stuff would be 
concatenated, but obviously this is just as good as you can imagine.

Having such a parameter shared across the entire platform would already 
be some improvement I guess.

Best,

Alessandro


On 1/23/12 2:37 PM, Rupert Westenthaler wrote:
> Hi all
>
> STANBOL-431 [1] suggests that EnhancementEngines are available at URIs like
>
>     http://{stanbol-host}/{rel-path}/enhancer/engine/{engine-name}
>
> e.g.
>
>     http://localhost:8080/enhancer/engine/langid
>
> now lets assume that an engine would be able to return an RDF graph
> that represents its configuration e.g
>
>    http://localhost:8080/enhancer/engine/langid
>      rdfs:label "langid"
>      rdfs:comment "Engine that can detect the language of parsed text"
>      enhancer:order "-300"^^xsd:integer
>
> and the enhancement metadata would use the engine URI as dc:creator
> values for enhancements instead of the full qualified class name as
> currently used.
>
> The problem with providing the metadata like this is that currently
> the engine has no way to know that it has the URI
> "http://localhost:8080/enhancer/engine/langid" but only the name
> {engine-name} "langid".
>
> I am asking for the best practice to provide this information so that
> engine implementation can correctly build such graphs.
>
> best
> Rupert
>
>
> [1] https://issues.apache.org/jira/browse/STANBOL-431
>


-- 
M.Sc. Alessandro Adamou

Alma Mater Studiorum - Università di Bologna
Department of Computer Science
Mura Anteo Zamboni 7, 40127 Bologna - Italy

Semantic Technology Laboratory (STLab)
Institute for Cognitive Science and Technology (ISTC)
National Research Council (CNR)
Via Nomentana 56, 00161 Rome - Italy


"As for the charges against me, I am unconcerned. I am beyond their timid, lying morality, and so I am beyond caring."
(Col. Walter E. Kurtz)

Not sent from my iSnobTechDevice