From: Markus <ma...@ai...> - 2007-03-25 13:56:21
|
OK, thanks to those who replied. We see that there is a lot of good argumen= ts=20 for either case. I try to summarise and add my view. I also add a number of= =20 revised/new proposals for discussion below. =3D=3D Pro-Keep =3D=3D I think S mentioned the most relevant argument against it:=20 * If editors want to remove the annotation from some statement, they don't= =20 know if they should also remove the brackets (if it is a link) or not (if i= t=20 is something else). The other issue, that the two things are conceptually different also in oth= er=20 respects, is less convincing to me. Users might not see this different=20 concepts anyway, and SMW blurs this clear distinction in a growing number o= f=20 cases (e.g. attributes of some types might display links).=20 =3D=3D Pro-Change =3D=3D The main complications with the current syntax seem to be: * The difference between "::" and ":=3D" to many users is not obvious, and = one=20 easily makes errors confusing the two. * For special properties (e.g. "has type" or "display unit"), forcing the u= ser=20 to use the right one of :: and :=3D seems to be unnecessary, since we know = what=20 special property it is anyway. * If we once support n-ary relations, there will be case where wikipages an= d=20 attribute values are mixed up in one annotation. For instance (using random= =20 syntax): [[has president:=3DKennedy; Jan 20 1961; Nov 22 1963]] which gives the president name (wikipage) and the time of him or her being = in=20 office. Now one could have optional parameters, e.g. if times are not known= =20 yet: [[has president:=3DBush; 2008]] or even [[has president:=3DClinton]]. That's where things will become confu= sing. =3D=3D Further issues =3D=3D Some things that were mentioned but are independent of the main question. * "Users may have problems finding the right attribute during editing." We = are=20 working on "intelligent" solutions for this. SMW might suggest attributes i= n=20 future versions. * "Untyped attributes should guess the type of the data based on user input= s."=20 Well, maybe. But the assumption for systems like Wikipedia is that there is= =20 much more content than relations/attributes, so most attributes are already= =20 defined nicely by someone else. The problem then is again to find the right= =20 attribute/relation. * "SMW-Syntax should always be hidden in templates." Maybe, though there ar= e=20 many cases where this does not work with current templates. We will try to= =20 make SMW's syntax as simple as possible anyway, even if people eventually=20 prefer template syntax. Also note that templates have the same problems as= =20 the proposed new syntax from a user perspective (you cannot distinguish=20 attributes from relations). * "SMW should (optionally) consider the link brackets as part of the annota= ted=20 value, thus supporting 4 nested brackets." This syntax is slightly too=20 heavy-weight for me in terms of brackets. The idea of [[Link]] being the=20 annotated value is reasonable, but maybe suggests a completely different=20 syntax, e.g. {{property:=3D[[Link]]}}. This might be doable. Any proponents= of=20 this (given that we provide a nice upgrade path for existing wikis)? See=20 below. =3D=3D New proposals =3D=3D 1) Keep everything as it is. 2) Keep the syntax :: and :=3D, but otherwise unify Attributes and Relation= s=20 (possibly calling all of them properties). Do checks to ensure that ":=3D"= =20 and "::" are used with properties of the right type. 3) Unify Attributes and Relations completely, allowing some Type:Wikipage a= nd=20 adopting Type:String as a default that catches everything. 4) Unify Attributes and Properties and use a template-like syntax that is=20 always put around the annotated wikitext.=20 Examples: * No annotation: 1,000,000 [[USA]] * 2): [[population:=3D1,000,000]] [[is located in::USA]] * 3): [[population:=3D1,000,000]] [[is located in:=3DUSA]] * 4): {{population:=3D1,000,000}} {{is located in:=3D[[USA]]}} =46eel free to order those proposals according to your preference (and let'= s=20 ignore details like ":=3D" vs. "::" for now). Regards, Markus On Friday 16 March 2007 17:31, Markus Kr=F6tzsch 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 ":= =3D" > 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 ":=3D" f= or > annotations? The syntax ":=3D" suggests a way of writing inverse relation= s in > queries via "=3D:", but maybe this is not obvious enough to be a good ide= a. > 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 =2D-=20 Markus Kr=F6tzsch Institute AIFB, University of Karlsruhe, D-76128 Karlsruhe ma...@ai... phone +49 (0)721 608 7362 www.aifb.uni-karlsruhe.de/WBS/ fax +49 (0)721 693 717 |