Re: some more problems

Ivan Herman wrote:


> - I would love to be able to import another isv file, not only an rdf
> file. Here is what I need it for: I use an RDF vocabulary which is a
> bit large. I have therefore created a project, typed in all the
> properties in their own namespaces. I then store an empty project that
> way.
> 
> When I have to create a concrete RDF, the only way I can do it now is
> to start with the empty one I created above, add nodes and links, and
> store the project as a separate file. But if I wanted to have several
> of those empty projects, I would like to import them... I tried, it
> did not work.


One feature that can partially address your problem: the Load Properties 
button in the "property Types" tab of the "Definitions" window that lets 
you import vocabularies from existing RDF files and adds them to the 
property types list (you don't actually load the model itself, just the 
property types it contains). This way you don't have to enter them by hand.

But this only addresses partially your problem. It would indeed be nice 
to be able to merge several ISV projects as you can merge RDF files. 
I'll put that on the TODO list.


> - during editing, the tip of the arrowheads should touch the boundary of a
> resource. Currently the full arrowhead is inside the object.


Only half of it is in the object :). This can be annoying when you move 
a node as then the arrows pointing to it get drawn below the node and 
are more or less hidden. The best solution would indeed be to move the 
arrow head 'backward'. But that may not be easy. I'll see what I can do.

 
> - some manual editing features would be nice (I know it is extra
> work...). Eg, aligning a set of objects vertically, horizontally,
> distributing them, etc. Adding some attributes to some of the
> geometric elements (eg, colour) would also be great...


yes. This is part of a larger feature request to allow the definition of 
some kind of stylesheet that would specifiy the representation of nodes 
(shape, colour, size, etc...) based on semantic information about these 
nodes. Manual editing of these attributes would be a necessary subpart 
of this. I think this would be great, but I don't have time to do that 
right now. Maybe later, unless someone volunteers, in which case I'd be 
glad to discuss the matter and help as much as I can.

I did not think about alignement and distribution patterns. That's 
another good idea. Same remark as above w.r.t volunteers.




> 
> - I experienced a problem when I rerun a graph through dot. I am
> warned that the geometry will change, and that there is no return: fair
> enough. However, some other things change, too, like:
>         - the namespace prefix I had chosen for my own predicates (it
>         simply disappears)
>         - all resources, previously set as 'URI' are flipped to 'ID'
>         - the (nice) display prefix flag on namespaces on the right get all unset


-I am aware of this and intend to fix it.
-Ah! This is probably linked to Jena's serialization. I'll have to 
investigate.
-Linked to first problem - will be fixed at the same time.



> 
> - zoom in seems to hit a limit prematurely. I am not sure how, but
> sometimes I cannot zoom in any more although it would really make
> sense. As if the original way of creating the graph was the limit, but
> I am not sure


Can you be more specific? Can you send me a snapshot of this maximum 
level of magnification you'd like to go beyond?





> 
> - the property browser display is strange: it leaves a very large
> vertical space around each item


When there aren't enough items to fill the window vertically. True. Do 
you think I should change that?


> 
> - the use for abbreviated RDF syntax is great but I wonder whether
> there should not be a way of a finer control. If one has very deep
> graphs, that will create a very deeply nested XML file. For
> readability, I might want to 'break' this somehow, and put a resource
> back to the top level (but only that one). Would be nice to be able to
> control that.


Unfortunately, I rely on Jena for the serialization. The only thing I 
can tell it is whether I want to use abbreviated or non-abbreviated syntax.




> 
> - (I might be wrong on this one!) the current system does not allow me
> to use the same literal twice as an object of a predicate (as the
> target of an arrow). On the other hand, as far as I remember, sirpac
> generates a graph with a shared node there, I guess implicitly meaning
> a replication of the literal. It is very handy if one has, for
> example, a literal 'true' or 'false', because it reduces the visual
> clutter of the graph. With isaviz, I may have to repeat the literal as
> many times as I want to use it...


> 

No, you are right. I made this choice for the representation because 
there is no a priori reason why literals with the same value should be 
shared between different statements in a model. And it simplified my 
internal representation and processing :)
But allowing the user to share literals when he thinks this is 
appropriate is a good idea. It would it indeed reduce visual clutter and 
make editing less cumbersome in some situations.
Again, this has many implications and I cannot devote to much time to 
implementing new features right now. So it will have to wait unless 
someone volunteers. I'll put it on the TODO list.


Thanks,
Emmanuel



-- 
emmanuel.pietriga@xrce.xerox.com |  Xerox Research Centre Europe
Contextual Computing             |  6, Chemin de Maupertuis
tel: +33 4 76 61 50 32           |  38240 Meylan, France
fax: +33 4 76 61 50 99           |  http://www.xrce.xerox.com

Received on Tuesday, 19 March 2002 10:21:35 UTC