Range of has_text_value is too narrow

[swartik]

The range of data property has_text_value is xsd:string. Therefore, the object of an triple whose predicate is has_text_value cannot be a language-tagged string, because a reasoner will declare the triple inconsistent. That is,

 :individual cco:has_text_value "quick brown fox"@en .

yields an inconsistent ontology.

I know CCO offers other ways to specify the language of a text string, but I find them cumbersome in comparison to the very simple and direct approach provided by language tags. That a language-tagged string is not also an xsd:string is an aspect of RDF we OWL users must live with, unfortunately. I suggest changing CCO by making the range of has_text_value rdfs:literal, and adding an annotation describing how to use the property.

[mark-jensen]

Thanks for catching this @swartik. I rarely use these datatype-based properties, defaulting to a more generic "has_value" on most data modeling efforts. Do you use them, e.g., "has_decimal_value"?

In addition to the change in range, I am tempted to to make a label change and remove 'text'. Perhaps a better approach is to introduce a top-level property "has_value" with range of literal and keep "has_text_value", but remove its range and add comment on usage.

Thoughts?

[swartik]

@mark-jensen In fact I generally use your approach. I define a property named "has_literal_value" with a range of rdfs:literal. rdfs:literal being the most general data type for literals, I can then give the value whatever datatype it needs.

But – here comes the qualifier – there are times when I appreciate all the different datatype properties in CCO. I may want to write:

 :individual cco:has_datetime_value "2023-06-21T10:37:00"^^xsd:datetime ;
             cco:has_text_value "June 21, 2023 at 10:37"^^xsd:string .

to provide semantics while preserving the original text. I could use a has_literal_value property to express that:

 :individual :has_literal_value "2023-06-21T10:37:00"^^xsd:datetime ,
                                "June 21, 2023 at 10:37"^^xsd:string .

but I find using the separate properties makes my queries simpler.

All that said, on balance I agree with you: a "has_value" property is better than the current set of properties.

[cameronmore]

I think a new top object property makes sense with a range of literal and keep has_text_value, and agree that the range should be removed to accommodate language tags.

If users need to specify whether a literal has a particular tag--data type or language tag--there may be more desirable ways to validate those literals like SPARQL queries and SHACL constraints.

[cameronmore]

I linked a PR to this issue implementing the above and adding definitions to the data properties.

[neilotte]

This issue has been addressed on develop.