Help talk:Properties and types

From semantic-mediawiki.org

[edit] #set: is space-sensitive

Having grown accustomed to MediaWiki parser functions being tolerant of white space between such things as

• arguments and operators or
• arguments and parameter delimiters

it was a tricky surprise to discover that SMW's #ask parser function is not so tolerant of white space. I'd file this as a bug if I knew what the designer intended but am not sure so am mentioning it here as a first step. The nearest similar bug I could find is 5900. The fix described there might be relevant here if there is consensus that indeed this is a bug.

• If the behavior is by design then a notice at section Silent annotations using #set about whitespace sensitivity seems appropriate.

Detail

The following two silent annotations do not have the same effect:

{{#set:property-name1=value1}}
{{#set:property-name1= value1}}

The list of values for property-name1 will show 2 distinct values. The second having a space prefix. Not something that is easy to notice or to debug. I believe the intention is unambiguous and that if a user wanted to explicitly prefix (or append) a space then either &nbsp; or <nowiki> </nowiki> ought to be required. e.g.

{{#set: property-name1 =  value1 }}
{{#set: property-name1 = <nowiki> </nowiki>value1 }}
{{#set: property-name2 = value2&nbsp; }}
{{#set: property-name2 = value2<nowiki> </nowiki> }}

I don't think I am mistaken when I say that a normal MediaWiki parser function (see the #ifeq or #switch examples below) or template call (see MyTemplate or CsvApend or CsvRemove examples below) would happily accept whitespace (although not necessarily a newline character) at any of the places illustrated:

{{ #set: property-name1 = value1 }}
{{ #ifeq: target-string
        | match-string
        | matches-output-string
        | mismatches-output-string
}}
{{ MyTemplate 
   | param1 = value1
   | param2 = value2
}}

Some of the spaces illustrated above are not reasonably necessary while others are essential to making complex mixtures of template calls, parser functions and semantic annotations easy for the human eye to parse. A more complex example from a real application:

{{#switch: {{lc: {{{Operation|}}} 
           }}
  | add      = {{#arraymap: {{CsvAppend
                              |{{{Favoredby|}}}
                              |{{{Thisuser|}}}
                              |,
                            }}
                 |,
                 |!
                 |{{#set: Is a favorite of=!}} 
                 |<nowiki> </nowiki>
               }}
  | remove   = {{#arraymap: {{CsvRemove
                              |{{{Favoredby|}}}
                              |{{{Thisuser|}}}
                              |,
                            }}
                 |,
                 |!
                 |{{#set: Is a favorite of=!}} 
                 |<nowiki> </nowiki>
               }}
  | #default = {{#arraymap: {{{Favoredby|}}}
                 |,
                 |!
                 |{{#set: Is a favorite of=!}}
                 |<nowiki> </nowiki>
               }}
}}

• The above block of markup code is bug-free because I removed the space between (=) and (!)

The trouble is the user is accustomed to the MediaWiki parser ignoring such spaces in other parser functions and yet the user needs to be vigilant for this SMW parser function. I am now wary that maybe #ask:, #show: and perhaps [[property-name::value|label]] might be similarly sensitive. -Najevi 06:09, 2 August 2009 (UTC)

[edit] Weight and Mass property and type

I've tried to set up properties for [weight] (unit weight, package weight) and define them in terms of [mass ] according to the examples i've found on semanticweb.org.

however, my tagged properties still have warnings Unsupported type 'weight' defined for property

Along the way of trying to define everything ultimately in terms of Type:Mass, I've ended up with Property:Weight, Type:Weight, Property:Mass and Type:Mass

I'm using Referata, where these are not already defined. Has anyone managed to accomplish this?

Update:

[[1]]

shows Type:Mass has Type:Number, yet balloon shows Type:Number does not exist...