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 <[email protected]>: >> 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
