From: "S Page" <[EMAIL PROTECTED]>
Sent: Tuesday, August 14, 2007 2:30 AM
> Eep² wrote:
>
>> Unnecessary as well; "has president" is the same as "is president of",
>
> No it is not, one is the inverse of the other. You may be hoping to pick one
> meaning , put [[president::USA]] on the George
> Walker Bush page, and have "George Walker Bush president USA" automatically
> show up on the United States page; but SMW 0.7
> doesn't work that way except in Special:Browse.
>
If you mean to say "contains president" (like a category), then that is exactly
what a category should be used for and SMW should
leave alone without complicating things any more than they already are. But,
really, categories can be used for "is president of" as
well since Bush can be in the categories "United States" and "presidents" and a
union category (set) search of any 2 categories
("Bush" also being a category which not only contains presidents but other
people's names, the foliage, a "see also" link to Busche
beer, etc) will result in "George Bush" (father and son). Then, it's just a
matter of selecting which one ("George Herbert Walker
Bush" or "George Walker Bush").
At any rate, instead of "has president", the colon (:) can be used to denote
"ownership" (parent-child relationships). "President:
Bush" and "Bush: President" both mean the same thing, essentially, but "United
States president: Bush" is more descriptive than "has
president" (which can just be represented by "president"). I say leave out the
prepositions as they only serve to confuse and
complicate things. Relationship/category (set) unions can replace prepositions,
like a Venn diagram where "Bush", "president", and
"United States" are all in circles that intersect each other in the middle to
produce "United States president Bush" (or "Bush
president United States" or "United States Bush president" or "Bush United
States president" depending on how the ordering is).
But, really, all of these classification systems (categories, namespaces,
subpages, or semantic
relationships/attributes/properties/types) all basically do the same thing. See
http://www.tnlc.com/wiki/index.php?title=3DGC:Design
for my experiments with them and their dis-/advantages.
>>> You can use templates to insert linked text together with attributes into
>>> Wiki pages.
>>
>> Example?
>
> http://ontoworld.org/wiki/Template:Between is a simple example.
> http://ontoworld.org/wiki/Template:Distance reformats the parts of
> a quantity for display, makes some parts links, and creates an attribute from
> them. Other templates on ontoworld.org are much
> more sophisticated but rely on the ParserFunctions extension.
>
More templates of things SMW should be able to do inherently like DPL can...
>>> Please can you give examples of when you would need to link an attribute
>>> value in factboxes and search results?
> >
>> Well, for my 3D game comparison, in comparing various features, I want to
>> have [[effect::weather]] and then [[weather
>> effect::rain]] appear under "effect::weather" (preferably as a type of it
>> without having to specify yet another relationship that
>> appears alphabetically instead of intuitively under the parent relationship,
>> forcing me to use [[effect weather::rain]] instead).
>>
> I think you're asking for a way to identify Relation:weather_effect as a
> subproperty of Relation:effect, and for SMW to know about
> this so that the factbox would display subproperties under the parent
> relation in the factbox. (Also, querying for
> Relation:effect would find instances of Relation:weather_effect .) Current
> SMW don't do that. It's a solid idea, Michael Uschold
> was also asking for rdfs:subPropertyOf support; I wish I could remember how
> to code. You should file it in the wikimedia bugbase
> as an enhancement request referencing this e-mail thread.
>
I don't like using Bugzilla; my enhancement requests keep getting rejected
because I didn't file separate requests for every little
thing (which is ridiculously inane to do).
>> The problem is types only apply to attributes which don't create links
>> (which is why I have to use relationships and am asking if
>> the upcoming "property" can be displayed as links too).
>
> How would SMW's datatyping or a unification of attributes and relations into
> properties help you get the factbox display you're
> seeking? The only datatype that seems relevant is Type:Enumeration, which
> would let you restrict Attribute:Weather_effect to a
> set of strings ("clouds", "clouds (moving)", "fog", and "rain".). It might
> be nice to extend this to limit the allowed values of
> a relation, but it's not what you're asking for. Maybe you're just hoping to
> say "weather_effect [[has type::Relation:effect]]",
> but that's not how datatypes work and I'm pretty sure the technical term for
> what you want is rdfs:subPropertyOf, not rdf:type (or
> rdfs:subClass).
>
Well, ideally, I would like the semantic form to have drop-/pull-down lists of
various relations/attributes/properties (whatever)
but, unfortunately, Semantic Forms (the only extension I know of to support
Semantic MediaWiki) can do this and can only bring in
categorized pages (and not in a standard HTML-style select listbox either,
which is what I want). That's why I'm trying to get Jaron
to implement DPL features in Semantic Forms. I can't get the other form
extension I know of, Simple Forms, to work so I'm stuck with
Semantic Forms, DPL, and SMW--and trying to get them all to work with each
other. Currently I mostly just use DPL since it's the
most versatile of all 3 extensions thus far, but even DPL isn't enough to do
what I want. :\
Another option is to use dynamic javascript select listboxes so if "weather
effect" is chosen, only "clouds", "rain", snow", "wind",
etc appear in the next listbox. Then, if "clouds" is chosen, a multi-select
listbox (or checkboxes) would show "moving", "fading",
"buildup" (dynamic building/dissipating), etc and text-entry fields for even
more specific/detailed info, if necessary. I'm most
likely going to have to manually re-edit everything in order to get all the
relationships/links between things correct but I'd like
to make the game entry form as technically intuitively dynamically detailed as
possible.
> For what it's worth, in SMW 0.7 you could have a template {{weather
> effect|rain}} that inserts [[effect::weather| ]] as well as
> [[weather effect::{{{1}}}]]. That would save typing, but would not organize
> the factbox the way you want.
>
Yea, and would kill the server in template calls with all those
relations/attributes/properties... :/ SMW and DPL already cause
enough server calls!
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Semediawiki-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
