On Donnerstag, 7. Januar 2010, Jon Lang wrote: > Markus Krötzsch wrote: > > The code for n-ary/multivalued has now been changed in SVN, and a new > > system is in place. This email describes the changes for users, and asks > > for proposals on how to label some things that users will have to enter. > > This thread does not discuss the maximal number of fields in a > > multi-valued property (there is another thread for this). > > > > == Changes for the user == > > > > The old way of declaring an n-ary property was to give a type annotation > > like the following on its property page: > > > > [[has type:: String; Number; Page]] > > > > This example declares a property that has three fields of the given order > > and type. The new code requires a modified declaration that contains two > > annotations: > > > > [[has type:: Value list]] > > [[has fields:: String; Number; Page]] > > > > So the type is no longer the list but it has a name, and the list of > > fields is given in a new property. > > Does the type have to be "Value list", or can you add "has fields" to > other properties?
No, you have to specify the type. > My reasoning: in the "Defining N-ary Relations on > the Semantic Web" article[1], a distinction was made between an N-ary > relation that represents a primary value with supplementary > information and an N-ary relation that represents different aspects of > a common relation with no preference for one value over any of the > others. It occurs to me that by allowing "has fields" on non-"Value > list" property pages, we could capture this distinction quite > intuitively: if the property page includes "has type:: Value list", > then there is no primary value: any queries concerning values for that > page must refer to the fields; if the property page specifies any > other type, then that is considered to be the primary value, and > queries for values on that page assume that you're referring to the > primary value unless you explicitly ask for the fields. I see your point but I don't think that this is needed. The reason is that there would be basically two cases that could occur: (1) The primary value is a wiki page. In this case, assigning a value to the N-ary relation would specify additional annotations of that primary page value. So one would specify annotations of a page within some other page. This is not supported by SMW and it is not needed, since one can always edit the primary page directly. (2) The primary value would be a data value that is not a page. Then you would attach annotations to a datavalue, e.g. to the number "42". This is not desirable, since neither SMW nor RDF support annotations on data literals such as numbers or strings. > > Related to this is the notion of named fields. Please give the option > to attach meaningful names to the fields for querying purposes, so > that the user doesn't have to specify a positional list of values. > For instance: > > [[has fields:: name=String; count=Number; source=Page]] > > This would allow queries for instances of the property by means of a > specific value for the name, property, and/or source. As I said, this task can be approached now. It is not going to be an extension of Type:List (the current favourite name of "Value list"), but another type that allows for these inputs (how could this be called?). Thanks for your syntax proposal; I think this is probably the most straightforward syntax to pick. I should add that we can have any number of such types that use different syntaxes for different purposes. One could also have special-purpose types for naturally occurring compound data such as street addresses (as written in some language). I am not going to write these, but they could be part of extensions. SMW now has an abstract datavalue class SMWContainerValue that can be used to create any kind of value implementations that store values that resemble an annotated page (just "internal", i.e. without a name). -- Markus -- Markus Krötzsch <mar...@semantic-mediawiki.org> * Personal page: http://korrekt.org * Semantic MediaWiki: http://semantic-mediawiki.org * Semantic Web textbook: http://semantic-web-book.org --
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
