Customizing User Access Control
Abhishek Salve
In my application, I want to create more fine-grained controls for
user access to editing.
One user group will only be able to edit instances.
A second user group will be able to edit instances for all classes
except for one (which is reserved for special editors).
(1) Currently, access is granted at the model-level, with the ability
to edit any resource. Is there a way to restrict it to instances only?
We don’t want our users to modify our class schema. Would you
recommend we create another model for only our instances? If we import
the model with our class schema into this “instance” model (e.g.
ABox), will users be able to edit assertions about the class schema as
well?
(2) Further, we also want to restrict editing access to a particular
class (whose subclasses contain our controlled vocabulary). Is there a
way to treat a particular class as special class only editable by some
users?
Here is what we are working with so far:
I want to create a separate user group, who has the permission of
grantModelView: AnyModel
denyModelView: SysOnt; OntoWiki/Config/
denyModelEdit: SysBase
grantAccess: Login
Now I want user to create instances of classes (which is already
created).
However, as we know that if we disable grantModelEdit then that user
group cannot EDIT, DELETE and CREATE resources, classes and instances.
I am trying to find a easy solution so that user can only create an
instance of a class.
Can I create a separate action (e.g. modelManagement) or Access
Control (e.g. grantModelEdit)? If “yes” then where I need to define
them? Do I also need to edit the ServiceController?
Thanks in advance
Regards,
Abhishek
Sebastian Tramp
Hi Abhishek Salve,
> In my application, I want to create more fine-grained controls for
> user access to editing.
> One user group will only be able to edit instances.
> A second user group will be able to edit instances for all classes
> except for one (which is reserved for special editors).
OntoWiki can not distinguish between resources for access control. If a user
has access to modify a model, he can add any triples to it (but its easy to
clean if you "define" one model as instance only model)
> (1) Currently, access is granted at the model-level, with the ability
> to edit any resource. Is there a way to restrict it to instances
> only? We don’t want our users to modify our class schema. Would you
> recommend we create another model for only our instances?
yes, and import the class model from that.
> If we import the model with our class schema into this “instance”
> model (e.g. ABox), will users be able to edit assertions about the
> class schema as well?
They can't delete your existing statements but can add one
> (2) Further, we also want to restrict editing access to a particular
> class (whose subclasses contain our controlled vocabulary). Is there a
> way to treat a particular class as special class only editable by some
> users?
no. Out of the box you can only hide classes you do not want to have in the
navigation module.
For sure I can imagine a plugin which hides the edit functionality for
a specify class instances but you can not enforce it over the non-gui
interfaces so easy (sparql update, add to knowledgebase, command line
interface, RPC service).
you could write a plugin which exits if there is triple of form (?x
a your:Class) but we did not test something like that yet.
> Here is what we are working with so far:
>
> I want to create a separate user group, who has the permission of
> grantModelView: AnyModel
> denyModelView: SysOnt; OntoWiki/Config/
> denyModelEdit: SysBase
> grantAccess: Login
> Now I want user to create instances of classes (which is already
> created). However, as we know that if we disable grantModelEdit then
> that user group cannot EDIT, DELETE and CREATE resources, classes and
> instances.
I am not sure what you exactly want here but why not disallow to edit anyModel
and allow to edit your specific instances model?
Best regards
Sebastian Tramp
> Can I create a separate action (e.g. modelManagement) or Access
> Control (e.g. grantModelEdit)? If “yes” then where I need to define
> them? Do I also need to edit the ServiceController?
>
> Thanks in advance
>
> Regards,
> Abhishek
--
Sebastian Tramp
WebID: http://sebastian.tramp.name
Abhishek Salve
questions.
Please see replies in line.
Regards,
Abhishek
On Jul 28, 10:41 am, Sebastian Tramp <m...@sebastian.tramp.name>
wrote:
>
> Hi Abhishek Salve,
>
> > In my application, I want to create more fine-grained controls for
> > user access to editing.
> > One user group will only be able to edit instances.
> > A second user group will be able to edit instances for all classes
> > except for one (which is reserved for special editors).
>
> OntoWiki can not distinguish between resources for access control. If a user
> has access to modify a model, he can add any triples to it (but its easy to
> clean if you "define" one model as instance only model)
>
> > (1) Currently, access is granted at the model-level, with the ability
> > to edit any resource. Is there a way to restrict it to instances
> > only? We don’t want our users to modify our class schema. Would you
> > recommend we create another model for only our instances?
>
> yes, and import the class model from that.
owl:imports) and noticed that
The only classes that displayed on the hierarchical class viewer
(Navigation:Classes) were ones that had instances defined for them. We
will not necessarily have instances for all classes pre-defined.
Is there a way to show all the classes of the imported model within
the “instance model” even if
There are no instances defined on some classes?
Also, we were unable to display the properties through the
hierarchical viewer (Navigation:Classes).
Is there a way to enable the Navigation view for properties within
this “instance model”?
We did find that, within the instance model, as Admin, we could edit
the “label” of a resource which was defined in our class model. This
label change was persistent in the “Properties” tab view within
“Properties of Instance”, but was not changed in the “Source” tab (nor
the original class model).
>
> > If we import the model with our class schema into this “instance”
> > model (e.g. ABox), will users be able to edit assertions about the
> > class schema as well?
>
> They can't delete your existing statements but can add one
>
> > (2) Further, we also want to restrict editing access to a particular
> > class (whose subclasses contain our controlled vocabulary). Is there a
> > way to treat a particular class as special class only editable by some
> > users?
>
> no. Out of the box you can only hide classes you do not want to have in the
> navigation module.
>
> For sure I can imagine a plugin which hides the edit functionality for
> a specify class instances but you can not enforce it over the non-gui
> interfaces so easy (sparql update, add to knowledgebase, command line
> interface, RPC service).
>
Does the “SPARQL query editor” allow
SPARQL Updates? I got an error creating an insert statement: INSERT
{myproj:Test rdf:type myproj:Class}.
We are on Virtuoso. Is there a way to disallow other interfaces or is
OntoWiki written in such a way that we can’t prevent http posts?
Sebastian Tramp
> > > (1) Currently, access is granted at the model-level, with the
> > > ability to edit any resource. Is there a way to restrict it to
> > > instances only? We don’t want our users to modify our class
> > > schema. Would you recommend we create another model for only our
> > > instances?
> >
> > yes, and import the class model from that.
>
> We created an instance model which imported the class model (via
> owl:imports) and noticed that The only classes that displayed on the
> hierarchical class viewer (Navigation:Classes) were ones that had
> instances defined for them. We will not necessarily have instances for
> all classes pre-defined. Is there a way to show all the classes of the
> imported model within the “instance model” even if There are no
> instances defined on some classes?
You can change this in the config of the extension "navigation". there
should exist a showEmptyElements option for class navigation.
> Also, we were unable to display the properties through the
> hierarchical viewer (Navigation:Classes). Is there a way to enable the
> Navigation view for properties within this “instance model”?
You change the navigation type from the Type menu navigation module.
Please try this on the knowledge base "OntoWiki System Configuration".
If it works there and not in your model, maybe its a bug in combination
with your data ...
> We did find that, within the instance model, as Admin, we could edit
> the “label” of a resource which was defined in our class model.
> This label change was persistent in the “Properties” tab view
> within “Properties of Instance”, but was not changed in the
> “Source” tab (nor the original class model).
if you modify a resource from another model inside your importing model,
you split your statements. I assume the new label is in the importing
model which the old label is still in the imported model.
> > For sure I can imagine a plugin which hides the edit functionality
> > for a specify class instances but you can not enforce it over the
> > non-gui interfaces so easy (sparql update, add to knowledgebase,
> > command line interface, RPC service).
>
> We were planning to only offer read-access for non-GUI interfaces.
> Does the “SPARQL query editor” allow SPARQL Updates? I got an
> error creating an insert statement: INSERT {myproj:Test rdf:type
> myproj:Class}. We are on Virtuoso. Is there a way to disallow other
> interfaces or is OntoWiki written in such a way that we can’t
> prevent http posts?
Not in an easy way at the moment. I could imagine more action identifier
to allow more fine grained access control. This seems to be the easiest
way to solve this use case.
Best regards
Sebastian Tramp
--
Sebastian Tramp - Department of Computer Science; University of Leipzig
WebID: http://sebastian.tramp.name Tel. (Fax): +49 341 97 323-66 (-29)
lisa
We are testing various aspects of the importing. It appears that the
import is not dynamic?
That is. I have two models, For_Editors, For_Contributors.
For_Contributors imports For_Editors so that they can see the
instances in a special class that
the editors have created.
As an editor, I have access to the For_Editors model. I add an
instance to a class.
When I then access For_Contributors, I would like to see that new
instance reflected in that class. However, it doesn't show, even after
I "destroyed session".
Ideas on how we can configure this behavior?
Thanks!
lisa
On Aug 3, 3:37 am, Sebastian Tramp <tr...@informatik.uni-leipzig.de>
wrote:
Sebastian Tramp
> Hi Sebastian, We are testing various aspects of the importing. It
> appears that the import is not dynamic?
It should be dynamic. The transitive closure of all imported knowledge
bases is added to the FROM section of the query so that these queries
are evaluated on the correct set of graphs.
maybe there is a problem with the cache. can you please:
1. Turn the debug mode on (add "debug = true" at the end of config.ini)
2. Delete the cache using the newly visible debug menu
3. Try your queries again
If this does not work:
1. Turn of the cache (add "cache.query.enable = false" to config.ini )
2. Try your queries again
> That is. I have two models, For_Editors, For_Contributors.
>
> For_Contributors imports For_Editors so that they can see the
> instances in a special class that the editors have created.
>
> As an editor, I have access to the For_Editors model. I add an
> instance to a class.
>
> When I then access For_Contributors, I would like to see that new
> instance reflected in that class. However, it doesn't show, even after
> I "destroyed session".
Even with the Admin user? Graph import works in combination with ACLs so if
a user does not has access to the graph, he can't see/edit it even if his own
graph imports it.
lisa
It looks like there I am having some issue with owl:imports. I have
tested this on two machines. One which has v.0.9.6./MySQL (Ubuntu) and
another which has v. 0.9.6 (Revision: a9ebe11cc2c7)/Virtuoso (SLES).
This is from the imported ontology:
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns="http://www.test.org/test/ForEditors#"
xml:base="http://www.test.org/test/ForEditors">
<owl:Ontology rdf:about="">
<owl:versionInfo rdf:datatype="http://www.w3.org/2001/
XMLSchema#string"
>Created with TopBraid Composer</owl:versionInfo>
</owl:Ontology>
-----------
For the imported ontology, I find this in the "source" tab and
corresponding property/values in the "properties" tab.
# Exported with the Erfurt API - http://aksw.org/Projects/Erfurt
@base <http://www.test.org/test/ForEditors> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
<http://www.test.org/test/ForEditors> a owl:Ontology ;
owl:versionInfo "Created with
TopBraid Composer"^^xsd:string ..
---
But for the file that is importing:
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns="http://www.udfr.org/test/forContributors#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:ForEditors="http://www.udfr.org/test/ForEditors#"
xml:base="http://www.test.org/test/forContributors">
<owl:Ontology rdf:about="">
<owl:imports rdf:resource="http://www.test.org/test/ForEditors"/>
<owl:versionInfo rdf:datatype="http://www.w3.org/2001/
XMLSchema#string"
>Created with TopBraid Composer</owl:versionInfo>
</owl:Ontology>
--
I get this in the "source" tab (and, correspondingly, no property/
values in the "properties" tab):
# Exported with the Erfurt API - http://aksw.org/Projects/Erfurt
@base <http://www.test.org/test/ForContributors> .
@prefix foreditors: <http://www.test.org/test/ForEditors#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
--
This is confusing, because it looks like my "owl" prefix has been
defined.
Am I missing something obvious?
Thanks again, in advance.
Regards,
Lisa
On Aug 11, 2:04 am, Sebastian Tramp <tr...@informatik.uni-leipzig.de>
wrote:
lisa
My understanding is that there is current only one access control to
the Virtuoso database from OntoWiki.
Is there a way we can control SPARQL Updates so that some users can
run SPARQL Updates from the Query tab and others cannot?
Lisa
On Aug 3, 3:37 am, Sebastian Tramp <tr...@informatik.uni-leipzig.de>
wrote:
> > Does the “SPARQL query editor” allow SPARQL Updates? I got an
> > error creating an insert statement: INSERT {myproj:Test rdf:type
> > myproj:Class}. We are on Virtuoso. Is there a way to disallow other
> > interfaces or is OntoWiki written in such a way that we can’t
> > prevent http posts?
>
> Not in an easy way at the moment. I could imagine more action identifier
> to allow more fine grained access control. This seems to be the easiest
> way to solve this use case.
Sebastian Tramp
> My understanding is that there is current only one access control to
> the Virtuoso database from OntoWiki.
>
> Is there a way we can control SPARQL Updates so that some users can
> run SPARQL Updates from the Query tab and others cannot?
Hi lisa, for my knowledge - the query tab does not SPARQL update at all
... so this is not a problem. If you want to hide the query tab from a
specific user group, we could easily create a new action for that.
Best regards
Sebastian Tramp
>
> Lisa
>
>
> On Aug 3, 3:37 am, Sebastian Tramp <tr...@informatik.uni-leipzig.de>
> wrote:
>
> > > We were planning to only offer read-access for non-GUI interfaces.
> > > Does the “SPARQL query editor” allow SPARQL Updates? I got an
> > > error creating an insert statement: INSERT {myproj:Test rdf:type
> > > myproj:Class}. We are on Virtuoso. Is there a way to disallow
> > > other interfaces or is OntoWiki written in such a way that we
> > > can’t prevent http posts?
> >
> > Not in an easy way at the moment. I could imagine more action
> > identifier to allow more fine grained access control. This seems to
> > be the easiest way to solve this use case.
>
> > -- Sebastian Tramp - Department of Computer Science; University of
> > Leipzig WebID:http://sebastian.tramp.name Tel. (Fax): +49 341 97
> > 323-66 (-29)
>
> F
Lisa Dawn Colvin
On Mon, Aug 29, 2011 at 04:12:47PM -0700, lisa wrote:Hi lisa, for my knowledge - the query tab does not SPARQL update at all
> My understanding is that there is current only one access control to
> the Virtuoso database from OntoWiki.
>
> Is there a way we can control SPARQL Updates so that some users can
> run SPARQL Updates from the Query tab and others cannot?
... so this is not a problem. If you want to hide the query tab from a
specific user group, we could easily create a new action for that.
What we want to do is load our ontology with a data set from a defined source. We are using the History tab as a way of capturing provenance for new statements. I was wondering how to capture the provenance of existing data that we are importing into our model. I was thinking I could use the Query tab to do a SPARQL update which would then capture information of the logged-in user. It didn't seem like we could write History information directly to the database as there are some randomly generated transaction(?) ids.
Do you have other ideas on how to do this within the OntoWiki platform? Perhaps we can have additional information on the imported ontology itself, but how would a user know that a particular triple came from the imported ontology versus the main ontology? Is it possible to add a link for ontology source (like a graph id) per triple? Perhaps I am thinking about this the wrong way?
Best Regards,
Lisa
Sebastian Tramp
> What we want to do is load our ontology with a data set from a defined
> source. We are using the History tab as a way of capturing provenance
> for new statements. I was wondering how to capture the provenance of
> existing data that we are importing into our model.
If you import the ontology e.g. with the jsonrpc service, over owcli, you will
get another transaction description so you can see, which history state is the
base line of your upload.
using erfurt, you could also create your own "transaction types"
Best regards
Sebastian Tramp
> I was thinking I could use the Query tab to do a SPARQL update which
> would then capture information of the logged-in user. It didn't seem
> like we could write History information directly to the database as
> there are some randomly generated transaction(?) ids.
>
> Do you have other ideas on how to do this within the OntoWiki
> platform? Perhaps we can have additional information on the imported
> ontology itself, but how would a user know that a particular triple
> came from the imported ontology versus the main ontology? Is it
> possible to add a link for ontology source (like a graph id) per
> triple? Perhaps I am thinking about this the wrong way?
>
> Best Regards, Lisa
--
Lisa Dawn Colvin
On Tue, Aug 30, 2011 at 09:54:24AM -0700, Lisa Dawn Colvin wrote:If you import the ontology e.g. with the jsonrpc service, over owcli, you will
> What we want to do is load our ontology with a data set from a defined
> source. We are using the History tab as a way of capturing provenance
> for new statements. I was wondering how to capture the provenance of
> existing data that we are importing into our model.
get another transaction description so you can see, which history state is the
base line of your upload.
We currently don't have owcli installed, but once installed, if we do something like create model/add triples:
"owcli -m http://localhost/model1# --create --add -i model.rdf"
We will get some sort of history state variable value in our output? Is there a name for this variable that we can see referenced in the erfurt code?
using erfurt, you could also create your own "transaction types"
Where are these types being stored in Virtuoso? We noticed the erfurt statement table used in MySQL. However, Virtuoso is being used as a triple store. Is there somewhere in Virtuoso where these various transaction IDs are referencing the triples and graph IDs (in the triple store)?
Many thanks again!
Regards,
Lisa
Lisa Dawn Colvin
A few more questions:
1. Are these the "history state" variables you were referring to?
const MODEL_IMPORTED = 10;
const STATEMENT_ADDED = 20;
const STATEMENT_CHANGED = 21;
const STATEMENT_REMOVED = 22;
const STATEMENTS_ROLLBACK = 23;
2. What we want to show is that for every statement added through this particular import, we want there to be history which attributes each statement to the User ID which is logged in. That way, we have provenance of everything in the system.
We could create another transaction type for display. We were wondering where in the erfurt code is the history established? Could we alter the code such that upon model import, the history that is created as a result of STATEMENT_ADDED is added to all statements to the model that is imported?
best regards,
lisa
Sebastian Tramp
> > > What we want to do is load our ontology with a data set from a
> > > defined source. We are using the History tab as a way of capturing
> > > provenance for new statements. I was wondering how to capture the
> > > provenance of existing data that we are importing into our model.
> >
> > If you import the ontology e.g. with the jsonrpc service, over
> > owcli, you will get another transaction description so you can see,
> > which history state is the base line of your upload.
>
> We currently don't have owcli installed, but once installed, if we do
> something like create model/add triples:
>
> "owcli -m http://localhost/model1# --create --add -i model.rdf"
>
> We will get some sort of history state variable value in our output?
you will get a history entry like "jsonrpc import" which represents the
complete transaction of all triples.
> Is there a name for this variable that we can see referenced in the
> erfurt code?
see next mail ...
> > using erfurt, you could also create your own "transaction types"
>
> Where are these types being stored in Virtuoso?
in extra tables outside the triple store. They are called
ef_versioning_actions and ef_versioning_payload
> We noticed the erfurt statement table used in MySQL. However, Virtuoso
> is being used as a triple store. Is there somewhere in Virtuoso where
> these various transaction IDs are referencing the triples and graph
> IDs (in the triple store)?
this is all described in these two tables. (trans)actions are described
witch: id, model(uri), useruri, resource(uri - to allow more easy
query), tstamp, action_type, parent(id of action) and payload_id
payloads are deleted or added triple.
Best regards
Sebastian Tramp
Sebastian Tramp
Hi Lisa,
> A few more questions:
>
> 1. Are these the "history state" variables you were referring to?
> * const *MODEL_IMPORTED = 10;
> *const *STATEMENT_ADDED = 20;
> *const *STATEMENT_CHANGED = 21;
> *const *STATEMENT_REMOVED = 22;
> *const *STATEMENTS_ROLLBACK = 23;
yes, these ids are used in the action_type column. you can use your own action
Ids there - the jsonrpc service creates an action in this way:
you see, creates an action type 80201
/**
* @desc add all input statements to the model
* @param string $modelIri
* @param string $inputModel
* @return bool
*/
public function add($modelIri, $inputModel)
{
$model = $this->store->getModel($modelIri);
$versioning = $this->erfurt->getVersioning();
$actionSpec = array();
$actionSpec['type'] = 80201;
$actionSpec['modeluri'] = (string) $model;
$actionSpec['resourceuri'] = (string) $model;
$versioning->startAction($actionSpec);
$model->addMultipleStatements($inputModel);
$versioning->endAction();
return true;
}
all you need to do is, to provide proper translations for your action items.
which means, this line somewhere in a translation csv:
HISTORY_ACTIONTYPE_80201;JSON/RPC model->add
(note, the action id is not used plain but with a prefix ...)
> 2. What we want to show is that for every statement added through
> this particular import, we want there to be history which attributes
> each statement to the User ID which is logged in. That way, we have
> provenance of everything in the system.
can you explain this a bit more, I didnt understand the point ...
> We could create another transaction type for display.
Displaying a resource? That would be possible I think. in this case, there is
no payload for that action.
> We were wondering where in the erfurt code is the history established?
Erfurt_Versioning for the api and extensions/history for the ontowiki
components.
> Could we alter the code such that upon model import, the history that
> is created as a result of STATEMENT_ADDED is added to all statements
> to the model that is imported?
Sorry, I'm not sure what exactly you want. can you give me an
before/after example?
ST
Lisa Dawn Colvin
Thanks for the detailed information about the versioning tables and the json rpc service.
I realize my explanation wasn't that clear. :)
Prior State:
Knowledge Base #1 (KB1) exists as a file.
Desired State:
We want add KB1 to our OntoWiki via "Create Knowledge Base"
On the "Create New Knowledge Base" tab, we want to add another button which is something like "Create Knowledge Base and Add History".
When you normally "Create Knowledge Base", there is no History (rightfully so!) for any of the triples that are imported.
Since we are using the History tab as a way of tracking provenance of changes, we also thought it would be useful to have it track the provenance of the original triples as we are integrating multiple data sources together.
We realize that we could have provenance information on the ontology itself, but thought it would be more helpful to have the history captured at the triple level as some of our data sources may need editing. We currently have a "Review" action which lets some users review and approve statements.
So, when one clicks on "Create Knowledge Base and Add History" what we want to happen is that every triple is loaded into the knowledge base. In addition, for every triple there is a "Statement added" History row that is also created. The timestamp will be the load time (perhaps we can change the Action type to "Statement loaded" to more accurately represent that the timestamp is associated with loading action). The user will be whomever is logged in. We were planning on creating special user accounts which represent the data sources.
Does this make sense?
Basically, we are creating a registry, but it will be pre-populated with some existing data sources (which could be changed by the users).
Thanks again, in advance ,
Kind Regards,
Lisa
Sebastian Tramp
> Thanks for the detailed information about the versioning tables and
> the json rpc service.
> Prior State: Knowledge Base #1 (KB1) exists as a file.
>
> Desired State: We want add KB1 to our OntoWiki via "Create Knowledge
> Base"
ok :-)
> On the "Create New Knowledge Base" tab, we want to add another button which
> is something like "Create Knowledge Base and Add History".
>
> When you normally "Create Knowledge Base", there is no History (rightfully
> so!) for any of the triples that are imported.
ok, I understand.
I just looked in the code. The versioning is explicitly deactivated for the
import. If you want to activate it, just delete line 532 in the ModelController
$versioning->enableVersioning(false);
It seems to be a bit of a windows start button philosophy :)
> Since we are using the History tab as a way of tracking provenance of
> changes, we also thought it would be useful to have it track the provenance
> of the original triples as we are integrating multiple data sources
> together.
ok, thats clear. but I am not sure why it was disabled. maybe for performance
reasons but really big models should be imported with isql to virtuoso
anyway, so feel free to test around with that.
If you are interested, we can add a config option for that if you tested this
strategy and it works.
> We realize that we could have provenance information on the ontology itself,
> but thought it would be more helpful to have the history captured at the
> triple level as some of our data sources may need editing. We currently have
> a "Review" action which lets some users review and approve statements.
interesting. where do you save the triple statup?
Best regards
Sebastian Tramp
--
WebID: http://sebastian.tramp.name
Lisa Dawn Colvin
On Wed, Aug 31, 2011 at 10:00:46AM -0700, Lisa Dawn Colvin wrote:
I just looked in the code. The versioning is explicitly deactivated for the
import. If you want to activate it, just delete line 532 in the ModelController
$versioning->enableVersioning(false);
It seems to be a bit of a windows start button philosophy :)
yes :)
Thank you!! This is exactly what we needed.
> Since we are using the History tab as a way of tracking provenance ofok, thats clear. but I am not sure why it was disabled. maybe for performance
> changes, we also thought it would be useful to have it track the provenance
> of the original triples as we are integrating multiple data sources
> together.
reasons but really big models should be imported with isql to virtuoso
anyway, so feel free to test around with that.
If you are interested, we can add a config option for that if you tested this
strategy and it works.
otherwise, it is ok for us to just comment it out in our branch as we are making other edits (in ontowiki, erfurt and RDFauthor) as well.
> We realize that we could have provenance information on the ontology itself,interesting. where do you save the triple statup?
> but thought it would be more helpful to have the history captured at the
> triple level as some of our data sources may need editing. We currently have
> a "Review" action which lets some users review and approve statements.
When we are done with our project, we will be posting it as open source (following the ontowiki licensing) so if there is anything useful there that you want to reuse... :) We currently are managing two repositories - one mercurial (for OntoWiki and RDFauthor) which is internal (but will be posted later on) and another repository which is external (github) for erfurt changes. Since erfurt library was git, we decided it would be easier to create a git repository rather than deal with any issues between mercurial and git down the road.
best regards,
Lisa
Sebastian Tramp
> When we are done with our project, we will be posting it as open
> source (following the ontowiki licensing) so if there is anything
> useful there that you want to reuse... :) We currently are managing
> two repositories - one mercurial (for OntoWiki and RDFauthor) which is
> internal (but will be posted later on) and another repository which is
> external (github) for erfurt changes. Since erfurt library was git, we
> decided it would be easier to create a git repository rather than deal
> with any issues between mercurial and git down the road.
sounds good - is your project then publicly available?
lisa dawn
lisa
We were testing this again and found it does not work for our Linux/
Virtuoso implementation. When we were testing it earlier, it was on a
Linux/MySQL version. We are using Virtuoso 6.1.3 and SUSE Linux
Enterprise Server (SLES).
Do you think this is an issue with Virtuoso?
You had mentioned it is possible to add a configuration option if we
were to load directly to Virtuoso? We don't anticipate our models to
be that big, but could be helpful to have that option.
What is most important for us, for this version, is to have this
functionality upon import. We are treating other data sources as
imports so that they their provenance is tracked.
Thanks again :)
lisa
>
> I just looked in the code. Theversioningis explicitly deactivated for the