mmisw / orr-portal Goto Github PK

After Help and Terms of use, how about a link called 'Contact us'? Could just link to the part of the Help pages that has Contact info.

(Capturing issue here for convenience, but fix is most likely to be in the backend, orr-ont)

http://cor.esipfed.org/ont3/?uri=http://data.gcoos.org/dp/data/Parameters.owl

triggers:

When I updated the metadata for the SWEET ontology, it didn't show existing metadata, then deleted the existing when I submitted the update.

The v2r display uses a single table for a vocabulary. Need to revisit this specially when dealing with large vocabularies.

This is about adjustments in conjunction with mmisw/orr-ont#2 toward the "self--dispatch" in orr-ont of the orrportal interface.

Needs adjustment to better reflect progress while file is being uploaded

I selected a few ontologies and tried to map a few terms, but couldn't see that anything was happening. I might have gotten one mapping to work, but that was it.

Also wasn't clear what the 2nd row from the bottom of the page was, that looked like 3 empty fields to fill in. Could be useful I'm guessing, but I'm not sure how.

I really don't like the ~ in the owner URIs. In addition to being a major pain to type -- so that I would try to become an organization or create my own URLs instead, if I had to -- it creates some confusion vs the regular URIs, and makes the owner ontologies seem a little less valuable.

I strong prefer just treating owners and organizations the same, and monitoring the list of owners and organizations so that duplicates are caught when they are created. I know that will create a scaleability issue someday, but I think it's worth it to make sure we get to that day.

We probably don't want --at least initially-- regular users to be able to create organizations directly. So we need an option for them to make corresponding request. Designated admin user can then (upon some form of notification) review the request.

in particular, in the v2r interface

Issue noted while importing CSV contents having Figure(s) as one of the column headers.

Besides documentation/tooltips/etc/, the tool should avoid entering invalid characters in the dialog itself:

and perhaps automatically replace them with underscores (or skip them) when importing.

The specific error was notified by Jena on the backend:

The workaround is of course not providing such invalid characters.

Found myself on the term search page with no obvious way to leave it. (Realized later I could have clicked on the COR icon in upper left.) Something explicit would be good...

In the ontology page only metadata is shown in the current prototype (0.0.9).

This entry is about determining strategies to incorporate ontology contents.

Re vocabulary contents:

From my March 27, 2015 email:

a possible approach I have in mind for a new ontology page is to be able to dispatch a customized viewer (in some embedded form perhaps) when some setting for this purpose is in place. For example, for the CF ontology, the viewer could be the CFSN browser. This is part of the intention with the generic vbrowser tool, which, via corresponding config files, can dispatch a good part of the registered vocabularies, eg.:

• https://mmisw.org/experimental/vbrowser/ioos_param/
• https://mmisw.org/experimental/vbrowser/ooi_epe_science/
• https://mmisw.org/experimental/vbrowser/cfsn/
• https://mmisw.org/experimental/vbrowser/cfat/

Users may not be sure about the specific format of the file they are uploading.

This could continue to be only available for an admin user.

• unregister particular version
• unregister whole ontology entry

Related mmisw/orr-ont#17
The error report from the backend is actually good enough already:

HTTP/1.1 400 Bad Request
Access-Control-Allow-Origin: *
...
{
    "detail": "org.xml.sax.SAXParseException; systemId: http://w3c.github.io/sdw/ssn/; 
          lineNumber: 55; columnNumber: 5; 
          The element type \"meta\" must be terminated by the matching end-tag \"</meta>\".",
    "error": "cannot load external ontology",
    "exceptionClassName": "com.hp.hpl.jena.shared.JenaException",
    "uri": "http://w3c.github.io/sdw/ssn/"
}

So we can expose some of this info in the UI along with something like:

The provided URI could not be loaded or parsed by the ORR backend. 
Please make sure you enter a HTTP URI that the corresponding remote
server can resolve to an ontology format (e.g., RDF/XML,  N3, OWL/XML, etc.)

Testing popup is offscreen left

• assume a successful login in a past session, along with the remember me option;
• later on, outside of the portal, the previous credentials are no longer valid for whatever reason (eg. password reset);
• when opening a new session, the stored cookie makes the logic consider the user already signed in, but subsequent operations will fail because of the associated credentials are actually invalid.

In specification of new property (v2r column or m2r mapping relation), allow to indicate whether it's a datatype (literal) or an object (uri) property.

Then adjust cell editing accordingly:

• only accept URI if object property
• accept string literal for datatype property (more specific type could be handled later)

Allow to capture not only one but multiple classes of terms in the vocabulary tool.

A related issue: mmisw/mmiorr#324

This is the UI counterpart of mmisw/orr-ont#10

Then, select owner:

The ontology name section becomes hidden.

Workaround: Enter ontology name first, then select owner.

Currently, admin can create organization and view full list of organizations. Need edit options (add/remove members...)

Although the update will fail in the backend, it should of course not be shown to the user if not authorized

Many of the metadata attributes have no useful explanation for their help tip. They just put up a URL, which seems like it would be helpful in some way but in fact isn't. All the tips from the original should be brought over.

Although entering a complete user-given URI is already supported, it will be very convenient to also allow selection from standard vocabularies, eg. RDF, DC, DCT, SKOS ... and from annotation properties like:

• owl:versionInfo
• rdfs:label
• rdfs:comment
• rdfs:seeAlso
• rdfs:isDefinedBy

Entry in old system: mmisw/mmiorr#380

One possible approach:

• Define a specific vocabulary for the default mapping relations; currently
  • skos:{exact/close/narrow/broad/related}Match
  • owl:sameAs
• the mapping editor exposes the relations in that vocabulary

(so, the above would be a general improvement to the tool)

• for new, user-given relations, allow to capture those in the mapping ontology itself. Ideally, the "new" relation for purposes of the mapping tool should actually be some standard one in the semantic community. As part of the relation specification, the user would enter the predicate URI along with additional, pre-establish set of attributes needed by the tool (desired symbol, tooltip, etc.)

Ok, that's a Real Big Issue. But thought I'd mention (both the other buttons use camel case).

If term set class dialog box name is apparently autocompleted in the browser, hitting the submit button doesn't fill out/accept the autocompletion. This is pretty minor but unexpected nonetheless.

I think we are in a brave new world and they aren't called URIs any more, they are called IRIs. If they are nicely internationalized they are, anyway. This shows up throughout the dialogs. (Sorry!)

Capture some sort of “organization manager” in the data model so only members with such role can edit the organization details (including membership list).

This is about a general review/handling of user-given strings that are either supposed to be complete IRIs, or used to compose IRIs (e.g., "local names").

In code adjustment for #33 we are currently restricting some characters that are in general considered unsafe (so this is OK), but also some that are not yet properly handled. For example, parens should be OK in a URI's local name, but are avoided at the moment.

UI counterpart of mmisw/orr-ont#11

The field is there, but not the traditional selection from http://mmisw.org/ont/mmi/resourcetype (instances of the ResourceType class).

The entry of metadata attributes is problematic.

a) If I enter an attribute and hit return or tab, or click in another field, I expect the original field to auto-update and close. I don't want to have to hit Apply each time.
b) If I go to another page (or field) without having hit Apply, I can't edit the metadata there, and there is no clue as to what the problem is (I'm not even on the tab where the problem is). I don't think it should be a problem to have multiple fields open, but if it is, see (a) -- leaving the context is saying 'enter this data'.

mmisw/mmiorr#322

This is now implemented but still to be tested.

The description that goes with the workflow of this dialog box isn't in the right context. We frame it in terms of the creation of the URI, but the user has no way to understand what the relationship of the URI sub-part is to the class name.

The thing that the user is doing, and that the user should understand, is creating a class name for the type of terms he or she is creating (in that term set). So the description should be "Define the name of the class that describes the type of terms you are creating (like the column header or name of the vocabulary). Note that this name will be used to build the URI for the class, so it should not have any special characters." (Is camel case appropriate? I'm not sure I remember any more, but thought it was recommended)

UI counterpart of mmisw/orr-ont#14

Currently, only simple name is implemented.

Test ontology: /ont/mmi/tool

In the create organization dialog box, the URI says http://cor.esipfed.org/ont3/org/. But I think the short name goes where it says 'org'. Oh! Wait, you're making a URI for the organization, aren't you? That wasn't clear, sorry.

It's worth a note too to say "the short name will be used in the IRIs of the vocabularies created for this organization".

In ontology metadata editing, allow user to add new properties. This could be done with a similar interface as in vocabulary tool, in particular with option to select from standards vocabularies, and option to enter a full URI..

For ontologies not authored with the ORR vocabulary (v2r) and mapping (m2r) tools, the two options for creating a new version are:

• (only) edit metadata -- implemented
• upload file -- not directly implemented yet. The workaround (but not intuitive) is to use the main upload option directly.

The prompt for defining the term set class is too obscure. The default should be Local, and the default should be the same name as used for the ontology. (This should work 80-90% of the time, I figure.)

The prompt should say something like "For most vocabularies, there will be only one term set, and its class will be the same as the name of the local file/ontology. These defaults are reflected below; click OK to accept them. (For ontologies with more than one term set, you are being asked for the class name for the first term set.)