David Nickerson wrote: > Hi Tommy, > > Thought I'd just jot down some initial thoughts after following your > invitation to have a play with the new metadata tools on the model > repository :-) These are generally cosmetic suggestions more for your > consideration than any urgent requirement you need to act on... >
Thank you for your input :). Some of the issues are the result of making this page in the short time between the time of your last email and my announcement, but I will address them in due time. > The formatting of author/creator/modifier/etc names leaves a bit to be > desired. I'd suggest following a more standard pattern and removing the > '|' as the separation character. For example, something like: > G1 O1 F1, G2 O2 F2, & G3 O3 F3; or > F1, G1 O1, F2, G2 O2, & F3, G3 O3 > with F=Family, G=Given, O=other names where you drop O's where they are > not specified or add more in where needed. You'd imagine that then names > specified using the vCard:FN property would more naturally slot into > this kind of display. > Thank you for showing me how it should be displayed. I just tossed that part up in about 5 minutes without given much thought to it. I did rush it, as you can see ;) > If would be good to make the PubMed ID field a link to the PubMed page > for the given reference. > That would be useful. > Similarly, when editing a citation it would be good to simply specify a > PubMed ID or DOI or something similar and have the fields populated from > that database. > The repository we have now originally only supported PubMed ID, and the editor only reads data from the CellML file. If the database has an API to achieve that I would be interested in seeing how that could be done, but if not I will put the auto-population in the back burner. > While its hard to judge until more metadata is presented to the user, I > suspect the collapsing pane view is not going to be particularly easy to > navigate around. But I guess we can wait and see once there are some > more complete examples to play with. Nesting similar properties would > probably be a good idea (modification history, as you pointed out). > If you imagine the citation and the modification history being in the same page, you can see the benefits. Also, I could start by making an index at the top that links to the anchors that is in the heading of the various panels. Just an idea for now. > In the previous framework, each piece of metadata presented to the user > provided a link to the corresponding CellML/MathML code in the "view > cellml" tab. It would be good to keep this functionality. > Yup, the only issue was I don't yet have code to pull other cmeta:comment from the CellML file fully in place yet, but I don't imagine this being too hard to do. > While I haven't followed through with any changes, I'm hoping that > modifying a model's name or curation level will force the editor to also > add modification metadata to the model? You could perhaps pre-populate > the modification fields based on the changes the user is making... > I am working on placing the modification entry form into the metadata editing form if the user is uploading a new model. Curation level is not in the metadata specification yet, it only lives as an attribute on the repository (the edit page provides that). As for pre-populating modification fields, how would my code know what changes the user made to the model between the last version and the one she is uploading? There is no real version tracking code in the repository now, certainly no way to run diff between them. > It would be good to have a consistent interface for editing a person's > name. Currently when editing metadata there is a different interface for > the file creator, comment authors, and citation authors. I think the > citation author interface is the best, although possibly with all three > fields having equal width. And while I guess we can force people into > using the full vCard:N structure when they are entering data using this > editor it probably gets a bit tricky to also support the abbreviated > vCard:FN property.... > See below... > In the metadata editor, there is really nothing special about the CellML > Model Metadata, it just happens to be "about" the cellml:model resource. > It would be nice to be able to use the same interface to enter the same > kinds of metadata about any resource in the model document. For example, > it is quite useful to cite a particular source(s) for a variable value > or a particular modification to an equation. > While it wouldn't be too difficult to extend the editor to include that, I would think getting the basics down first before I start making further fancy additions, and I didn't want to start making drastic changes before I get the foundation solid. The features I have completed so far pretty much mimics what this PMR originally had, except using a proper library that abstracts operations away to classes for code that is much easier to maintain and to extend than what was there originally. Oh, not to mention the upload process is about 10 times faster now (it no longer takes about (or even over) a minute for PMR to upload/process a ~200 kilobyte model with loads of metadata), and generates correct RDF graphs that validated by W3C's RDF validator and with a graph that conforms to the CellML metadata specifications (I validated that visually). I also don't want to write a full fledge RDF editor right off the bat, if you know what I mean... Once again, thank you for your input, Andre. Kind Regards, Tommy. _______________________________________________ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
