[SMW-devel] Changes for using multi-valued properties
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. This change needs to be done to all property pages
that use a declaration like the old one above (but please read on before
updating from SVN and starting with this change). With the new SMW, you can
actually ask for those properties with the query (~ is now enabled by default
for all sites):
{{#ask: [[has type::~*;*]] }}
(Note that types are not stored with their translated labels internally, so ~
queries are not likely to be of much use for has_type in general; but it works
well enough for the ; in n-ary types. The fact that this works also
illustrates how the new SMW code consistently supports all features in the
same way for all properties/datatypes that allow it.)
== Call for labels ==
Two new labels are used above: Value list (the name of the type) and has
fields (the name of the property for declaring which fields this property
has). Both labels are just preliminary and may still be changed. We have
already had some history of changing the name of n-ary/multi-valued
properties.
Technically, the new type is not a list (a sequence of arbitrary length with
a fixed type) but a tuple (like a pair but not specifically with 2
values). But this term will not be meaningful to most users, so maybe list is
not so bad. We can still change it if better proposals are made.
Afterwards, we will need translations for the labels so that non-en wikis can
use their own language right away, but I will call for this in another email.
Cheers,
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
Re: [SMW-devel] Changes for using multi-valued properties
Hi,
wouldn't be [[has type:: List]] most consistent with other types like String,
Number? Or are there other list types than 'Value List' (list of values)
possible (e.g. 'Object List' ...)?
What happens in the case of just one field used?
[[has type:: Value list]]
[[has fields:: String]]
Is it equivalent to [[has type:: String]]?
In the query example shouldn't
{{#ask: [[has type::~*;*]] }}
be
{{#ask: [[has fields::~*;*]] }}
?
Cheers,
Gu
P.S.
Just a thought, for backward compatibility, couldn't SMW if it finds a [[has
type::]] value string with a ';' in it silently use it as [[has fields::]] value
and set [[has type::]] to 'Value List' (or whatever name is used)?
Quoting Markus Krötzsch mar...@semantic-mediawiki.org:
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. This change needs to be done to all property pages
that use a declaration like the old one above (but please read on before
updating from SVN and starting with this change). With the new SMW, you can
actually ask for those properties with the query (~ is now enabled by default
for all sites):
{{#ask: [[has type::~*;*]] }}
(Note that types are not stored with their translated labels internally, so ~
queries are not likely to be of much use for has_type in general; but it
works
well enough for the ; in n-ary types. The fact that this works also
illustrates how the new SMW code consistently supports all features in the
same way for all properties/datatypes that allow it.)
== Call for labels ==
Two new labels are used above: Value list (the name of the type) and has
fields (the name of the property for declaring which fields this property
has). Both labels are just preliminary and may still be changed. We have
already had some history of changing the name of n-ary/multi-valued
properties.
Technically, the new type is not a list (a sequence of arbitrary length
with
a fixed type) but a tuple (like a pair but not specifically with 2
values). But this term will not be meaningful to most users, so maybe list is
not so bad. We can still change it if better proposals are made.
Afterwards, we will need translations for the labels so that non-en wikis can
use their own language right away, but I will call for this in another
email.
Cheers,
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
--
--
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
Re: [SMW-devel] Changes for using multi-valued properties
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? 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. 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. -- Jonathan Dataweaver Lang [1] http://www.w3.org/TR/2006/NOTE-swbp-n-aryRelations-20060412 -- 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
Re: [SMW-devel] Changes for using multi-valued properties
On Donnerstag, 7. Januar 2010, zehet...@molgen.mpg.de wrote:
Hi,
wouldn't be [[has type:: List]] most consistent with other types like
String, Number? Or are there other list types than 'Value List' (list of
values) possible (e.g. 'Object List' ...)?
Good point. So my preferred name for now would be List.
What happens in the case of just one field used?
[[has type:: Value list]]
[[has fields:: String]]
Is it equivalent to [[has type:: String]]?
No, it is still a List with one field.
In the query example shouldn't
{{#ask: [[has type::~*;*]] }}
be
{{#ask: [[has fields::~*;*]] }}
?
Yes, right.
-- Markus
Cheers,
Gu
P.S.
Just a thought, for backward compatibility, couldn't SMW if it finds a
[[has type::]] value string with a ';' in it silently use it as [[has
fields::]] value and set [[has type::]] to 'Value List' (or whatever name
is used)?
Quoting Markus Krötzsch mar...@semantic-mediawiki.org:
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. This change needs to be done to all property
pages that use a declaration like the old one above (but please read on
before updating from SVN and starting with this change). With the new
SMW, you can actually ask for those properties with the query (~ is now
enabled by default
for all sites):
{{#ask: [[has type::~*;*]] }}
(Note that types are not stored with their translated labels internally,
so ~
queries are not likely to be of much use for has_type in general; but it
works
well enough for the ; in n-ary types. The fact that this works also
illustrates how the new SMW code consistently supports all features in
the same way for all properties/datatypes that allow it.)
== Call for labels ==
Two new labels are used above: Value list (the name of the type) and
has fields (the name of the property for declaring which fields this
property has). Both labels are just preliminary and may still be changed.
We have already had some history of changing the name of
n-ary/multi-valued properties.
Technically, the new type is not a list (a sequence of arbitrary length
with
a fixed type) but a tuple (like a pair but not specifically with 2
values). But this term will not be meaningful to most users, so maybe
list is
not so bad. We can still change it if better proposals are made.
Afterwards, we will need translations for the labels so that non-en wikis
can
use their own language right away, but I will call for this in another
email.
Cheers,
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
Re: [SMW-devel] Changes for using multi-valued properties
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
Re: [SMW-devel] Changes for using multi-valued properties
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. Another possibility, which I partly use in the SQFT extension, would be to supply the names via other properties on the property page which allows different set of names for different purposes (e.g. as index replacement in ask queries, as table headers etc.): [[has fields:: String; Number; Page]] [[has names:: name; count; source]] [[has long_names:: official id of component; occurences between 2000 and 2007; first publication mentioning component]] [[has headers:: ID by EMBL; 2000-2007 ; Publication]] Gu -- 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
Re: [SMW-devel] [Semediawiki-user] Changes for using multi-valued properties
I don't think using List as a type name is a good idea, because list is
already generally used to indicate that a template field holds a list of
values. This naming is used even in SMW itself - the #declare function can
be called with {{#declare:property-name=field-name#list}}. This naming
confusion could apply even to Value list, actually.
As for a better name - how about N-ary? Yes, it's obscure, but then again
people probably wouldn't use this type unless they understood the concept
anyway. N-ary has the advantage that it doesn't introduce yet another term
- it's already the name used in the database table and code, and in
discussions.
I should note, since I'm on the subject, that I would just as well see these
multi-value properties removed from SMW altogether. Even if the issues
with querying get resolved, they're still an un-ideal solution: they're
inflexible, they don't support enumerations (i.e., a limited set of allowed
values), and, maybe most compellingly, they're not semantic - there's no
way to indicate what each value actually means. But maybe that's a topic for
another discussion...
-Yaron
On Thu, Jan 7, 2010 at 9:16 AM, Markus Krötzsch
mar...@semantic-mediawiki.org wrote:
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
