You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stanbol.apache.org by Alessandro Adamou <al...@istc.cnr.it> on 2011/12/14 23:22:21 UTC
For Acuity: thanks for your JIRA Tickets on the Ontology Manager
Dear Martin, Steve,
Thanks very much for the issues just opened on Stanbol JIRA concerning
ontology management.
Most if not all of them were addressed in recent ontonet revisions, and
I am documenting the changes with comments straight on the issue pages.
Please feel free to follow up on them in case there are additional
requirements or misalignments with the current state. I have roughly a
couple of weeks to address any other issues coming up.
As it turns out, some parts of the ontonet API were deprecated, but
others could just not stay there and had to be removed altogether. I
apologise if this gets to break any of your previous code, and will be
glad to point you to their replacements in return.
Thank you again for the great cooperation.
Kind regards,
Alessandro
--
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)
RE: For Acuity: thanks for your JIRA Tickets on the Ontology Manager
Posted by Stephen Bayliss <st...@acuityunlimited.net>.
Thanks Alessandro
> > Is this an appropriate point in time for us to upgrade to
> the latest
> > SVN release in terms of any work-in-progress on revisions to the
> > OntoNet API?
>
> Yes I think it's time to take the step.
Great, thanks.
>
> > Also, do you have any guidance on STANBOL-426, about resolving
> > identifiers between ontologies in Ontonet with identifiers from
> > external systems? We'll of course look at this in the
> context of the
> > revisions to the codebase, but any pointers you can provide will be
> > gratefully received.
>
> I did not have time to comment on that one too, but the
> OntologyProvider
> interface does provide a low-level implementation of this issue (i.e.
> getKey(IRI) where IRI can be either the logical or physical
> IRI of the
> ontology, and the Strings returned by the Clerezza provider
> can be made
> into UriRef)
>
> We just have to check if it's worth escalating it to the level of
> scope/space/session.
This sounds useful; we'll take a look as we integrate the latest SVN
revision to see how well this fits our use case and get back to you.
>
> > I've also just raised a JIRA over the scalability issue we
> had which
> > you're aware of, please let us know if the latest revisions also
> > tackle this issue.
>
> Great! It would be even better if you could provide more quantitative
> details such as the exact size of the ontology and the VM heap space.
I've added a comment to STANBOL-433 with some more information.
>
> Hopefully the Clerezza re-implementation helps out on this. There is
> still a conversion bottleneck if you need to access an
> ontology in OWL
> API form, but I am bugging the Manchester guys for a possible
> solution
> (a midlevel Clerezza adapter).
Great, we'll let you know how we get on.
>
> I am also considering making scopes and spaces able to export
> Clerezza
> Graphs as an alternative to OWLOntology objects, would that be of any
> use to you?
We'll come back to you as we progress with our implementatino.
> -----Original Message-----
> From: Alessandro Adamou [mailto:adamou@cs.unibo.it]
> Sent: 16 December 2011 18:47
> To: stanbol-dev@incubator.apache.org
> Subject: Re: For Acuity: thanks for your JIRA Tickets on the
> Ontology Manager
>
>
> Hi Steve,
>
> > Thanks very much for the update on this, we are looking forward to
> > trying out the latest codebase; we'll raise any questions
> we have over
> > changes and deprecations on the list.
>
> That's perfect! The list and JIRA are the places.
>
> > Is this an appropriate point in time for us to upgrade to
> the latest
> > SVN release in terms of any work-in-progress on revisions to the
> > OntoNet API?
>
> Yes I think it's time to take the step.
>
> > Also, do you have any guidance on STANBOL-426, about resolving
> > identifiers between ontologies in Ontonet with identifiers from
> > external systems? We'll of course look at this in the
> context of the
> > revisions to the codebase, but any pointers you can provide will be
> > gratefully received.
>
> I did not have time to comment on that one too, but the
> OntologyProvider
> interface does provide a low-level implementation of this issue (i.e.
> getKey(IRI) where IRI can be either the logical or physical
> IRI of the
> ontology, and the Strings returned by the Clerezza provider
> can be made
> into UriRef)
>
> We just have to check if it's worth escalating it to the level of
> scope/space/session.
>
> > I've also just raised a JIRA over the scalability issue we
> had which
> > you're aware of, please let us know if the latest revisions also
> > tackle this issue.
>
> Great! It would be even better if you could provide more quantitative
> details such as the exact size of the ontology and the VM heap space.
>
> Hopefully the Clerezza re-implementation helps out on this. There is
> still a conversion bottleneck if you need to access an
> ontology in OWL
> API form, but I am bugging the Manchester guys for a possible
> solution
> (a midlevel Clerezza adapter).
>
> I am also considering making scopes and spaces able to export
> Clerezza
> Graphs as an alternative to OWLOntology objects, would that be of any
> use to you?
>
> Alessandro
>
>
> >> -----Original Message-----
> >> From: Alessandro Adamou [mailto:alessandro.adamou@istc.cnr.it]
> >> Sent: Wednesday, December 14, 2011 10:22 PM
> >> To: stanbol-dev@incubator.apache.org
> >> Subject: For Acuity: thanks for your JIRA Tickets on the Ontology
> >> Manager
> >>
> >> Dear Martin, Steve,
> >>
> >> Thanks very much for the issues just opened on Stanbol JIRA
> >> concerning ontology management.
> >>
> >> Most if not all of them were addressed in recent ontonet
> revisions,
> >> and I am documenting the changes with comments straight on
> the issue
> >> pages. Please feel free to follow up on them in case there are
> >> additional requirements or misalignments with the current state. I
> >> have roughly a couple of weeks to address any other issues
> coming up.
> >>
> >> As it turns out, some parts of the ontonet API were
> deprecated, but
> >> others could just not stay there and had to be removed
> altogether. I
> >> apologise if this gets to break any of your previous code,
> and will
> >> be glad to point you to their replacements in return.
> >>
> >> Thank you again for the great cooperation.
> >> Kind regards,
> >>
> >> Alessandro
> >>
> >> --
> >> 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)
> >
> >
>
>
> --
> 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)
>
>
Re: Identifiers of graphs within spaces
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
On 1/13/12 6:27 PM, Stephen Bayliss wrote:
> Should we be grabbing the TcProvider with an OSGi SCR @Reference
> annotation, or TcManager.getInstance() ?
If you are doing it from within an OSGi service component it is fine to
use a @Reference TcManager (not TcProvider because there can be several
other TcProviders).
Otherwise TcManager.getInstance() should work just the same. @Reto am I
wrong?
Alessandro
--
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
RE: Identifiers of graphs within spaces
Posted by Stephen Bayliss <st...@acuityunlimited.net>.
Hi Alessandro
Thanks very much for this - we're working through the changes. One quick
question:
> - you can supply the TcProvider to the
> GraphContentInputSource. If it is
> the same as the TcManager singleton instance, we skip copying all the
> triples to yet another Graph. Should take considerably less
> time
Should we be grabbing the TcProvider with an OSGi SCR @Reference annotation,
or TcManager.getInstance() ?
Steve
> -----Original Message-----
> From: Alessandro Adamou [mailto:adamou@cs.unibo.it]
> Sent: 11 January 2012 11:59
> To: stanbol-dev@incubator.apache.org
> Subject: Re: Identifiers of graphs within spaces
>
>
> Dear Steve,
>
> thanks for your feedback and sorry for not coming back to you earlier
> but I was on vacation until just the other day.
>
> I have committed an update to OntoNet that should address
> your inquiries:
> - addOntology() on spaces and sessions now returns the String
> that you
> can use as a key to identify the ontology in the OntologyProvider (or
> the graph in the TcManager if you create a UriRef from it).
> - you can export scopes, spaces and sessions as Clerezza objects if
> needed - does not give you the OWL-oriented view on the graph but can
> save much computing power. I will probably employ it on the REST API
> - you can supply the TcProvider to the
> GraphContentInputSource. If it is
> the same as the TcManager singleton instance, we skip copying all the
> triples to yet another Graph. Should take considerably less
> time; on the
> other hand it prevents from using this method to *update*
> graphs. Note
> that there are protected binding methods in OntologyInputSource
> implementations for triple providers, physical IRIs etc.
> - other minor optimizations
>
> It would be great to share a benchmarking method to assess network
> scalability. So far I have managed to load a 200MB RDF/XML
> graph using a
> 256MB VM without out-of-memory errors.
>
> Also thanks for the post on the IKS blog (I am telling you
> here because
> I don't know if you and Martin are following an IKS mailing
> list)! I am
> working on an adopter-oriented one, and it would be great to
> include an
> overview on the Acuity experience with Stanbol-Fedora - what
> it does and
> what benefit it gets from Stanbol. Would you like to share?
> Unfortunately, I have been able to tell only my side of the story so
> far, as the link at [1] keeps timing out on me :(
>
> Thanks a lot, keep up the good work!
>
> Alessandro
>
> [1]
> fedora-stanbol.acuityunlimited.net:18080/orbeon/stanbol-fedora
> /data-browser
>
>
> On 12/30/11 6:08 PM, Stephen Bayliss wrote:
> > Hi Alessandro
> >
> > Thanks very much for your responses.
> >
> >> Dear Steve,
> >>
> >> On 12/19/11 6:22 PM, Stephen Bayliss wrote:
> >>> Our use-case is thus:
> >>>
> >>> 1) Create OntologyContentInputSource(stream)
> >> Perhaps you're better off with a
> GraphContentInputSource(InpuStream),
> >> so it won't have to go through the burden of converting from
> >> OWLOntology to
> >> Graph just in order to store it (everything is stored as
> >> Clerezza graphs
> >> anyhow). Note that OWLOntology exports of scopes, spaces and
> >> ontologies
> >> within is possible regardless of the input source
> (although it is THE
> >> bottleneck of the current implementation, see my comment to
> >> STANBOL-433).
> >>
> >> I'm now adding the possibility to specify the TcProvider in the
> >> GraphContentInputSource constructor. This should also save
> the burden
> >> of copying the triples from the in-memory SimpleGraph to the
> >> Graph stored
> >> in the TcManager (IF you pass the TcManager singleton as
> TcProvider).
> > Great, we'll take a look at the GraphContentInputSource and the
> > TcProvider constructor argument.
> >
> >>> - as our content is behind authentication, the stream
> >> is provided
> >>> by an HTTP client
> >>> - the content has an identifier (URI) assigned by
> the external
> >>> system (independent of the contents of the stream/ontology)
> >>> 2) Load OntologyInputSource into the space with
> >>> CustomOntologySpace.addOntology(...)
> >>> 3) When updated content comes along:
> >>> - remove the original (from the store as well as the space)
> >>> - add the updated content
> >>>
> >>> As the OntologyInputSource was created from a stream, it
> >> doesn't have
> >>> a physical IRI (I think?),
> >> correct
> > Actually logically it does have a physical IRI - the one
> that our HTTP
> > client sourced the input stream from - so if there was an option to
> > specify the physical IRI somehow, maybe this would in fact
> do the job?
> >
> >>> so at (2) we don't have a "KReS identifier" for it
> >>> - so if we want to replace the ontology in the future with
> >> an updated
> >>> version I can't see currently an easy way of determining which
> >>> ontology to remove from the space and then delete it prior
> >> to adding
> >>> the updated content.
> >> if the ontology is named (i.e. it does have logical IRI
> even if not
> >> a physical one), you could simply call
> >> OntologyProvider#getKey(logicalIRI), but if you would like
> something
> >> simpler... see my next comment below.
> >>
> >>> I can list the graph keys through the OntologyProvider;
> but I think
> >>> what I need is to know (or be able to set?) the key when
> adding it?
> >> Would it be enough if this key were the return value of
> >> addOntology() ?
> > If there's no logical way of passing in an identifier that
> we wish to
> > use for the graph, then I think this would do the job; we
> can maintain
> > our own map/index of the graph keys vs the content
> provider's URIs for
> > these graphs.
> >
> >
> >>> Also I can see that if I get the TcProvider I can do a
> >>> .deleteTripleCollection(UriRef ref) - how would this
> UriRef link in
> >>> with the above (when I look at the identifiers of the ontologies
> >>> retrieved using the the keys from listGraphs, these are
> >>> "Anonymous-xyz" and don't have an IRI).
> >> I'll have to look into this one, fortunately I've still
> got some time
> >> on it.
> > Great, thanks!
> >
> >> All the best,
> >>
> >> Alessandro
> >>
> >> --
> >> 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)
> >>
> >>
> >
>
>
> --
> 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)
>
>
Re: Identifiers of graphs within spaces
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
Dear Steve,
thanks for your feedback and sorry for not coming back to you earlier
but I was on vacation until just the other day.
I have committed an update to OntoNet that should address your inquiries:
- addOntology() on spaces and sessions now returns the String that you
can use as a key to identify the ontology in the OntologyProvider (or
the graph in the TcManager if you create a UriRef from it).
- you can export scopes, spaces and sessions as Clerezza objects if
needed - does not give you the OWL-oriented view on the graph but can
save much computing power. I will probably employ it on the REST API
- you can supply the TcProvider to the GraphContentInputSource. If it is
the same as the TcManager singleton instance, we skip copying all the
triples to yet another Graph. Should take considerably less time; on the
other hand it prevents from using this method to *update* graphs. Note
that there are protected binding methods in OntologyInputSource
implementations for triple providers, physical IRIs etc.
- other minor optimizations
It would be great to share a benchmarking method to assess network
scalability. So far I have managed to load a 200MB RDF/XML graph using a
256MB VM without out-of-memory errors.
Also thanks for the post on the IKS blog (I am telling you here because
I don't know if you and Martin are following an IKS mailing list)! I am
working on an adopter-oriented one, and it would be great to include an
overview on the Acuity experience with Stanbol-Fedora - what it does and
what benefit it gets from Stanbol. Would you like to share?
Unfortunately, I have been able to tell only my side of the story so
far, as the link at [1] keeps timing out on me :(
Thanks a lot, keep up the good work!
Alessandro
[1]
fedora-stanbol.acuityunlimited.net:18080/orbeon/stanbol-fedora/data-browser
On 12/30/11 6:08 PM, Stephen Bayliss wrote:
> Hi Alessandro
>
> Thanks very much for your responses.
>
>> Dear Steve,
>>
>> On 12/19/11 6:22 PM, Stephen Bayliss wrote:
>>> Our use-case is thus:
>>>
>>> 1) Create OntologyContentInputSource(stream)
>> Perhaps you're better off with a
>> GraphContentInputSource(InpuStream), so
>> it won't have to go through the burden of converting from
>> OWLOntology to
>> Graph just in order to store it (everything is stored as
>> Clerezza graphs
>> anyhow). Note that OWLOntology exports of scopes, spaces and
>> ontologies
>> within is possible regardless of the input source (although it is THE
>> bottleneck of the current implementation, see my comment to
>> STANBOL-433).
>>
>> I'm now adding the possibility to specify the TcProvider in the
>> GraphContentInputSource constructor. This should also save
>> the burden of
>> copying the triples from the in-memory SimpleGraph to the
>> Graph stored
>> in the TcManager (IF you pass the TcManager singleton as TcProvider).
> Great, we'll take a look at the GraphContentInputSource and the TcProvider
> constructor argument.
>
>>> - as our content is behind authentication, the stream
>> is provided
>>> by an HTTP client
>>> - the content has an identifier (URI) assigned by the external
>>> system (independent of the contents of the stream/ontology)
>>> 2) Load OntologyInputSource into the space with
>>> CustomOntologySpace.addOntology(...)
>>> 3) When updated content comes along:
>>> - remove the original (from the store as well as the space)
>>> - add the updated content
>>>
>>> As the OntologyInputSource was created from a stream, it
>> doesn't have
>>> a physical IRI (I think?),
>> correct
> Actually logically it does have a physical IRI - the one that our HTTP
> client sourced the input stream from - so if there was an option to specify
> the physical IRI somehow, maybe this would in fact do the job?
>
>>> so at (2) we don't have a "KReS identifier" for it
>>> - so if we want to replace the ontology in the future with
>> an updated
>>> version I can't see currently an easy way of determining which
>>> ontology to remove from the space and then delete it prior
>> to adding
>>> the updated content.
>> if the ontology is named (i.e. it does have logical IRI even
>> if not a
>> physical one), you could simply call
>> OntologyProvider#getKey(logicalIRI), but if you would like something
>> simpler... see my next comment below.
>>
>>> I can list the graph keys through the OntologyProvider; but I think
>>> what I need is to know (or be able to set?) the key when adding it?
>> Would it be enough if this key were the return value of
>> addOntology() ?
> If there's no logical way of passing in an identifier that we wish to use
> for the graph, then I think this would do the job; we can maintain our own
> map/index of the graph keys vs the content provider's URIs for these graphs.
>
>
>>> Also I can see that if I get the TcProvider I can do a
>>> .deleteTripleCollection(UriRef ref) - how would this UriRef link in
>>> with the above (when I look at the identifiers of the ontologies
>>> retrieved using the the keys from listGraphs, these are
>>> "Anonymous-xyz" and don't have an IRI).
>> I'll have to look into this one, fortunately I've still got
>> some time on it.
> Great, thanks!
>
>> All the best,
>>
>> Alessandro
>>
>> --
>> 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)
>>
>>
>
--
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)
RE: Identifiers of graphs within spaces
Posted by Stephen Bayliss <st...@acuityunlimited.net>.
Hi Alessandro
Thanks very much for your responses.
>
> Dear Steve,
>
> On 12/19/11 6:22 PM, Stephen Bayliss wrote:
> > Our use-case is thus:
> >
> > 1) Create OntologyContentInputSource(stream)
>
> Perhaps you're better off with a
> GraphContentInputSource(InpuStream), so
> it won't have to go through the burden of converting from
> OWLOntology to
> Graph just in order to store it (everything is stored as
> Clerezza graphs
> anyhow). Note that OWLOntology exports of scopes, spaces and
> ontologies
> within is possible regardless of the input source (although it is THE
> bottleneck of the current implementation, see my comment to
> STANBOL-433).
>
> I'm now adding the possibility to specify the TcProvider in the
> GraphContentInputSource constructor. This should also save
> the burden of
> copying the triples from the in-memory SimpleGraph to the
> Graph stored
> in the TcManager (IF you pass the TcManager singleton as TcProvider).
Great, we'll take a look at the GraphContentInputSource and the TcProvider
constructor argument.
>
> > - as our content is behind authentication, the stream
> is provided
> > by an HTTP client
> > - the content has an identifier (URI) assigned by the external
> > system (independent of the contents of the stream/ontology)
> > 2) Load OntologyInputSource into the space with
> > CustomOntologySpace.addOntology(...)
> > 3) When updated content comes along:
> > - remove the original (from the store as well as the space)
> > - add the updated content
> >
> > As the OntologyInputSource was created from a stream, it
> doesn't have
> > a physical IRI (I think?),
>
> correct
Actually logically it does have a physical IRI - the one that our HTTP
client sourced the input stream from - so if there was an option to specify
the physical IRI somehow, maybe this would in fact do the job?
>
> > so at (2) we don't have a "KReS identifier" for it
> > - so if we want to replace the ontology in the future with
> an updated
> > version I can't see currently an easy way of determining which
> > ontology to remove from the space and then delete it prior
> to adding
> > the updated content.
>
> if the ontology is named (i.e. it does have logical IRI even
> if not a
> physical one), you could simply call
> OntologyProvider#getKey(logicalIRI), but if you would like something
> simpler... see my next comment below.
>
> > I can list the graph keys through the OntologyProvider; but I think
> > what I need is to know (or be able to set?) the key when adding it?
>
> Would it be enough if this key were the return value of
> addOntology() ?
If there's no logical way of passing in an identifier that we wish to use
for the graph, then I think this would do the job; we can maintain our own
map/index of the graph keys vs the content provider's URIs for these graphs.
>
> > Also I can see that if I get the TcProvider I can do a
> > .deleteTripleCollection(UriRef ref) - how would this UriRef link in
> > with the above (when I look at the identifiers of the ontologies
> > retrieved using the the keys from listGraphs, these are
> > "Anonymous-xyz" and don't have an IRI).
>
> I'll have to look into this one, fortunately I've still got
> some time on it.
Great, thanks!
>
> All the best,
>
> Alessandro
>
> --
> 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)
>
>
Re: Identifiers of graphs within spaces
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
Dear Steve,
On 12/19/11 6:22 PM, Stephen Bayliss wrote:
> Our use-case is thus:
>
> 1) Create OntologyContentInputSource(stream)
Perhaps you're better off with a GraphContentInputSource(InpuStream), so
it won't have to go through the burden of converting from OWLOntology to
Graph just in order to store it (everything is stored as Clerezza graphs
anyhow). Note that OWLOntology exports of scopes, spaces and ontologies
within is possible regardless of the input source (although it is THE
bottleneck of the current implementation, see my comment to STANBOL-433).
I'm now adding the possibility to specify the TcProvider in the
GraphContentInputSource constructor. This should also save the burden of
copying the triples from the in-memory SimpleGraph to the Graph stored
in the TcManager (IF you pass the TcManager singleton as TcProvider).
> - as our content is behind authentication, the stream is provided by an
> HTTP client
> - the content has an identifier (URI) assigned by the external system
> (independent of the contents of the stream/ontology)
> 2) Load OntologyInputSource into the space with
> CustomOntologySpace.addOntology(...)
> 3) When updated content comes along:
> - remove the original (from the store as well as the space)
> - add the updated content
>
> As the OntologyInputSource was created from a stream, it doesn't have a
> physical IRI (I think?),
correct
> so at (2) we don't have a "KReS identifier" for it
> - so if we want to replace the ontology in the future with an updated
> version I can't see currently an easy way of determining which ontology to
> remove from the space and then delete it prior to adding the updated
> content.
if the ontology is named (i.e. it does have logical IRI even if not a
physical one), you could simply call
OntologyProvider#getKey(logicalIRI), but if you would like something
simpler... see my next comment below.
> I can list the graph keys through the OntologyProvider; but I think what I
> need is to know (or be able to set?) the key when adding it?
Would it be enough if this key were the return value of addOntology() ?
> Also I can see that if I get the TcProvider I can do a
> .deleteTripleCollection(UriRef ref) - how would this UriRef link in with the
> above (when I look at the identifiers of the ontologies retrieved using the
> the keys from listGraphs, these are "Anonymous-xyz" and don't have an IRI).
I'll have to look into this one, fortunately I've still got some time on it.
All the best,
Alessandro
--
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)
Identifiers of graphs within spaces
Posted by Stephen Bayliss <st...@acuityunlimited.net>.
Hi Alessandro
Upgraded to the latest svn revision :o)
>
> > Also, do you have any guidance on STANBOL-426, about resolving
> > identifiers between ontologies in Ontonet with identifiers from
> > external systems? We'll of course look at this in the
> context of the
> > revisions to the codebase, but any pointers you can provide will be
> > gratefully received.
>
> I did not have time to comment on that one too, but the
> OntologyProvider
> interface does provide a low-level implementation of this issue (i.e.
> getKey(IRI) where IRI can be either the logical or physical
> IRI of the
> ontology, and the Strings returned by the Clerezza provider
> can be made
> into UriRef)
>
> We just have to check if it's worth escalating it to the level of
> scope/space/session.
I think it could be, somehow, but I'm not sure exactly in what form.
Our use-case is thus:
1) Create OntologyContentInputSource(stream)
- as our content is behind authentication, the stream is provided by an
HTTP client
- the content has an identifier (URI) assigned by the external system
(independent of the contents of the stream/ontology)
2) Load OntologyInputSource into the space with
CustomOntologySpace.addOntology(...)
3) When updated content comes along:
- remove the original (from the store as well as the space)
- add the updated content
As the OntologyInputSource was created from a stream, it doesn't have a
physical IRI (I think?), so at (2) we don't have a "KReS identifier" for it
- so if we want to replace the ontology in the future with an updated
version I can't see currently an easy way of determining which ontology to
remove from the space and then delete it prior to adding the updated
content.
I can list the graph keys through the OntologyProvider; but I think what I
need is to know (or be able to set?) the key when adding it?
Also I can see that if I get the TcProvider I can do a
.deleteTripleCollection(UriRef ref) - how would this UriRef link in with the
above (when I look at the identifiers of the ontologies retrieved using the
the keys from listGraphs, these are "Anonymous-xyz" and don't have an IRI).
Thanks
Steve
Re: For Acuity: thanks for your JIRA Tickets on the Ontology Manager
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
Hi Steve,
> Thanks very much for the update on this, we are looking forward to trying
> out the latest codebase; we'll raise any questions we have over changes and
> deprecations on the list.
That's perfect! The list and JIRA are the places.
> Is this an appropriate point in time for us to upgrade to the latest SVN
> release in terms of any work-in-progress on revisions to the OntoNet API?
Yes I think it's time to take the step.
> Also, do you have any guidance on STANBOL-426, about resolving identifiers
> between ontologies in Ontonet with identifiers from external systems? We'll
> of course look at this in the context of the revisions to the codebase, but
> any pointers you can provide will be gratefully received.
I did not have time to comment on that one too, but the OntologyProvider
interface does provide a low-level implementation of this issue (i.e.
getKey(IRI) where IRI can be either the logical or physical IRI of the
ontology, and the Strings returned by the Clerezza provider can be made
into UriRef)
We just have to check if it's worth escalating it to the level of
scope/space/session.
> I've also just raised a JIRA over the scalability issue we had which you're
> aware of, please let us know if the latest revisions also tackle this issue.
Great! It would be even better if you could provide more quantitative
details such as the exact size of the ontology and the VM heap space.
Hopefully the Clerezza re-implementation helps out on this. There is
still a conversion bottleneck if you need to access an ontology in OWL
API form, but I am bugging the Manchester guys for a possible solution
(a midlevel Clerezza adapter).
I am also considering making scopes and spaces able to export Clerezza
Graphs as an alternative to OWLOntology objects, would that be of any
use to you?
Alessandro
>> -----Original Message-----
>> From: Alessandro Adamou [mailto:alessandro.adamou@istc.cnr.it]
>> Sent: Wednesday, December 14, 2011 10:22 PM
>> To: stanbol-dev@incubator.apache.org
>> Subject: For Acuity: thanks for your JIRA Tickets on the Ontology Manager
>>
>> Dear Martin, Steve,
>>
>> Thanks very much for the issues just opened on Stanbol JIRA concerning
>> ontology management.
>>
>> Most if not all of them were addressed in recent ontonet revisions, and
>> I am documenting the changes with comments straight on the issue pages.
>> Please feel free to follow up on them in case there are additional
>> requirements or misalignments with the current state. I have roughly a
>> couple of weeks to address any other issues coming up.
>>
>> As it turns out, some parts of the ontonet API were deprecated, but
>> others could just not stay there and had to be removed altogether. I
>> apologise if this gets to break any of your previous code, and will be
>> glad to point you to their replacements in return.
>>
>> Thank you again for the great cooperation.
>> Kind regards,
>>
>> Alessandro
>>
>> --
>> 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)
>
>
--
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)
RE: For Acuity: thanks for your JIRA Tickets on the Ontology Manager
Posted by Stephen Bayliss <st...@acuityunlimited.net>.
Hi Alessandro
Thanks very much for the update on this, we are looking forward to trying
out the latest codebase; we'll raise any questions we have over changes and
deprecations on the list.
Particularly thanks for your comments on the new OntologyProvider, we'll
give that a try and let you know how that works out.
Is this an appropriate point in time for us to upgrade to the latest SVN
release in terms of any work-in-progress on revisions to the OntoNet API?
Also, do you have any guidance on STANBOL-426, about resolving identifiers
between ontologies in Ontonet with identifiers from external systems? We'll
of course look at this in the context of the revisions to the codebase, but
any pointers you can provide will be gratefully received.
I've also just raised a JIRA over the scalability issue we had which you're
aware of, please let us know if the latest revisions also tackle this issue.
Thanks for your work on this, looking forward to taking our use-cases
forward based on these improvements to KReS.
Best Regards
Steve
> -----Original Message-----
> From: Alessandro Adamou [mailto:alessandro.adamou@istc.cnr.it]
> Sent: Wednesday, December 14, 2011 10:22 PM
> To: stanbol-dev@incubator.apache.org
> Subject: For Acuity: thanks for your JIRA Tickets on the Ontology Manager
>
> Dear Martin, Steve,
>
> Thanks very much for the issues just opened on Stanbol JIRA concerning
> ontology management.
>
> Most if not all of them were addressed in recent ontonet revisions, and
> I am documenting the changes with comments straight on the issue pages.
> Please feel free to follow up on them in case there are additional
> requirements or misalignments with the current state. I have roughly a
> couple of weeks to address any other issues coming up.
>
> As it turns out, some parts of the ontonet API were deprecated, but
> others could just not stay there and had to be removed altogether. I
> apologise if this gets to break any of your previous code, and will be
> glad to point you to their replacements in return.
>
> Thank you again for the great cooperation.
> Kind regards,
>
> Alessandro
>
> --
> 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)