URIs and Labels - Issues with new entity options

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

URIs and Labels - Issues with new entity options

Gibson, A.P.
URIs and Labels - Issues with new entity options

I am really pleased to see some work towards managing the consistent labelling of new entities in an ontology with the "New Entities" tab in the Preferences - especially support for Auto IDs.

BUT

theres a few bugs and odd behaviours :-), and a veritable 'exploding bicycle' of possible rendering outcomes depending on different user settings.

I'm not sure what the default setting for labelling new entities is - so I'll cycle through as many as I can find:

1) See 'NewEntity1' in attached ontology
Setting: In the 'New Entities' tab, in the 'Entity Name' section, with *only* the radio button for 'User Supplied Name' selected

Outcome: New entities get the URI of the name that the user entered. This is the same behaviour as you would get in older versions where 'Render entities using URI fragment' was selected.

Observation: There is no annotation created (as expected), but the renderer defaults to rendering with the URI fragment, even with the 'render entities using annotation values' option selected in the renderer. There is no visual clue (apart from the absence of a label) that this has happened - so in an ontology with a mixture of labelled and unlabelled classes, theres no clue that they are encoded differently 'under the hood'.

2) See 'NewEntity2(a,b,c) in attached ontology
Setting: In the 'New Entities' tab, in the 'Entity Name' section, with the radio button for 'User Supplied Name' selected *and* the 'create label' checkbox selected.

Outcome: This is a new possible combination where both the URI fragment and the Label get created with the user supplied label.

Observation: This is dangerous. Initially there will be no difference to the user whether they are rendering with URI fragments or labels (as with NewEntity2a). BUT then you are open to the possibility that a user changes EITHER the label (see class with URI NewEntity2b) OR the URI fragment (see class with Label NewEntity2c). As a developer, unless you are sure that different people have their Protege rendering set up the same way, ontologies will most likely end up with a mixture of these and some very confused people and URI resolvers, especially with multiple users.

3) See NewEntity3 in attached ontology
Setting: In the 'New Entities' tab, in the 'Entity Name' section, with the radio button for 'AutoID' selected *and* the 'create label' checkbox selected (happens automatically).

Outcome: This is *almost* my preferred behaviour. You get a label of the user supplied input, but a URI that conforms to the specifications in the AutoID options.

Observation: I think the prefix, suffix and length options should be separate from the pseudo random option - there will be people who want to specify such options, but I am most interested in some 'unique' URI, I dont want to have to specify the length. The default prefix is also a problem. Also, the way in which the pseudo random numer is generated seems to mean that only the first 13 digits are non-zero, extra ones are redundant.

4) See NewEntity4 (or '00000001218659708610') in attached ontology
Setting: In the 'New Entities' tab, in the 'Entity Name' section, with the radio button for 'AutoID' selected *and* the 'create label' checkbox selected (happens automatically) *and* 'create label' selected for 'Auto ID'.

Observation: This is the strangest behaviour of all. I get *two* labels now. One for the user input, and one for the Auto ID, along with a URI for the Auto ID. The renderer seems to default to the label that is the Auto ID label - meaning that the rendering is meaningless and you have to look at the other label.


Finally, closing the preferences pane with the Red X throws a null pointer exception. :-)

Cheers
Andrew

Dr Andrew Gibson
Universiteit van Amsterdam


_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback

NewEntities.owl (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: URIs and Labels - Issues with new entity options

Nick Drummond
Hi Andy,

As a general theme, you seem to be arguing for no defaulting mechanism on the renderer so you can tell when a label is missing.

Please note that the renderer settings are completely separate from these settings - you can still get the renderer to always show the URI fragment, or particular annotations.

1) Several people requested splitting what gets rendered from what gets generated. I will add an option to hook these back together that will be on by default.

2) Creating a URI and label with the same content was also requested - I suppose spelling mistakes could be corrected in the label without changing the URI, but the URIs remain useful for debugging.
Having a separate URI and label already causes this issue - people need to be aware of the potential difference between the identifier for something (the URI) and the labels that determine how it is rendered.
Surely people just have to be careful what they change - its only because so many tools have historically made ID changing so easy that this is an issue (arguably, the URI should never change - most other applications never give users control over the IDs).

3) The default options (including the prefix) and all the controls allow the existing P4 behaviour before all of this stuff. Prefixes/suffixes can be turned off. Many people want a regularised ID format so they can recognise it in other contexts.

4) I would typically imagine the other combination more useful - user generates the URI and the autoID might become a label, but I could see no reason to disallow having the autoID in both - bound to annoy someone somewhere if this combination was not available. However, I suppose in this case the annotations would probably need to be on two separate URIs - I originally started this but it all got a bit clogged.

x exception - Fixed this already.

Nick

On Wed, Aug 13, 2008 at 9:43 PM, Gibson, A.P. <[hidden email]> wrote:

I am really pleased to see some work towards managing the consistent labelling of new entities in an ontology with the "New Entities" tab in the Preferences - especially support for Auto IDs.

BUT

theres a few bugs and odd behaviours :-), and a veritable 'exploding bicycle' of possible rendering outcomes depending on different user settings.

I'm not sure what the default setting for labelling new entities is - so I'll cycle through as many as I can find:

1) See 'NewEntity1' in attached ontology
Setting: In the 'New Entities' tab, in the 'Entity Name' section, with *only* the radio button for 'User Supplied Name' selected

Outcome: New entities get the URI of the name that the user entered. This is the same behaviour as you would get in older versions where 'Render entities using URI fragment' was selected.

Observation: There is no annotation created (as expected), but the renderer defaults to rendering with the URI fragment, even with the 'render entities using annotation values' option selected in the renderer. There is no visual clue (apart from the absence of a label) that this has happened - so in an ontology with a mixture of labelled and unlabelled classes, theres no clue that they are encoded differently 'under the hood'.

2) See 'NewEntity2(a,b,c) in attached ontology
Setting: In the 'New Entities' tab, in the 'Entity Name' section, with the radio button for 'User Supplied Name' selected *and* the 'create label' checkbox selected.

Outcome: This is a new possible combination where both the URI fragment and the Label get created with the user supplied label.

Observation: This is dangerous. Initially there will be no difference to the user whether they are rendering with URI fragments or labels (as with NewEntity2a). BUT then you are open to the possibility that a user changes EITHER the label (see class with URI NewEntity2b) OR the URI fragment (see class with Label NewEntity2c). As a developer, unless you are sure that different people have their Protege rendering set up the same way, ontologies will most likely end up with a mixture of these and some very confused people and URI resolvers, especially with multiple users.

3) See NewEntity3 in attached ontology
Setting: In the 'New Entities' tab, in the 'Entity Name' section, with the radio button for 'AutoID' selected *and* the 'create label' checkbox selected (happens automatically).

Outcome: This is *almost* my preferred behaviour. You get a label of the user supplied input, but a URI that conforms to the specifications in the AutoID options.

Observation: I think the prefix, suffix and length options should be separate from the pseudo random option - there will be people who want to specify such options, but I am most interested in some 'unique' URI, I dont want to have to specify the length. The default prefix is also a problem. Also, the way in which the pseudo random numer is generated seems to mean that only the first 13 digits are non-zero, extra ones are redundant.

4) See NewEntity4 (or '00000001218659708610') in attached ontology
Setting: In the 'New Entities' tab, in the 'Entity Name' section, with the radio button for 'AutoID' selected *and* the 'create label' checkbox selected (happens automatically) *and* 'create label' selected for 'Auto ID'.

Observation: This is the strangest behaviour of all. I get *two* labels now. One for the user input, and one for the Auto ID, along with a URI for the Auto ID. The renderer seems to default to the label that is the Auto ID label - meaning that the rendering is meaningless and you have to look at the other label.


Finally, closing the preferences pane with the Red X throws a null pointer exception. :-)

Cheers
Andrew

Dr Andrew Gibson
Universiteit van Amsterdam


_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback



_______________________________________________
p4-feedback mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/p4-feedback