Menu
▾
▴
Re: [Semediawiki-user] Unify relations and attributes? (update)
|
From: Ittay D. <it...@ql...> - 2007-03-27 13:39:19
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body dir="ltr" bgcolor="#ffffff" text="#000000">
<p style="margin-bottom: 0cm; margin-top: 0pt;">+1<br>
<br>
Markus Krötzsch wrote on 03/27/07 10:34:<br>
</p>
<blockquote cite="mid:200...@ai..."
type="cite">
<pre wrap="">We had some additional internal discussions, and came up with the following
proposal, which tries to integrate all ideas and arguments put forward so
far:
* Recombine the namespaces "Relation" and "Attribute", and call the new
namespace "Property".
* Introduce a new datatype Type:Wikipage which can be used for properties (the
former attributes).
* Annotations for Type:Wikipage are written like
[[property:=[[page name]]]] or [[property:=[[page name]] ]]
* Types of untyped properties are guessed, usually to be either Type:String or
Type:Wikipage (and maybe also Type:Float).
* Syntactic sugar is introduced: to abbreviate [[property:=[[page name]] ]],
one can just write [[property::page name]].
* The :: notation enforces the type. If another type than Wikipage is already
given, annotations with :: will not be stored, but are still rendered as
normal articles. Hence, changing one type can not easily break existing
articles.
This will hopefully enable us to support n-ary relations at some point. Here
is our plan:
* Basically, one would allow properties to have types of the following form:
[[has Type:=[[Type:Weight]]; [[Type:Wikipage]] ]] or
[[has Type:=[[Type:Wikipage]]; [[Type:Date]]; [[Type:Date]] ]]
(maybe we can do something about the large number of [[]] too ...)
* Such properties can then be used in statements of the form
[[has ingredient:=300g; [[Sugar]] ]] or
[[has president::Bush; 2001; 2008]]
(note that we again use :: to save [[]] around the first value)
* On a page, by default they would be displayed by using parentheses:
"300g (Sugar)" or
"Bush (2001, 2008)"
* The formatting can be controlled by providing templates on the property
page, e.g. to obtain
"300g Sugar" or
"Bush (2001-2008)"
* It will be possible to omit any of the values of n-ary relations, and the
system will try to guess what was omitted. If this is not clear, users can
use an empty value to clarify that something was omitted. Examples:
[[has president::Bush (2001)]]
-> just gives the start date (the end might be earlier than 2008 -- who
knows ...)
[[has president::Clinton]]
-> omits all dates; note that this looks like a normal "Relation"
[[has president::Washington; ;1797]]
-> omit first date; maybe the user was not sure of it
* Omitted values will be displayed as "?", though formating templates could
check this and do something else if they like.
* Querying will largely work as it does now, with additional syntax using ;
* Some details must still be defined, and it will be a lot of implementation
work.
More things to discuss, I guess ...
-- Markus
On Sunday 25 March 2007 16:44, Ittay Dror wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> Markus Krötzsch wrote on 03/25/07 15:56:
[snip]
== New proposals ==
1) Keep everything as it is.
2) Keep the syntax :: and :=, but otherwise unify Attributes and Relations
(possibly calling all of them properties). Do checks to ensure that ":="
and "::" are used with properties of the right type.
3) Unify Attributes and Relations completely, allowing some Type:Wikipage
and adopting Type:String as a default that catches everything.
I liked Günther's syntax proposal. i suggest using Type:String for any
property that is not of the form [[prop]]. by using such a form, the user
indicates the type of property is Type:Wikipage. This will also solve the
annotation removal issue.
so: [[capital:=[[Berlin|alternate text]]]] [[located in:=Europe|alternate
text 2]] means Berlin is a wiki page and Europe is a value. if at some
point someone decides to change the type of 'located in' to Type:Wikipage,
there's no problem (that is, the braces around the property value have
meaning only if the type of property is not defined)
4) Unify Attributes and Properties and use a template-like syntax that is
always put around the annotated wikitext.
Examples:
* No annotation: 1,000,000 [[USA]]
* 2): [[population:=1,000,000]] [[is located in::USA]]
* 3): [[population:=1,000,000]] [[is located in:=USA]]
* 4): {{population:=1,000,000}} {{is located in:=[[USA]]}}
Feel free to order those proposals according to your preference (and let's
ignore details like ":=" vs. "::" for now).
Regards,
Markus
On Friday 16 March 2007 17:31, Markus Krötzsch wrote:
Hello SMW users!
Please take a few minutes to decide upon the future of SMW syntax. Short
answers suffice.
----
Our increasing impression is that the distinction between Relations and
Attributes in SMW is no longer the best solution. It was useful when ":="
still behaved mostly different from "::", but it seems that the growing
number of types of attributes might as well include a type "wikipage" that
makes them act like relations. This could simplify wiki syntax as well as
explaining SMW to new users.
So, dear SMW users, what do you think?
(1) Should we merge Relations with Attributes by providing a new datatype,
and by treating untyped attributes as relations by default (instead of
rejecting them as done now)? Why?/Why not?
(2) If only one remains, should we rather use the syntax "::" or ":=" for
annotations? The syntax ":=" suggests a way of writing inverse relations in
queries via "=:", but maybe this is not obvious enough to be a good idea.
Which syntax looks more user-friendly in general?
(3) Should we call the remaining semantic elements "Relations"
or "Attributes"?
(4) How would the type "wikipage" that is used for emulating relations be
called? "Article", "Page", "Wikipage", "Link", ...?
Your feedback is greatly appreciated.
Cheers,
Markus
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your opinions on IT & business topics through brief surveys-and earn cash
<a class="moz-txt-link-freetext" href="http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV">http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV</a>
_______________________________________________
Semediawiki-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Sem...@li...">Sem...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/semediawiki-user">https://lists.sourceforge.net/lists/listinfo/semediawiki-user</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<b>Ittay Dror</b>
<br>
Chief Architect,
<br>
R&D, Qlusters Inc.
<br>
Web: <a href="http://www.qlusters.com/">qlusters.com</a>
<br>
Email: <a href="mailto:it...@ql...">it...@ql...</a>
<br>
Phone: +972-3-6081994 <br>
<br>
<a href="www.openqrm.org"><img
src="cid:par...@ql..."> openQRM</a> - Data
Center Provisioning
</div>
</body>
</html>
|