Help talk:Properties and types/Archive

has type::string is incorrectly listed on main page as limited to 250 bytes

The actual limit for has type::string is 255 bytes.

Hi, this was amended now. Thank you for giving us this hint. Cheers --kgh 20:16, 13 December 2010 (CET)

#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)

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

• There are no user-defined types any more. I, too, miss them. Use Type:Quantity.
  Alexander Mashin^talk 10:19, 24 November 2012 (CET)

Has type is case sensitive

In this help talk it should be always written "Has type" with the capital letter H on the beginning because it is the correct name. "has type" is confusing for beginners as I am. When the site setting allows lowercase page names then all names become case sensitive and then the lowercase "has type" will not work, I see. This same notice should be applied for all others built-in names for special properties and types, for example not: "has type::number", but: "Has type::Number" etc. --Kychot 22:58, 27 June 2010 (UTC)

Template display depending on property updating poorly

When using an output template that switches depending on current page properties, the output is only updated after the page is edited and saved twice.

{{#switch: {{#show: {{PAGENAME}} | ?PageStatus}}
 | Draft = {{DraftBox}}
 | Review = {{ReviewBox}}
 | #default = 
}}

Behaviour seems to be the same when using #ifeq instead of #switch, so i guess there's something wrong with the updaterate of properties.

Please report bugs on http://bugzilla.mediawiki.org/. For testing bugs, http://sandbox.semantic-mediawiki.org can be used (in the best case, you could create a page there which shows your problem and mention the URL in the bug report). Thanks. (Note regarding your bug: you can use the action "refresh", found below the downarrow button in vector skin, to update a page without saving it again. It should always require one update due to the way in which MediaWiki and SMW are currently implemented, but not two.) --Markus Krötzsch 15:33, 30 November 2010 (CET)

• Querying itself ({{#show: {{PAGENAME}} | ?...}}) is a bad practice and better be avoided. Queried properties are not set until the page is saved, therefore queries will not return correct result until the page is saved again or purged.
  Alexander Mashin^talk 10:23, 24 November 2012 (CET)

Request for additional types

I really miss these fundamental types:

• Time (daily recurring)
• Date and time
• Duration

When temperature is included also these would be natural:

• Length
• Area
• Volume

--Even Thorbergsen 09:59, 22 December 2010 (CET)

I just discovered that Date can be used both as date and date + time, so I retract my second bullet point--Even Thorbergsen 00:03, 3 January 2011 (CET)

• While there were user-defined types, defining types for physical quantities was easy. Now you should use Type:Quantity and set unit os measurement separately for each property (try using templates, though).
  Alexander Mashin^talk 10:26, 24 November 2012 (CET)

File as an additional data type

It'd be nice to have File as a data type. That way, one could get files and images to display in inline semantic queries. For example, something like [[Myimage::[[File:Imagename]] | [[File:Imagename]]]] where Myimage is a property of <type file> would be very useful.

So, if I make an inline query: {{#ask: [[Category: All pages]] | ?Myimage }} one could directly get images showing up in the results.

Is there a way to do this using the current set up?

Thanks, Veryhuman 05:51, 4 March 2011 (CET)

Link group property? Possible?

I wanted to great a string (so I used Has type::string) that had multiple links in it.

To put it simply I'm using a template and there are various terrains in which you can find specific things. One item may be only found in Mountain another only in Cave, but this one is both Mountain and Cave. I've attempted using page, breaks it because it makes the whole thing into one text string. I tried using string with links inside however it will display [[terrain::Mountain, Cave]], so while the links will work the unwelcome ''[[terrain::]]'' is added. My goal is also to restrict the values, how is it possible to use a single property but allow multiple values like this for a single item? Thanks in advance -- Some guy

To assign multiple values to one property you can use #arraymap (which comes with the Semantic Forms extension). More info on #arraymap can be found here.
I think we should update the help page and add a section "Assigning multiple values to a property". I guess there are lots of people looking for that info (including me :)
--Stefan Seidner-Britting (talk) 15:36, 13 September 2012 (CEST)

I guess the reason why this is not documented so far is that the arraymap parser function is provide by Semantic Forms and not Semantic MediaWiki. But yes, a page about #arraymap called "Assigning multiple values" would make sense on this wiki (see here for other examples). Then a link on this page to it fits perfectly well. Cheers --[[kgh]] (talk) 02:19, 21 September 2012 (CEST)

Property as part of link?

I currently have a field set up that allows a user to fill in their own name and mark themselves as the author of an article.

[[author::{{{player|player}}}]]

Ideally, I would like this to automatically link to that member's user page on the wiki.

I tried the following, but that didn't seem to work.

[[user:[[author::{{{player|player}}}]]]]

Is this possible?

• You should include namespace prefix in the property setting code: [[author::User:{{{player|player}}}|{{{player|player}}}]]
  Alexander Mashin^talk 10:32, 24 November 2012 (CET)

Property naming best practices

I'm somewhat new to SMW, and I've long been confused by best practices that aren't explained. That has led myself and others to use best practices in cases where they aren't necessary, or to not use them because we don't undertand them. Here's some discussion from freenode's #semantic-mediawiki to illustrate:

[10:08:52] <Yaron> badon - it helps to eliminate ambiguity, especially for relationships that could go either way, like "Capital" or "Child".
[10:09:04] <badon> either way?
[10:09:08] <badon> what do you mean?
[10:09:28] <Yaron> I mean, a property called "Capital" would be ambigious, in my opinion.
[10:09:41] <badon> Oh, yes, that needs to be more specific.
[10:09:55] <badon> It's not clear whether it IS a capital, or HAS a capital.
[10:10:04] <badon> I didn't think of that.
[10:10:32] <Yaron> Yeah.
[10:10:36] <badon> But, something like color, that's not ambiguous is it?
[10:10:53] <badon> being intrinsic, I don't think there's any ambiguity
[10:11:01] <badon> sort of like Population
[10:11:22] <Yaron> No - but I don't think there's any harm in always having the property name always be a verb phrase.
[10:11:39] <Yaron> It's a personal choice, though.
[10:11:41] <badon> Hmm, does this kind of ambiguity have a technical name? I could update the docs to explain it better. It confused me at first.
[10:11:48] <badon> I should talk to a linguist :)
[10:12:10] <Yaron> How about "ambiguity"? :)
[10:14:22] <badon> Sounds good :)
[10:14:30] <badon> I'll use your example too, that should be clear.

I'll give this, and other things I'd like to change some more thought before I make changes to the docs. Badon 19:52, 12 July 2011 (CEST)

Automatically updated property values

I wanted to achieve the following:

• Pages with Property:Date having the value of the current date shall also get value "true" assigned for Property:Today (type Boolean).

I tried to achieve that by this:

{{#ifeq: {{#show: {{FULLPAGENAME}} | ?Date}} | {{#time: j F Y }} | [[Today::true]] | [[Today::false]] }}

It seems values for properties are updated only when pages get saved. Saving those pages the day before and reading those pages on the current date they display "true" but the value for Property:Today is still false.

I'm clueless. Is there any way to make property values dynamic?

Thanks!

--Eric 12:18, 4 September 2011 (CEST)

Hi Eric, if think there is unfortunately no way around refreshing the page. Perhaps you give the mailing list a shot since some very experienced SMW-users are subscribed to it. Cheers --[[kgh]] 21:33, 4 September 2011 (CEST)

About new parser function #setto

In sam cases a needed create property not for the current page, but for the more common page. I think, there are reason in the Semantic MediaWiki extention for, that will be created new parser function #setto:

{{#setto:<page>|<property>=<value>|<property2>=<value2>}}

--Vpovilaitis 12:51, 23 December 2011 (CET)

Creating pages for special properties

Special properties work no matter whether you create pages for them or not.

But what is the policy/recommendation/"good practise"? Or could creating pages for them even do harm? What, for example, if you make Property:Modification date type Boolean?

I think it would be good to add a few clarifying lines to the documentaion.

--Eric 15:25, 29 February 2012 (CET)

Properties with the same names as datatypes

Properties can have the same name as datatypes (i.e. Property:Code, Property:Page, etc.) but the datatypes of these properties cannot be changed. Any explicit has type:: definition will be ignored. See demo here: http://sandbox.semantic-mediawiki.org/wiki/Code_property_test

Is it worth adding this information to the page? It confused me a bit; enough to raise a bug report.  :-)

—Samwilson (talk) 08:27, 3 August 2012 (CEST)

Heiya Samwilson, thank you for making aware of this. I have just added an new section on naming of properties which also contains information about this behaviour. I am sorry that it took me a while but I just saw your post now. Cheers --[[kgh]] (talk) 01:41, 18 September 2012 (CEST)