You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@stanbol.apache.org by "Alessandro Adamou (JIRA)" <ji...@apache.org> on 2012/07/30 16:45:33 UTC
[jira] [Created] (STANBOL-710) Use the Sling Adaptable interface to
export OWL artifacts
Alessandro Adamou created STANBOL-710:
-----------------------------------------
Summary: Use the Sling Adaptable interface to export OWL artifacts
Key: STANBOL-710
URL: https://issues.apache.org/jira/browse/STANBOL-710
Project: Stanbol
Issue Type: Wish
Components: Ontology Manager
Affects Versions: 0.9.0-incubating
Reporter: Alessandro Adamou
Priority: Minor
Sling has a nice interface that can be used for implementing an Adapter pattern
org.apache.sling.api.adapter.Adaptable
It would be good to use this in lieu of the custom export methods in the OWLExportable interface.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (STANBOL-710) Use an Adaptable interface to export
OWL artifacts
Posted by "Alessandro Adamou (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STANBOL-710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alessandro Adamou updated STANBOL-710:
--------------------------------------
Description:
Sling has a nice interface that can be used for implementing an Adapter pattern
org.apache.sling.api.adapter.Adaptable
It would be good to use either this or a custom Adaptable interface in lieu of the custom export methods in the OWLExportable interface.
was:
Sling has a nice interface that can be used for implementing an Adapter pattern
org.apache.sling.api.adapter.Adaptable
It would be good to use this in lieu of the custom export methods in the OWLExportable interface.
Summary: Use an Adaptable interface to export OWL artifacts (was: Use the Sling Adaptable interface to export OWL artifacts)
Thanks, I am then renaming the issue as it is likely that a custom adapter pattern with options will be used instead of the Sling one.
> Use an Adaptable interface to export OWL artifacts
> --------------------------------------------------
>
> Key: STANBOL-710
> URL: https://issues.apache.org/jira/browse/STANBOL-710
> Project: Stanbol
> Issue Type: Wish
> Components: Ontology Manager
> Affects Versions: 0.9.0-incubating
> Reporter: Alessandro Adamou
> Priority: Minor
> Labels: adapters, pattern, sling
>
> Sling has a nice interface that can be used for implementing an Adapter pattern
> org.apache.sling.api.adapter.Adaptable
> It would be good to use either this or a custom Adaptable interface in lieu of the custom export methods in the OWLExportable interface.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (STANBOL-710) Use the Sling Adaptable interface
to export OWL artifacts
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STANBOL-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13474941#comment-13474941 ]
Bertrand Delacretaz commented on STANBOL-710:
---------------------------------------------
Ok, so IIUC basically your
public interface OWLExportable {
<O> O export(Class<O> returnType, boolean merge, IRI prefix);
}
is very similar to a Sling Adaptable:
public interface Adaptable {
<AdapterType> AdapterType adaptTo(Class<AdapterType> type);
}
but takes additional options, so if you want to make it more generic you could do something like
public interface Adaptable {
// no-options variant
<AdapterType> AdapterType adaptTo(Class<AdapterType> type);
// with options
<AdapterType> AdapterType adaptTo(Class<AdapterType> type, Map<String, Object> options);
}
the Sling adaptable interface does not provide for such options, OTOH it is available in bundles, as part of the Sling API, and adapter extension, see links below.
I'm not sure if reusing the Sling code is useful, if you need the options you might just use your own adapter pattern.
Code links:
http://svn.apache.org/repos/asf/sling/trunk/bundles/api
http://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/adapter
> Use the Sling Adaptable interface to export OWL artifacts
> ---------------------------------------------------------
>
> Key: STANBOL-710
> URL: https://issues.apache.org/jira/browse/STANBOL-710
> Project: Stanbol
> Issue Type: Wish
> Components: Ontology Manager
> Affects Versions: 0.9.0-incubating
> Reporter: Alessandro Adamou
> Priority: Minor
> Labels: adapters, pattern, sling
>
> Sling has a nice interface that can be used for implementing an Adapter pattern
> org.apache.sling.api.adapter.Adaptable
> It would be good to use this in lieu of the custom export methods in the OWLExportable interface.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (STANBOL-710) Use the Sling Adaptable
interface to export OWL artifacts
Posted by "Alessandro Adamou (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STANBOL-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13474935#comment-13474935 ]
Alessandro Adamou edited comment on STANBOL-710 at 10/12/12 11:06 AM:
----------------------------------------------------------------------
The Ontology Manager API has a few types of objects, such as Scope, OntologySpace and Session, that reference ontologies stored in Stanbol.
These objects also need to be exported as ontologies (e.g. ontologies with OWL import declarations, or merged axioms from all the referenced ontologies). This is very useful when you GET a REST resource representing a scope, session etc. and accept RDF/XML, or Turtle, or Manchester OWL Syntax etc.
To do so I make them implement this OWLExportable interface which looks like this
public interface OWLExportable {
<O> O export(Class<O> returnType, boolean merge, IRI prefix);
// ... a few more methods
}
So if I have a
Session s1;
IRI prefix = IRI.create([stanbol-host]"/ontonet/session");
then I can call
OWLOntology o = s1.export(OWLOntology.class, false, prefix);
so I have a Session represented as an OWL API OWLOntology (good for OWL/XML, Manchester and Functional syntax formats, but also a prettyprint for RDF/XML and Turtle). And it contains owl:imports triples whose objects start with prefix.
Other times I need a Clerezza TripleCollection because I can use it for RDF/JSON, JSON-LD and faster RDF/XML and Turtle serialization. So I'll do
TripleCollection o = s1.export(TripleCollection.clas, false, prefix);
(internally the implementation uses a SimpleMGraph or IndexedMGraph);
Now, currently I have the export() method implementation in the ScopeImpl, SessionImpl, etc. . They have a fixed set of supported return types and perform the export on a case basis, otherwise they throw an UnsupportedOperationException.
I don't like having it there, so I'd like to move these implementation outside and defer them to specific OWL API and Clerezza adapters classes, possibly add more in the future and keep the core implementation agnostic to exportable types.
Something like an object able to export to such a class
public interface Exporter {
<O> O export(Scope s, Class<O> returnType [, ...]);
<O> O export(OntologySpace s, Class<O> returnType [, ...]);
<O> O export(Session s, Class<O> returnType [, ...]);
boolean canExport(Scope s, Class<O> returnType);
boolean canExport(OntologySpace s, Class<O> returnType);
boolean canExport(Session s, Class<O> returnType);
}
and a general manager where these exporters are registered
public interface ExportManager extends Exporter {
void addExporter(Exporter exporter);
void removeExporter(Exporter exporter);
// ...
}
Or some other way. The important thing is not to have class-specific export() implementation in the core classes.
Hope this clears it out?
was (Author: alessandro.adamou):
The Ontology Manager API has a few types of objects, such as Scope, OntologySpace and Session, that reference ontologies stored in Stanbol.
These objects also need to be exported as ontologies (e.g. ontologies with OWL import declarations, or merged axioms from all the referenced ontologies). This is very useful when you GET a REST resource representing a scope, session etc. and accept RDF/XML, or Turtle, or Manchester OWL Syntax etc.
To do so I make them implement this OWLExportable interface which looks like this
public interface OWLExportable {
<O> O export(Class<O> returnType, boolean merge, IRI prefix);
// ... a few more methods
}
So if I have a
Session s1;
IRI prefix = IRI.create([stanbol-host]"/ontonet/session");
then I can call
OWLOntology o = s1.export(OWLOntology.class, false, prefix);
so I have a Session represented as an OWL API OWLOntology (good for OWL/XML, Manchester and Functional syntax formats, but also a prettyprint for RDF/XML and Turtle). And it contains owl:imports triples whose objects start with prefix.
Other times I need a Clerezza TripleCollection because I can use it for RDF/JSON, JSON-LD and faster RDF/XML and Turtle serialization. So I'll do
TripleCollection o = s1.export(TripleCollection.clas, false, prefix);
(internally the implementation uses a SimpleMGraph or IndexedMGraph);
Now, currently I have the export() method implementation in the ScopeImpl, SessionImpl, etc. . They have a fixed set of supported return types and perform the export on a case basis, otherwise they throw an UnsupportedOperationException.
I don't like having it there, so I'd like to move these implementation outside and defer them to specific OWL API and Clerezza adapters classes, possibly add more in the future and keep the core implementation agnostic to exportable types.
Something like an object able to export to such a class
public interface OWLExporter {
<O> O export(Scope s, Class<O> returnType [, ...]);
<O> O export(OntologySpace s, Class<O> returnType [, ...]);
<O> O export(Session s, Class<O> returnType [, ...]);
boolean canExport(Scope s, Class<O> returnType);
boolean canExport(OntologySpace s, Class<O> returnType);
boolean canExport(Session s, Class<O> returnType);
}
and a general manager where these exporters are registered
public interface ExportManager extends Exporter {
void addExporter(Exporter exporter);
void removeExporter(Exporter exporter);
// ...
}
Or some other way. The important thing is not to have class-specific export() implementation in the core classes.
Hope this clears it out?
> Use the Sling Adaptable interface to export OWL artifacts
> ---------------------------------------------------------
>
> Key: STANBOL-710
> URL: https://issues.apache.org/jira/browse/STANBOL-710
> Project: Stanbol
> Issue Type: Wish
> Components: Ontology Manager
> Affects Versions: 0.9.0-incubating
> Reporter: Alessandro Adamou
> Priority: Minor
> Labels: adapters, pattern, sling
>
> Sling has a nice interface that can be used for implementing an Adapter pattern
> org.apache.sling.api.adapter.Adaptable
> It would be good to use this in lieu of the custom export methods in the OWLExportable interface.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (STANBOL-710) Use the Sling Adaptable interface
to export OWL artifacts
Posted by "Alessandro Adamou (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STANBOL-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13474935#comment-13474935 ]
Alessandro Adamou commented on STANBOL-710:
-------------------------------------------
The Ontology Manager API has a few types of objects, such as Scope, OntologySpace and Session, that reference ontologies stored in Stanbol.
These objects also need to be exported as ontologies (e.g. ontologies with OWL import declarations, or merged axioms from all the referenced ontologies). This is very useful when you GET a REST resource representing a scope, session etc. and accept RDF/XML, or Turtle, or Manchester OWL Syntax etc.
To do so I make them implement this OWLExportable interface which looks like this
public interface OWLExportable {
<O> O export(Class<O> returnType, boolean merge, IRI prefix);
// ... a few more methods
}
So if I have a
Session s1;
IRI prefix = IRI.create([stanbol-host]"/ontonet/session");
then I can call
OWLOntology o = s1.export(OWLOntology.class, false, prefix);
so I have a Session represented as an OWL API OWLOntology (good for OWL/XML, Manchester and Functional syntax formats, but also a prettyprint for RDF/XML and Turtle). And it contains owl:imports triples whose objects start with prefix.
Other times I need a Clerezza TripleCollection because I can use it for RDF/JSON, JSON-LD and faster RDF/XML and Turtle serialization. So I'll do
TripleCollection o = s1.export(TripleCollection.clas, false, prefix);
(internally the implementation uses a SimpleMGraph or IndexedMGraph);
Now, currently I have the export() method implementation in the ScopeImpl, SessionImpl, etc. . They have a fixed set of supported return types and perform the export on a case basis, otherwise they throw an UnsupportedOperationException.
I don't like having it there, so I'd like to move these implementation outside and defer them to specific OWL API and Clerezza adapters classes, possibly add more in the future and keep the core implementation agnostic to exportable types.
Something like an object able to export to such a class
public interface OWLExporter {
<O> O export(Scope s, Class<O> returnType [, ...]);
<O> O export(OntologySpace s, Class<O> returnType [, ...]);
<O> O export(Session s, Class<O> returnType [, ...]);
boolean canExport(Scope s, Class<O> returnType);
boolean canExport(OntologySpace s, Class<O> returnType);
boolean canExport(Session s, Class<O> returnType);
}
and a general manager where these exporters are registered
public interface ExportManager extends Exporter {
void addExporter(Exporter exporter);
void removeExporter(Exporter exporter);
// ...
}
Or some other way. The important thing is not to have class-specific export() implementation in the core classes.
Hope this clears it out?
> Use the Sling Adaptable interface to export OWL artifacts
> ---------------------------------------------------------
>
> Key: STANBOL-710
> URL: https://issues.apache.org/jira/browse/STANBOL-710
> Project: Stanbol
> Issue Type: Wish
> Components: Ontology Manager
> Affects Versions: 0.9.0-incubating
> Reporter: Alessandro Adamou
> Priority: Minor
> Labels: adapters, pattern, sling
>
> Sling has a nice interface that can be used for implementing an Adapter pattern
> org.apache.sling.api.adapter.Adaptable
> It would be good to use this in lieu of the custom export methods in the OWLExportable interface.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (STANBOL-710) Use the Sling Adaptable interface
to export OWL artifacts
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STANBOL-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13474864#comment-13474864 ]
Bertrand Delacretaz commented on STANBOL-710:
---------------------------------------------
I'm familiar with Sling adapters (http://sling.apache.org/site/adapters.html) but not with the OWLExportable that you mention, could you provide a small code example that explains your use case?
> Use the Sling Adaptable interface to export OWL artifacts
> ---------------------------------------------------------
>
> Key: STANBOL-710
> URL: https://issues.apache.org/jira/browse/STANBOL-710
> Project: Stanbol
> Issue Type: Wish
> Components: Ontology Manager
> Affects Versions: 0.9.0-incubating
> Reporter: Alessandro Adamou
> Priority: Minor
> Labels: adapters, pattern, sling
>
> Sling has a nice interface that can be used for implementing an Adapter pattern
> org.apache.sling.api.adapter.Adaptable
> It would be good to use this in lieu of the custom export methods in the OWLExportable interface.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira