2 bugs in build 304

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

2 bugs in build 304

Daniel Elenius
1) If I create a property with subproperties, I can't promote the
subproperties to outside of their superproperty. Dragging and dropping
them does nothing.

2) If I have two ontologies, A and B, where A imports and refers to B,
and then change B (e.g. by renaming a class that is referred to in A),
subsequently loading A is problematic. Protege tries to fix this by
adding placeholder classes for the missing ones, which is a good
solution. But it's buggy. It seems like it doesn't add all that's
needed. What happens is that I can't select (in the class tab hierarchy)
the class that refers to the now non-existent imported class.  So
essentially my importing ontology is broken. What's worse, there's not
really *any* good way of doing this, which seems like a common thing to
need to do.

Here's a feature request: Even after the bugs in this
creating-missing-classes code are fixed, the user will need to look at
them and do something about these classes and the references to them. So
how about adding a TODO item to all such auto-generated classes, and
also to each class that references them. Then it will be easy for users
to handle this.

Daniel
-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

Reply | Threaded
Open this post in threaded view
|

Re: 2 bugs in build 304

Nick Drummond
Daniel,

1) added to the list

2) if you do this within Protege, then the rename works fine.
Its only if B changes outside that we have no control over updating A.
It's like someone rewriting a software library, changing all the
interfaces and expecting everyones code to still work :)
Renaming effectively removes the existing resource. So, in most cases
Protege just creates an untyped external resource - they aren't always
classes and without an rdf:type statement for the old reference how do
we know what to create??
The problem with patching is that it requires a huge set of metrics that
say if a reference is used in a particular context then it must be of a
particular type. eg if aClass is a subclass of bClass (which no longer
exists in b.owl) then bClass must be an rdfs class.

I agree that there should be an automatic TODO on these resources - I
will add a feature request.

Nick

Daniel Elenius wrote:

> 1) If I create a property with subproperties, I can't promote the
> subproperties to outside of their superproperty. Dragging and dropping
> them does nothing.
>
> 2) If I have two ontologies, A and B, where A imports and refers to B,
> and then change B (e.g. by renaming a class that is referred to in A),
> subsequently loading A is problematic. Protege tries to fix this by
> adding placeholder classes for the missing ones, which is a good
> solution. But it's buggy. It seems like it doesn't add all that's
> needed. What happens is that I can't select (in the class tab
> hierarchy) the class that refers to the now non-existent imported
> class.  So essentially my importing ontology is broken. What's worse,
> there's not really *any* good way of doing this, which seems like a
> common thing to need to do.
>
> Here's a feature request: Even after the bugs in this
> creating-missing-classes code are fixed, the user will need to look at
> them and do something about these classes and the references to them.
> So how about adding a TODO item to all such auto-generated classes,
> and also to each class that references them. Then it will be easy for
> users to handle this.
>
> Daniel
> -------------------------------------------------------------------------
> To unsubscribe go to http://protege.stanford.edu/community/subscribe.html
>
>

--

Nick Drummond

http://www.cs.man.ac.uk/~drummond/ <http://www.cs.man.ac.uk/%7Edrummond/>
-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html