search

chenejac / VIVOTestMigrationJIRA

0 stars 0 forks source link

VIVO-1528: Selectable editors for input fields #1421

Closed chenejac closed 5 years ago

chenejac commented 6 years ago

Stefan Wolff (Migrated from VIVO-1528) said:

The WYSIWYG editor will provided to input of all data properties of string values.

The problem: For the most of this properties it is not correct to input formatted text (HTML), i.e. identifier.

I suggest providing a simple input field to allow plain text only. But if there is a range of [http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral], a WYSIWYG editor should be provided.

 

See also:  [https://www.w3.org/TR/rdf11-concepts/#section-html]

 

chenejac commented 6 years ago

Mike Conlon said:

We may need an application configuration property for the field to indicate HTML is supported.

We have Datatype properties that are declared string and datatype properties declared langString.  Agree that most do not need HTML support.

Perhaps a property in vitroAnnotations.n3 could be used to indicate that a data property should be edited as HTML.  The default would be plain text editing.

chenejac commented 6 years ago

Stefan Wolff said:

Don't you think, we can do it based on the data model (type or range of the property)?

chenejac commented 6 years ago

Mike Conlon said:

It can be done that way, but it overloads the range.  The range then would indicate two different things 1) what datatype is stored, and 2) how is it to be handled by an application.  The first is an ontology concern.  The second is an application concern.  Having a separate property for the second allows us to have unlimited possibilities for handling and display (should be displayed as WYSWIG editor, as a slider, using a DOM parser, a SPARQL editor, etc).

The problem with using one field value (the range) for two different purposes is that the knowledge of each is no longer in the data, and rests in the software. 

In this particular case, if we use one kind of string (say xsd:string) to indicate one kind of handling, what do we do with rdf:langString, and rdf:Literal, and rdf:XMLLiteral.

chenejac commented 6 years ago

Stefan Wolff said:

These two things, 1) what datatype should be stored and 2) which input elements will be provided, depending on each other directly. I.e. if there is a file type, then we should give a file upload element. If there is a date type, we should give a date picker, ... . Of course, we can specialize it in individual cases, but we should have a general solution. If we don't have, then we would have to configure the related input elements for all data types of all used ontologies. This is real redundancy and a lot of work.

Please notice: The suggested solution (use range to select the elements for editing) is the way it is now implemented.

already implemented:

 

my suggestion: separate the last group in ..

 

see [https://github.com/vivo-project/Vitro/pull/76]

chenejac commented 6 years ago

Mike Conlon said:

Most of the these cases should not present problems.  URI/URL is one where we should have special editor to handle these consistently (as in the case of DOI)

DateTime is currently handled inconsistently – in some cases, additional date/time parts are requested, in other cases they are not.  This seems to be determined by the software, not by the data.  This could be determined by the datePrecision.

You are proposing we change the range for overview fields in the ontology to XMLLiteral so that a WYSIWIG editor is presented by the interface?

We also have ranges of rdf:Literal (these should eventually be changed to xd:string or other for consistency) and rdf:langString for strings having language tags (which should become the most common string type)

I am very much in favor of reducing the use of the WYSIWIG editor for string fields, using it only where it is valuable.  

chenejac commented 6 years ago

Stefan Wolff said:

Yes, the most of these cases are not present problems. I listed it to show the current implementation.

The point is not to change a range of an overview field for providing WYSIWYG editor, it is to provide an input field for editing text properties in general. HTML content in data properties is a big exception and should be handled like these. For those few cases the range XMLLiteral could be used.

chenejac commented 6 years ago

Mike Conlon said:

Agree, HTML editing is the exception.  Overviews are likely the key properties for HTML editing.

chenejac commented 6 years ago

Stefan Wolff said:

-> https://github.com/vivo-project/Vitro/pull/76

chenejac commented 6 years ago

Brian Lowe said:

I like Stefan's proposal of activating the WYSIWYG editor only where the datatype is XMLLiteral.-- though I would suggest that such a change to the application's behavior not be made until/unless the ontology is updated so that expected properties have this range datatype.

Additionally, we might consider the new rdf:HTML datatype: [https://www.w3.org/TR/rdf11-concepts/#section-html] 

(Edit before submission:) The only real disadvantage I see is that if we use either of these datatypes we can't also use a language tag, which significantly complicates language filtering.

If the language filtering issue can be overcome, then the rest of what I initially wrote below might be of interest:

I'm not sure that this issue is purely one of application configuration.  When consuming the resulting data, it seems that it would be nice to know from the ontology when to expect plain strings and when to expect values that might contain markup which needs to be either further processed or rendered without escaping in order to be intelligible to a user.

As I recall, XMLLiteral is designed to allow un-escaped markup to be directly embedded in RDF/XML documents – part of an early attempt to make the RDF and XML worlds play nicely together.  While this particular use case – in our modern N3 and JSON world – doesn't really interest us, it seems that the semantics are still pretty close to what we want to convey.  For certain fields, we expect markup that should be rendered unescaped on display pages, and we also want to allow that markup to be created and edited.  It seems that both the public display escaping or lack thereof and the choice of WYSIWYG/non-WYSIWYG editors could be toggled via this method.

chenejac commented 6 years ago

Ralph O'Flinn said:

Brian went the way I was going - [https://www.w3.org/TR/rdf11-concepts/#section-html]

http://www.w3.org/1999/02/22-rdf-syntax-ns#HTML.

Also I believe that the XMLLiteral is only to be used for well-formed XML so it would need to be XHTML and not just HTML.

 

 

chenejac commented 6 years ago

Andrew Woods said:

The ontologists met and discussed https://jira.duraspace.org/browse/VIVO-1528 regarding rdf:XMLLiteral, the use of ranges on datatype properties to indicate application action and the the preferred range. From the meeting notes:

Following discussion the group recommends the use of rdf:HTML as range on datatype properties that require HTML editing. All other datatype property ranges (including no ranges) are edited using a plain text edit editor unless already handled by range. It appears that 4 datatype properties (bibo:abstract, vivo:overview, vivo:teachingOverview, vivo:researchOverview) should have range specified as rdf:HTML. Note: other fields may require rdf:HTML type, and other edge cases may be discovered. The group discussed the impact of language tags, the need to add HTML to some labels, and other potential edge cases. The group recommends testing in a branch to discover unintended consequences and edge cases. Existing field may contain HTML that under this proposal would no longer be able to contain HTML. Such fields may need to be stripped of HTML by site data managers.

chenejac commented 6 years ago

Andrew Woods said:

Pending response to code review comments.

chenejac commented 6 years ago

Andrew Woods said:

[~accountid:557058:e85949dc-6c3c-425e-9fe4-6a5ad1e0d082] / [~accountid:557058:3f53c733-6ac2-4e92-9f12-e34e297283a3]: [~accountid:6113d5ccc51f3a006960df17] has made the requested updates to: https://github.com/vivo-project/Vitro/pull/76 It would be great if we could get this reviewed/merged.

chenejac commented 5 years ago

Mike Conlon said:

After even further discussion, the ontologists and developers discussed the following approach:

 

With this approach, the annotation would not be editable through the interface (that would require additional code ).  The annotation could be changed by editing the vitroAssertions.n3 file and generating a firsttime start-up condition so that it is reloaded by the application.

chenejac commented 5 years ago

Stefan Wolff said:

[~accountid:557058:e85949dc-6c3c-425e-9fe4-6a5ad1e0d082]: Where is field "serviceOverview" from?

chenejac commented 5 years ago

Mike Conlon said:

[~accountid:6113d5ccc51f3a006960df17]: My mistake.  It is called outreachOverview in VIVO.  

chenejac commented 5 years ago

Muhammad Javed said:

[~accountid:557058:e85949dc-6c3c-425e-9fe4-6a5ad1e0d082]: Above given suggestion looks good to me. The mentioned list of data properties has a mismatch. Andrew mentioned bibo:abstract but you :outreachOverview.

chenejac commented 5 years ago

Mike Conlon said:

Yes, bibo:abstract could also be HTML edited.  

BTW, looks like [~accountid:6113d5ccc51f3a006960df17] has a complete pull request implementing the above approach.

chenejac commented 5 years ago

Stefan Wolff said:

Yes, the approach is implemented in [https://github.com/vivo-project/Vitro/pull/76] .

The configuration of HTML fields is contained in this pr: https://github.com/vivo-project/VIVO/pull/100

chenejac commented 5 years ago

Andrew Woods said:

[~accountid:6113d5ccc51f3a006960df17]: Is the ticket "Ready for Review"?

chenejac commented 5 years ago

Stefan Wolff said:

chenejac commented 5 years ago

Laura Wrubel said:

Working on reviewing this. 

chenejac commented 5 years ago

Laura Wrubel said:

Update, no longer reviewing since it got a second review already. 

chenejac commented 5 years ago

Andrew Woods said:

Resolved with: