mmisw / orr-portal

ORR Frontend component
Apache License 2.0
8 stars 5 forks source link

Workflow for defining IRIs: term set class #41

Closed graybeal closed 8 years ago

graybeal commented 8 years ago

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.)

screen shot 2016-07-04 at 3 53 01 pm
carueda commented 8 years ago

The prompt for defining the term set class is too obscure.

Does the recent fix to #47 cover at least part of this?

The default should be Local,

It's been local from the beginning, so no sure what you saw instead

and the default should be the same name as used for the ontology. (This should work 80-90% of the time, I figure.)

Just to be clear, indicating the name of the class is nothing new --it's been there for ages in the "old" system, so this discussion could have happened a while ago! unless my memory is failing me 😄

But this is certainly a rather tricky, potentially confusing aspect in the tool. With your example ontology:

 http://cor.esipfed.org/ont3/~esipdemo/bodyofwater

the term class would be

http://cor.esipfed.org/ont3/~esipdemo/bodyofwater/BodyOfWater

so some people may find this as some form of duplication.

We could avoid prompting the user for the term class altogether and instead use the ontology URI http://cor.esipfed.org/ont3/~esipdemo/bodyofwater also to identify the term class ... but this could probably open another can of worms (for example, this likely will render an ontology OWL Full, which otherwise would be DL..) -- we will have to investigate the concrete implications when time permits.

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.

well, let's do that for the time being, with a minor edit: "For most vocabularies, there will be only one term set, and its class will typically be the same (but camel case) as the local name of the ontology.

These defaults are reflected below; click OK to accept them.

So, you are suggesting that the local class name be initialized with the local name of the ontology (capitalized), right?

(For ontologies with more than one term set, you are being asked for the class name for the first term set.)

I don't follow here ... the tool currently prompts for the class name on every term set.

graybeal commented 8 years ago

All good, comments inline if more info needed.

On Jul 6, 2016, at 9:01 PM, Carlos Rueda notifications@github.com<mailto:notifications@github.com> wrote:

The prompt for defining the term set class is too obscure.

Does the recent fix to #47https://github.com/mmisw/orr-portal/issues/47 cover at least part of this?

I think all of it

The default should be Local,

It's been local from the beginning, so no sure what you saw instead

It wasn’t obvious that “Local” (whatever that meant) was selected as the default. I kept clicking on it to try to select it even though it was already selected.

and the default should be the same name as used for the ontology. (This should work 80-90% of the time, I figure.)

Just to be clear, indicating the name of the class is nothing new --it's been there for ages in the "old" system, so this discussion could have happened a while ago! unless my memory is failing me 😄

true

But this is certainly a rather tricky, potentially confusing aspect in the tool. With your example ontology:

http://cor.esipfed.org/ont3/~esipdemo/bodyofwater

the term class would be

http://cor.esipfed.org/ont3/~esipdemo/bodyofwater/BodyOfWater

so some people may find this as some form of duplication.

making the distinction between the local ontology name, and the class, is the key thing that makes it all clear. I think you are doing that well now.

We could avoid prompting the user for the term class altogether and instead use the ontology URI http://cor.esipfed.org/ont3/~esipdemo/bodyofwater also to identify the term class ... but this could probably open another can of worms (for example, this likely will render an ontology OWL Full, which otherwise would be DL..) -- we will have to investigate the concrete implications when time permits.

don’t like this, for the reason you give. way risky.

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.

well, let's do that for the time being, with a minor edit: "For most vocabularies, there will be only one term set, and its class will typically be the same (but camel case) as the local name of the ontology.

These defaults are reflected below; click OK to accept them.

So, you are suggesting that the local class name be initialized with the local name of the ontology (capitalized), right?

yes, not that you’ll know how to camel case that :-)

(For ontologies with more than one term set, you are being asked for the class name for the first term set.)

I don't follow here ... the tool currently prompts for the class name on every term set.

the point is that at this stage, the user has no concept of producing multiple term sets (even if they plan to, this isn’t the interface for it). So your explanation addresses both naive and advanced users in this regard, good job!

carueda commented 8 years ago

Added some text and improved the visual feedback for the "Local name" vs. "Full URI" selection. Also the relevant field is automatically focused. Now looks like this in 3.0.5-alpha:

image

graybeal commented 8 years ago

is perfect