Suggestion: Default [legal] values in form fields

[Jack Hodges]

Often times I find myself in a situation where I am putting a value into a form field and TBC doesn't like it. I end up spending a fair amount of time looking for legal values. It would be [very] nice if, at least for standard types, a default legal value could be put into the field so that we could then edit it. That would give us both proper syntax and values. Maybe I am the only one that would like this.

[Jack Hodges]

And for non-standard properties (such as those created by us), maybe an option to provide such a legal default value definition for others.

[Holger Knublauch]

Which datatypes do you have in mind? I assume xsd:string and any numeric datatypes are not a problem. I can imagine that xsd:date and xsd:dateTime are. What else?

Also, could you give me some example of user-defined datatypes that you have created? With OWL 2 syntax?

(On the more general issue, note that SHACL has sh:defaultValue, which may be exploited for useful suggestions for certain properties - sh:defaultValue lives on a property definition though, not the datatype itself).

Holger

--
You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary Network (EVN), Reference Data Manager (RDM), TopBraid Composer, TopBraid Live, TopBraid Insight, SPARQLMotion, SPARQL Web Pages and SPIN.
To post to this group, send email to topbrai...@googlegroups.com
---
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jack Hodges]

Hello Holger,

Yes, mostly for the use of datatypes in properties. Well, last night and this morning the problem is with an owl:DatatypeProperty in QUDT, qudt:numericValue, whose rdfs:range is xsd:double. So it is a good example of a custom property but uses a standard datatype.

I created a class instance and tried to set the qudt:numericValue to one of the below:

255

255.0

255e01

255.0e01

"255"^^xsd:double

but TBC didn't like any of them. That is when I thought of a template value in the field.

I've been thinking about this since reading your mention of SHACL. At first I thought that the solution should be in the TBC IDE, but the notion of it being part of [some] language model makes more sense. Unfortunately, it seems like this kind of thing would make sense at a very high level, and I do not think the benefit would justify the effort.

[Holger Knublauch]

On 7/31/2015 2:23, Jack Hodges wrote:

Hello Holger,

Yes, mostly for the use of datatypes in properties. Well, last night and this morning the problem is with an owl:DatatypeProperty in QUDT, qudt:numericValue, whose rdfs:range is xsd:double. So it is a good example of a custom property but uses a standard datatype.

I created a class instance and tried to set the qudt:numericValue to one of the below:

255

255.0

255e01

255.0e01

"255"^^xsd:double

but TBC didn't like any of them. That is when I thought of a template value in the field.

I am not sure what you are talking about - these values appear to be working fine, except the last one which isn't expected to work. Screenshot using 5.0:



In another email (offlist) you state that the issue may be related to dtype:numericUnion custom datatype. But when you enter a value for that datatype, TBC has no idea what to instantiate and just uses dtype:numericUnion as the literals' datatype. Instead, it should pick one of the XSD datatypes in the union, but it cannot guess which one.

By coincidence a related topic came up in the SHACL WG today, where we decided to add an "official" datatype sh:text for the union of xsd:string and rdf:langString. Yet even if that is used as a sh:datatype, nobody would instantiate sh:text directly and tools would just need to offer both choices.

Holger

[Jack Hodges]

Thanks for the reply. I do not recall saying anything about dtype:numericUnion in my mails and as far as I can see qudt:numericValue is defined with an xsd:double range. That said, I can see that there are instances of qudt:numericValue that follow the conventions you and I both used, but yours is successful and mine was not. Maybe it is some kind of glitch in my TBC (which happens on occasion, though I close and reopen daily to be safe).

But the suggestion is still valid I think, at least in terms of standard types (but maybe not if no errors occur).

Jack

On Wednesday, July 29, 2015 at 4:57:22 PM UTC-7, Jack Hodges wrote: