> Asking this again because I never got an answer before on the user list
You probably got ignored because you're simultaneously dismissive and
ignorant of what SMW tries to achieve. But hey, I'm just guessing.
You seem to be using Semantic Forms which I understand builds on SMW to
provide editing forms for template data. So I can accept some "Why does
SMW do it that way?" if your primary goal is not annotating wiki text
with semantics. You seem frustrated the combination doesn't do what you
want but haranguing volunteer developers who don't have time to
understand both code bases won't magically deliver features.
> or on
> With the new property, er, property (attribute? option?
Property. Former Relations become a type of property, alongside the
other property datatypes (strings, dates, enumeration, etc.)
> will it work like relationships do now with
> [[relationship::name]] where the "::" (double colons) create a link
> whereas [[attribute:=name]] doesn't create a link?
Quick answer: no. The type of property determines how it displays.
Given [[MyProperty:=Value]], MyProperty's datatype defaults to wiki page
(such properties are relations in SMW 0.7) and SMW will display Value as
a link. If you give MyProperty a type, then SMW displays Value
depending on that type (type:string and type:enumeration appear as text,
type:email appears as a mailto: link, etc.).
It works this way because the arrow between two pages is
owl:ObjectProperty and the arrow between a page and a mere datavalue is
owl:DataTypeProperty. They're different things. (Now you're going to
tell us how that's way too complicated, please see my first sentence above.)
> I ask because
> I need that functionality for both parameters ("relationship" and
> "attribute") now in SMW .7 and I hope "property" can do both links
> and non-links as well in the next SMW version...
Here's how to get links and non-links:
1. A page property ("relation" in SMW0.7) is always a link, even if you
give alternate text. But you can give it blank alternate text and
follow with the value: [[MyPageProperty:=Value| ]]Value
2. A string or enumerated property is always text. But you can give a
link in its alternate text: [[MyStringProperty:=Value|[[Value]]]].
(It seems in current pre-alpha code you can simply write
[[MyStringProperty:=[[Value]] ]], but
http://ontoworld.org/wiki/Type:String says string values cannot have
double closing brackets in them.)
3. If you don't like typing "Value" twice you can create template(s)
that expand into one or the other.
I assume you already know this; does this not work well with Semantic Forms?
I've imagined a string variation, call it Type:WikiText, where you can
reliably say [[MyWikiTextProperty:=[[This Links]] ]] and
[[MyWikiTextProperty:=This doesn't]]. This raises a whole host of
parsing and display problems, but would it help you?
From some of your other posts, perhaps you want to have a
Type:Enumeration where some possible values appear as links and others
aren't? Would a Type:EnumerationWikiText help you (some allowed values
would contain [[This Links]])? Or Semantic Forms could know about the
desired appearance and figure out how to provide the alternate text.
This is just guessing. If you can explain what you're doing with a
test page and why the alternate text workaround isn't satisfactory, it
> Also, why require ":=" over simply "::" for creating properties? "::"
> ("shift+;;") is easier to type than ":=" (requires "shift+;"
> and "=")?
You're assigning a value to the property, hence :=. IMO colon already
does too much in MediaWiki. In current (pre-release) code, :: and :=
are equivalent but :: is only for backwards compatibility.