Convert to integer: EDG property values and constraints are automatically of type 'string'

[Stefan Verweij]

Hi all,

I have an ontology with class time containing the attributes (year, month, week, day, hour, minute, second). Now I have set some typical constraints for each attribute and I am stuck with these. For example, the attribute 'hour' can occur max 1x in time with a value between 0 and 23 (an hour cannot be negative and after 23 hours it should be referred to as 'day' (see first picture below for property shape).

These constraints are standard of type 'string', hence resulting in ValueErrors (see second picture), since the EDG software implements these values automatically as a string. 

While I have found a way to convert the elements by manually removing the quotation marks within the source code (see third picture), this consumes quite a lot of time. Therefore I would like to know if there is an general build-in option to change the datatype from string to integer?

property characterisics

ValueError

source code

[Irene Polikoff]

Have you tried adding sh:datatype XSD:integer constraint? Or do you want values to be strings?

On Jul 25, 2019, at 8:35 AM, Stefan Verweij <stefan....@wur.nl> wrote:

Hi all,

I have an ontology with class time containing the attributes (year, month, week, day, hour, minute, second). Now I have set some typical constraints for each attribute and I am stuck with these. For example, the attribute 'hour' can occur max 1x in time with a value between 0 and 23 (an hour cannot be negative and after 23 hours it should be referred to as 'day' (see first picture below for property shape).

These constraints are standard of type 'string', hence resulting in ValueErrors (see second picture), since the EDG software implements these values automatically as a string. 

While I have found a way to convert the elements by manually removing the quotation marks within the source code (see third picture), this consumes quite a lot of time. Therefore I would like to know if there is an general build-in option to change the datatype from string to integer?

<hour_properties.PNG>property characterisics

<time_error.PNG>ValueError

<adjust_sourcecode.PNG>source code

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/369b6925-4dcb-4563-9915-31d663a84025%40googlegroups.com.

<hour_properties.PNG>

<time_error.PNG>

<adjust_sourcecode.PNG>

[Stefan Verweij]

I have tried that indeed, by selecting integer from the dropdown list at datatype at Type of Values in the UI. But then I get another error that says the datatype doesn't match the values at max inclusive (see picture again)

Op donderdag 25 juli 2019 15:10:54 UTC+2 schreef Irene Polikoff:

[Irene Polikoff]

Let’s say you have something like

g:C1-test

  rdf:type sh:PropertyShape ;

  sh:path g:test ;

  sh:maxInclusive "23" ;

  sh:minInclusive "0" ;

.

Add the datatype constraint. Then change (using source code panel) “23” and “0” to 23 and 0.

To get to:

g:C1-test

  rdf:type sh:PropertyShape ;

  sh:path g:test ;

  sh:datatype xsd:integer ;

  sh:maxInclusive 23 ;

  sh:minInclusive 0 ;

.

Basically, if you set sh:datatype xsd:integer  constraint before you enter min/max values and save it, then min/max values constraints will be saved as integers.

But if you add the integer constraint after entering min/max, then it would be saved as a string. The same happens if you enter both of them in a single edit transaction since the system does not know yet that it must be a digit.

So, in the future, enter the integer constraint first, save it. Then you can enter values constraints and they will be integers.

On Jul 25, 2019, at 9:23 AM, Stefan Verweij <stefan....@wur.nl> wrote:

I have tried that indeed, by selecting integer from the dropdown list at datatype at Type of Values in the UI. But then I get another error that says the datatype doesn't match the values at max inclusive (see picture again)

<datatype_error.PNG>

Op donderdag 25 juli 2019 15:10:54 UTC+2 schreef Irene Polikoff:

Have you tried adding sh:datatype XSD:integer constraint? Or do you want values to be strings?

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

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/9f23dec7-eb5e-409a-b794-dac26436820e%40googlegroups.com.
<datatype_error.PNG>

[Stefan Verweij]

Okay good to know, thanks for the help. It's still quite inconvenient (especially when using such an UI), but at least less time consuming!

Stefan

Op donderdag 25 juli 2019 16:07:15 UTC+2 schreef Irene Polikoff:

...

[Fan Li]

Thanks for the explanation! If we have both sh:datatype defined as xs:integer and sh:max in string within a shape, doesn't it represent an inconsistency? Maybe we need another shape to validate this shape:)

On Thursday, July 25, 2019 at 10:07:15 AM UTC-4, Irene Polikoff wrote:

Let’s say you have something like

g:C1-test

  rdf:type sh:PropertyShape ;

  sh:path g:test ;

  sh:maxInclusive "23" ;

  sh:minInclusive "0" ;

.

Add the datatype constraint. Then change (using source code panel) “23” and “0” to 23 and 0.

To get to:

g:C1-test

  rdf:type sh:PropertyShape ;

  sh:path g:test ;

  sh:datatype xsd:integer ;

  sh:maxInclusive 23 ;

  sh:minInclusive 0 ;

.

Basically, if you set sh:datatype xsd:integer  constraint before you enter min/max values and save it, then min/max values constraints will be saved as integers.

But if you add the integer constraint after entering min/max, then it would be saved as a string. The same happens if you enter both of them in a single edit transaction since the system does not know yet that it must be a digit.

So, in the future, enter the integer constraint first, save it. Then you can enter values constraints and they will be integers.

On Jul 25, 2019, at 9:23 AM, Stefan Verweij <stefan...@wur.nl> wrote:

I have tried that indeed, by selecting integer from the dropdown list at datatype at Type of Values in the UI. But then I get another error that says the datatype doesn't match the values at max inclusive (see picture again)

<datatype_error.PNG>

Op donderdag 25 juli 2019 15:10:54 UTC+2 schreef Irene Polikoff:

Have you tried adding sh:datatype XSD:integer constraint? Or do you want values to be strings?

--
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 topbrai...@googlegroups.com.

[Irene Polikoff]

It does represent an inconsistency and there is a shape that validates a shape. When this happens, there will be a validation issue displayed for the shape itself. This is what Stefan’s screenshot showed.

To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/6c17415d-c2cb-4719-a415-fb6d8e7076c9%40googlegroups.com.

[Fan Li]

Hi Irene, you are right. When I reproduced, the screenshot in Stefan's 2nd post is what I got and would have expected. It is a slight inconvenience to do it right in two steps but not a big deal. 

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/6c17415d-c2cb-4719-a415-fb6d8e7076c9%40googlegroups.com.

[Irene Polikoff]

In 6.3, when a user creates a property they will be able to enter the most commonly used constraints (including datatype) as part of create:

After naming the property and entering the common constraints, users will then be able to add other constraints:

This will remove the slight inconvenience that is present now.

To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/034acc64-0c2b-4259-8c98-b647ed999d9b%40googlegroups.com.

[Fan Li]

Thanks. Looking forward to trying the new version!

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/034acc64-0c2b-4259-8c98-b647ed999d9b%40googlegroups.com.

[Stefan Verweij]

I have a new question regarding the class 'time' in this ontology. I found a simpler datatype xsd:duration resulting in a single attribute 'has duration' (sh:datatype xsd:duration ;) with the format PnYnMnDTnHnMnS. 

In some cases there is no duration and things happen instantly at t=0 (e.g. in the case of experiments). The datatype xsd:duration forbids t=0 however. Now I can choose to make the attribute 'has duration' optional by only setting a max count of 1. However, I would like time to be mandatory to avoid any ambiguity between a thing, let's say an experiment happening at t=0 (possible) or an experiment where the scientist simply forgot to mention its duration (not possible!!!). Therefore I created a boolean attribute 'is instant'. Now I would like to link this boolean attribute to my attribute 'has duration' in a way that if 'is instant'=False it leads to the co-existence of 'has duration', but if 'is instant=True there is no 'has duration'. I thought of using 'co-existence with', but I can only link this to a property and not to the value of that property.

is instant=True --> nothing

is instant=False --> 'has duration'=P5Y

Or if there is a better way of describing this relationship, please let me know!

Stefan

Op donderdag 25 juli 2019 15:10:54 UTC+2 schreef Irene Polikoff:

Have you tried adding sh:datatype XSD:integer constraint? Or do you want values to be strings?

[dprice]

Seems to me you’re trying to manage two concepts you cannot record as one: “happened at time” and “time taken to occur”. 

I’ve seen both xsd:duration and xsd:dateTime used in real, operational ontologies in customer projects. However, the main use I’ve seen for xsd:duration is properties about things that live for years like "equipment life”. For data about experiments or similar, I’ve seen xsd:dateTime used far more often.

A few alternatives:

1 - Perhaps two dateTime properties of the action/activity are all you need: startedOrHappenedAt and endedAt. If endedAt is missing then you know it happened instantly, if not then duration = endedAt - startedOrHappenedAt. 

2 - Alternatively, you could use startedAt and endedAt and set endedAt to have the same value as startedAt for the “instantly” case.

3 - Alternatively, choose the smallest value allowed for xsd:duration and use that to mean “instantly”. People sometimes choose a seldom-used value of a datatype and give it a specific meaning.

The advantage of 2 is that you also record when something happened, not just how long it took to happen, and so you can order activities and also always calculate if activities overlapped in time.  1 is one less triple in the “instantly” case. 3 is perhaps best if you are only ever comparing how long things took, not when they happened.

A fourth option you might consider is two subclasses of Activity: InstantaneousActivity and ContinuousActivity rather than trying to use a Boolean (which very often means a subclass is missing).

Cheers,

David

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

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/d8992643-d56c-4579-b1e3-ab406af547be%40googlegroups.com.

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[Stefan Verweij]

Great alternatives, thanks! All seem to be very useful, though I am indeed not really interested in the 'when', but more in the 'how long' indeed, so the third option will do just fine I think.

Stefan

Op woensdag 31 juli 2019 11:59:08 UTC+2 schreef David Price:

Seems to me you’re trying to manage two concepts you cannot record as one: “happened at time” and “time taken to occur”. 

I’ve seen both xsd:duration and xsd:dateTime used in real, operational ontologies in customer projects. However, the main use I’ve seen for xsd:duration is properties about things that live for years like "equipment life”. For data about experiments or similar, I’ve seen xsd:dateTime used far more often.

A few alternatives:

1 - Perhaps two dateTime properties of the action/activity are all you need: startedOrHappenedAt and endedAt. If endedAt is missing then you know it happened instantly, if not then duration = endedAt - startedOrHappenedAt. 

2 - Alternatively, you could use startedAt and endedAt and set endedAt to have the same value as startedAt for the “instantly” case.

3 - Alternatively, choose the smallest value allowed for xsd:duration and use that to mean “instantly”. People sometimes choose a seldom-used value of a datatype and give it a specific meaning.

The advantage of 2 is that you also record when something happened, not just how long it took to happen, and so you can order activities and also always calculate if activities overlapped in time.  1 is one less triple in the “instantly” case. 3 is perhaps best if you are only ever comparing how long things took, not when they happened.

A fourth option you might consider is two subclasses of Activity: InstantaneousActivity and ContinuousActivity rather than trying to use a Boolean (which very often means a subclass is missing).

Cheers,

David

[Irene Polikoff]

You will need to use SHACL SPARQL for this constraint. 

The pattern of “value of property p1 must exist if property p2 has value X” seems to be generally useful, so defining it declaratively as a new type of constraint component would make sense.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/d8992643-d56c-4579-b1e3-ab406af547be%40googlegroups.com.