What to do about langStrings

20 views
Skip to first unread message

cbur...@healthwise.org

unread,
Oct 4, 2019, 4:13:28 PM10/4/19
to TopBraid Suite Users
When building property shapes for properties with literals as objects, such as rdfs:label, mandating a datatype of "string" seems like a good idea -- in fact, it seems to be necessary if we want search to work properly (i.e., if we want the filtering logic in search forms to default to "contains").

But the thing is: all or existing values of rdfs:label have a datatype of what W3C calls rdf:langString (string + lang tag), not just simple strings. That means they all trigger a constraint violation!

What should I do about this? I don't see a way to set the datatype to rdf:langString.

Irene Polikoff

unread,
Oct 4, 2019, 4:49:34 PM10/4/19
to topbrai...@googlegroups.com
rdf:langString is available as a datatype.

Typically, we do ‘or’. Look at SKOS shapes e.g.,


There is also dash:HTMLOrStringOrLangString - to simplify if you need these 3 datatypes. You could also do them with sh:or



--
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/30bb5e41-a151-4711-b071-86b89d7d082f%40googlegroups.com.

Holger Knublauch

unread,
Oct 4, 2019, 8:08:26 PM10/4/19
to topbrai...@googlegroups.com

Right, plus there is dash:StringOrLangString as a possible value for sh:or built-in.

Holger

cbur...@healthwise.org

unread,
Oct 8, 2019, 3:03:56 PM10/8/19
to TopBraid Suite Users
Thanks, Irene and Holger, for your prompt replies.

Doing what you've done with skos:altLabel totally worked for my purposes, so that's good -- thanks! But I have two observations:

1. rdf:langString is not available as an option in the datatype dropdown in EDG. Perhaps it should be?
2. I cannot get EDG to accept either the manually entered text of either "dash:StringOrLangString" or "dash:HTMLOrStringOrLangString" as values for sh:or. I get the warning, "Requires at least two choices." I suppose it would work if I imported this constraint expression into the project, but it seems like it should be permitted to add these values manually in EDG.

thanks,
C

Irene Polikoff

unread,
Oct 8, 2019, 3:23:55 PM10/8/19
to topbrai...@googlegroups.com
Please see below

On Oct 8, 2019, at 3:03 PM, cbur...@healthwise.org wrote:

Thanks, Irene and Holger, for your prompt replies.

Doing what you've done with skos:altLabel totally worked for my purposes, so that's good -- thanks! But I have two observations:

1. rdf:langString is not available as an option in the datatype dropdown in EDG. Perhaps it should be?

It is available in 6.3

2. I cannot get EDG to accept either the manually entered text of either "dash:StringOrLangString" or "dash:HTMLOrStringOrLangString" as values for sh:or. I get the warning, "Requires at least two choices." I suppose it would work if I imported this constraint expression into the project, but it seems like it should be permitted to add these values manually in EDG.

Value of sh:or is RDF List.

If you look at skos:altLabel, for example, you will see:

skos:Concept-altLabel
  rdf:type sh:PropertyShape ;
  sh:path skos:altLabel ;
  dash:singleLine true ;
  sh:description "An alternative lexical label for a resource."@en ;
  sh:disjoint skos:hiddenLabel ;
  sh:group skos:LabelsAndDescriptionPropertyGroup ;
  sh:or (
      [
        sh:datatype xsd:string ;
      ]
      [
        sh:datatype rdf:langString ;
      ]
    ) ;

You need to use ( ) and [] brackets to combine individual constraints using sh:or. 

So, you need to go to sh:or field and enter

 (
      [
        sh:datatype xsd:string ;
      ]
      [
        sh:datatype rdf:langString ;
      ]
    )


dash:HTMLOrStringOrLangString is not used with sh:or. It is used instead of sh:or because it already has OR built in.

You would use it directly with sh:datatype constraint. For example, you may see:

skos:Concept-definition
  rdf:type sh:PropertyShape ;
  sh:path skos:definition ;
 sh:datatype dash:HTMLOrStringOrLangString;

The datatype dropdown does not support this in 6.2. You can enter dash:HTMLOrStringOrLangString as a value of sh:datatype constraint in the source code panel.

In 6.3, instead of a dropdown, you will get a pop up like this


You will be able to make multiple choices and EDG will construct the right expression from your selections.


thanks,
C



On Friday, October 4, 2019 at 1:13:28 PM UTC-7, cbur...@healthwise.org wrote:
When building property shapes for properties with literals as objects, such as rdfs:label, mandating a datatype of "string" seems like a good idea -- in fact, it seems to be necessary if we want search to work properly (i.e., if we want the filtering logic in search forms to default to "contains").

But the thing is: all or existing values of rdfs:label have a datatype of what W3C calls rdf:langString (string + lang tag), not just simple strings. That means they all trigger a constraint violation!

What should I do about this? I don't see a way to set the datatype to rdf:langString.

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

Irene Polikoff

unread,
Oct 8, 2019, 3:33:30 PM10/8/19
to topbrai...@googlegroups.com
Correcting a mistake.

It would indeed be sh:or not sh; datatype with dash:HTMLOrStringOrLangString

skos:Concept-definition
  rdf:type sh:PropertyShape ;
  sh:path skos:definition ;
  sh:or dash:HTMLOrStringOrLangString;

However, you need to do this in the source code until 6.3.

<PastedGraphic-1.png>

cbur...@healthwise.org

unread,
Oct 8, 2019, 3:36:15 PM10/8/19
to TopBraid Suite Users
Fantastic! It sounds like getting these added to the UI has already been thought of. Glad to know I'm not the only one who would find it useful.

C


On Friday, October 4, 2019 at 1:13:28 PM UTC-7, cbur...@healthwise.org wrote:
Reply all
Reply to author
Forward
0 new messages