Re: [SMW-devel] RFC Subobjects (aka internal objects) in SMW
On 01/11/11 00:54, Jonathan Lang wrote:
Markus Krötzsch wrote:
I would like to give an aggregated reply to the discussions around having
formatting strings with {{{markers}}} to be part of #subobject declarations.
Decision: we will not implement this.
Reason: MediaWiki has templates for doing exactly this. SMW will not
replicate available functionality. To get subobjects with custom
formatting one can create a template that produces the format based on
input parameters. This template can then include a #subobject call. This
solution is more powerful (you can have arbitrarily complex formatting in
templates without syntactic restrictions), much more robust (no conflict of
{{{markers}}} and no hacks in the MediaWiki parser to use this syntax),
readily available without any implementation work and already familiar to
users without additional training. :-)
If the decision has already been made, then so be it. But let me just put in
a dissenting opinion: subobjects themselves are redundant in much the same
way that you say that online templates would be: there's nothing that you can
do with a subobject that you can't do with a separate page.
Ok, fair point. The explanation should then include that SMW is
conceived as a data management extension, but tries to keep small on
data formatting/visualisation. So the real reason is the overall project
goal.
But with the new functions in place, it is easy to make many
#subobject-like parser functions with all kinds of extra features. The
file implementing #subobject is hardly a 100 lines and most of it could
be re-used for building modified versions of it.
Markus
--
RSAreg; Conference 2012
Save #36;700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] RFC Subobjects (aka internal objects) in SMW
On 30/10/11 21:43, Stephan Gambke wrote: Hi Markus, Am 30.10.2011 12:12, schrieb Markus Krötzsch: Thanks. What I now implemented requires naming for all subobjects, so it is not optional. One could have another parser function that does not require a name; overloading #subobject to do both (named subobjects without any return value and anonymous subobjects returning their generated name) seems to have a great potential for confusion. Maybe we don't need unnamed subobjects after all. I think unnamed subobjects would be very useful. E.g. suppose you have a multiple-instance template in a Semantic Form. Currently there is no way to ensure unique names for the subobjects. (Ok, you could use the extensions Variables and Parser Functions). Fair point. I could provide another parser function for this (behaviour: it gets only a list of property=value pairs and returns the name of the generated subobject). So we need a second new name :-o. But I think overloading #subobject is possibly confusing (if the first parameter does not contain a '=' then make a subobject name and return it; otherwise use the first parameter as a name and do not return anything). Regards, Markus -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] RFC Subobjects (aka internal objects) in SMW
I would like to give an aggregated reply to the discussions around
having formatting strings with {{{markers}}} to be part of #subobject
declarations.
Decision: we will not implement this.
Reason: MediaWiki has templates for doing exactly this. SMW will not
replicate available functionality. To get subobjects with custom
formatting one can create a template that produces the format based on
input parameters. This template can then include a #subobject call. This
solution is more powerful (you can have arbitrarily complex formatting
in templates without syntactic restrictions), much more robust (no
conflict of {{{markers}}} and no hacks in the MediaWiki parser to use
this syntax), readily available without any implementation work and
already familiar to users without additional training. :-)
Cheers,
Markus
On 24/10/11 18:00, John McClure wrote:
Are embedded subobjects something like
{{#subobject: objname | objpropname= {{#subobject: subobjname |
subobjpropname=x}}
}}
I am mystified by the {{{given}}}...{{{family}}} parameter - how is it
used/referenced? More than one? Positional?
I don't think subobject is technically accurate, nor object for that
matter, as these technically connote behavior.
How about vector?
-Original Message-
*From:* Jon Lang [mailto:datawea...@gmail.com]
*Sent:* Sunday, October 23, 2011 3:48 PM
*To:* Yury Katkov
*Cc:* Semediawiki-user; Markus Krötzsch; Semantic MediaWiki developers
*Subject:* Re: [SMW-devel] RFC Subobjects (aka internal objects) in SMW
Sorry for the late response.
Would it be reasonable to have the syntax be something like:
{{#subobject:name
| given=Jonathan
| family=Lang
| middle=LeRoy
| surname=Mr.
| {{{given}}} {{{middle}}} {{{family}}}
}}
{{#subobject:name
| given=Ranma
| family=Saotome
| {{{family}}} {{{given}}}
}}
This way, the subobject's formatting could be determined on a
case-by-case basis, and in a manner that people are used to (i.e.,
value on the left; display on the right). In effect, the unnamed
entry is assumed to contain an inline template for display
purposes. This saves you the trouble of writing a new template every
time you want to format a subobject differently.
If no inline template is given, there should be a default inline
template on the property page; possibly use the property page itself
/as/ the default template, and rely on the usual tricks used by
template pages to define text that should only be available when
viewing the property page and text that should only be available
when making use of it as a template.
BTW: subobject is technically accurate, but needlessly long. I'd
recommend going with object instead. Granted, this is a nitpick;
but there you are.
--
Jonathan Dataweaver Lang
--
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World#153; now supports Android#153; Apps
for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple
it is! http://p.sf.net/sfu/android-dev2dev
___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] RFC Subobjects (aka internal objects) in SMW
On 24/10/11 18:05, John McClure wrote:
There is a difference though: wikipages are listed on special:allpages.
If an object is the value of a page property, then it's listed on
special:browse.
If an object is not a value of any page property, then where is it listed?
Maybe a pseudo namespace can contain these.
The use of a special property (currently called has subobject) should
solve this now. All subobjects now appear on Special:Browse and also on
the property page Property:Has_subobject.
Markus
-Original Message-
From: Markus Krötzsch [mailto:mar...@semantic-mediawiki.org]
Sent: Wednesday, October 12, 2011 10:14 PM
To: jmccl...@hypergrove.com
Cc: 'Semediawiki-user'; 'Semantic MediaWiki developers'
Subject: Re: [SMW-devel] [Semediawiki-user] RFC Subobjects (aka
internal objects) in SMW
On 07/10/11 19:21, John McClure wrote:
Under #2 scenario, if a template creates a subobject but never uses it in
{{#set}} then what is the impact?
Then the subobject will be like a wikipage with the property values as
specified. The subobject will just not have an incoming property from
its parent page.
This can occur, e.g., if subobjects are used as in the SIO extension
with a property pointing *to* the parent page instead of away from it.
Another possible use case are subobjects of subobjects which would also
not have a direct relation to the parent page.
Regards,
Markus
--
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World#153; now supports Android#153; Apps
for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple
it is! http://p.sf.net/sfu/android-dev2dev
___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] RFC Subobjects (aka internal objects) in SMW
Updates on the subobject feature. The following changes have now been
implemented and committed to SVN.
== Parser function #subobject ==
The new parser function #subobject can be used to create *named*
subobjects. Example:
{{#subobject:My office address
| street name=Parks Road
| postcode=OX1 3QD
| city=Oxford
| country=UK
}}
creates a new subobject with four property values. If this is done on a
page called Testpage then the subobject is named
Testpage#My_office_address and it can be used under that name
everywhere in the wiki. Example:
[[has office address::Testpage#My_office_address]]
You can use space instead of underscore _ as they are equivalent
in fragments (in MediaWiki) and in subobject names (in SMW). However,
note that fragment names are strictly case sensitive, even in the fist
letter. So my office address is not the same as My office address.
To have a property from the subobject to the parent page (like in the
SIO extension) simply add such a property to the data. Example:
{{#subobject:My office address
| street name=Parks Road
| postcode=OX1 3QD
| city=Oxford
| country=UK
| is address of=Markus Kroetzsch
}}
on the page Markus Kroetzsch.
The #subobject parser function is completely silent and returns no text
unless errors occur. If errors happen, then they are shown in the place
where the parser function is used.
== Fragment support for wiki page values ==
As indicated above, all wiki page property values can now have
fragments. They will be stored faithfully and be part of the meaning of
a value. Different fragment names encode different values.
You can also use the MediaWiki shortcut for fragments of the page you
are one. Example:
[[has office address::#My office address]]
on the page Testpage has the same meaning as [[has office
address::Testpage#My office address]]. This makes it easier to link to
subobjects too.
== Interaction with subobjects ==
Subobjects work like pages in all interfaces (they are represented in
the same datastructure internally, so all existing code will work with
them if it works with pages now).
All subobjects of a page that are created with #subobject are assigned
to the new predefined property Has subobject. This can be used to
query for all subobjects and to show them on pages like Special:Browse
even if they are not otherwise linked to anything.
Cheers,
Markus
P.S. I have also adjusted the display of page names in SMW in general as
part of the inclusion of subobjects. This may affect some displays,
especially if the change was not propagated to all places in SMW. I will
send another email to the devleoper list to explain the details to other
devs. Let me know if you discover any display problems with page names.
On 03/10/11 10:02, Markus Krötzsch wrote:
Following up the discussions we had at SMWCon in Berlin, we have now
implemented a new feature for internal objects in SMW. This email
explains this feature and starts the discussion on some open questions
for it to become stable.
== Goal ==
Allow SMW annotations to refer to objects that have their own
property-value pairs just like wiki pages, but that do not actually have
an article in the wiki. This can be used to group property-value pairs
given on one page without requiring new auxiliary pages to be created.
It also integrates the main functionality of the Semantic Internal
Objects (SIO) extension into SMW.
== Feature Overview: Current Prototype Implementation ==
SMW now has a new subobject feature. For example, you can use the
parserfunction #subobject on some page Example page as follows:
{{#subobject:street address
| street name=Parks Road
| postcode=OX1 3QD
| city=Oxford
| country=UK
}}
This does the following:
(A) create a new subobject called Example page#_anInternalId,
(B) assign the property values for street name, ..., country to this
subobject,
(C) assign the subobject Example page#_anInternalId as a property
value for street address to Example page.
You could have achieved a similar effect as follows:
(A') create a new page called my auxiliary page,
(B') edit this new page to contain the text:
[[street name::Parks Road]]
[[postcode::OX1 3QD]]
[[city::Oxford]]
[[country::UK]]
(C') edit the page Example page to contain the text:
[[street address::my auxiliary page]]
The difference when using #subobject is that you do not create a new
auxiliary page. Instead, a subobject of Example page is created by
SMW. Also, the function #subobject does not display anything unless an
error occurred that needs to be reported.
Subobjects are named automatically by following the schema Parent page
name#_someInternalId. When subobjects are displayed to users, they thus
appear like links to sections within their parent page. This can happen,
e.g., subobjects might occur in query results (example above: {{#ask:
[[postcode::OX1 3QD]] }}). Likewise, subobjects are also addressed by
this name
Re: [SMW-devel] RFC Subobjects (aka internal objects) in SMW
Yury Katkov wrote:
Hi!
Are you sure about the syntax here? Those {{{Parameters}}} surrounded by
curly braces will conflict with template parameters, won't they?
Yes, they will: if you have a template parameter with the same name as a
subobject field, you will lose access to the template parameter within the
subobject's display field. It's a problem; but IMHO it's a minor problem,
in that the primary purpose of the subobject's display field is to display
the subobject's contents.
You *could* avoid the problem by using some other delimiter for the
subobject fields; but the reason why I suggested triple-curlies is precisely
*because* that's what template parameters use: anyone familiar with wiki
syntax will have no problem intuiting their meaning.
How about this: use {{{# ... }}} as the delimiters for inline template
parameters. So:
{{#subobject:name
| given=Ranma
| family=Saotome
| {{{#family}}} {{{#given}}}
}}
The triple curlies indicate that you'll be substituting a value here, and
the hash marks indicate that the value will come from within the subobject.
Mind you, the default format supplied by the property page would still use
regular template parameter syntax; the {{{# ... }}} syntax would be for the
concept of the inline template only.
I could also see this concept of inline templates being used with #ask to
provide on-the-fly formatting for search results.
--
Jonathan Dataweaver Lang
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] RFC Subobjects (aka internal objects) in SMW
Hi!
Are you sure about the syntax here? Those {{{Parameters}}} surrounded by
will conflict with template parameters, won't they?
Yury
On Mon, Oct 24, 2011 at 3:48 AM, Jon Lang datawea...@gmail.com wrote:
Sorry for the late response.
Would it be reasonable to have the syntax be something like:
{{#subobject:name
| given=Jonathan
| family=Lang
| middle=LeRoy
| surname=Mr.
| {{{given}}} {{{middle}}} {{{family}}}
}}
{{#subobject:name
| given=Ranma
| family=Saotome
| {{{family}}} {{{given}}}
}}
This way, the subobject's formatting could be determined on a case-by-case
basis, and in a manner that people are used to (i.e., value on the left;
display on the right). In effect, the unnamed entry is assumed to contain
an inline template for display purposes. This saves you the trouble of
writing a new template every time you want to format a subobject
differently.
If no inline template is given, there should be a default inline template
on the property page; possibly use the property page itself *as* the
default template, and rely on the usual tricks used by template pages to
define text that should only be available when viewing the property page and
text that should only be available when making use of it as a template.
BTW: subobject is technically accurate, but needlessly long. I'd
recommend going with object instead. Granted, this is a nitpick; but
there you are.
--
Jonathan Dataweaver Lang
--
Yury V. Katkov
WikiVote! llc
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] RFC Subobjects (aka internal objects) in SMW
surrounded by curly brackets of course :)
On Mon, Oct 24, 2011 at 12:13 PM, Yury Katkov katkov.ju...@gmail.comwrote:
Hi!
Are you sure about the syntax here? Those {{{Parameters}}} surrounded by
will conflict with template parameters, won't they?
Yury
On Mon, Oct 24, 2011 at 3:48 AM, Jon Lang datawea...@gmail.com wrote:
Sorry for the late response.
Would it be reasonable to have the syntax be something like:
{{#subobject:name
| given=Jonathan
| family=Lang
| middle=LeRoy
| surname=Mr.
| {{{given}}} {{{middle}}} {{{family}}}
}}
{{#subobject:name
| given=Ranma
| family=Saotome
| {{{family}}} {{{given}}}
}}
This way, the subobject's formatting could be determined on a case-by-case
basis, and in a manner that people are used to (i.e., value on the left;
display on the right). In effect, the unnamed entry is assumed to contain
an inline template for display purposes. This saves you the trouble of
writing a new template every time you want to format a subobject
differently.
If no inline template is given, there should be a default inline template
on the property page; possibly use the property page itself *as* the
default template, and rely on the usual tricks used by template pages to
define text that should only be available when viewing the property page and
text that should only be available when making use of it as a template.
BTW: subobject is technically accurate, but needlessly long. I'd
recommend going with object instead. Granted, this is a nitpick; but
there you are.
--
Jonathan Dataweaver Lang
--
Yury V. Katkov
WikiVote! llc
--
Yury V. Katkov
WikiVote! llc
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] RFC Subobjects (aka internal objects) in SMW
Are embedded subobjects something like
{{#subobject: objname | objpropname= {{#subobject: subobjname |
subobjpropname=x}}
}}
I am mystified by the {{{given}}}...{{{family}}} parameter - how is it
used/referenced? More than one? Positional?
I don't think subobject is technically accurate, nor object for that matter, as
these technically connote behavior.
How about vector?
-Original Message-
From: Jon Lang [mailto:datawea...@gmail.com]
Sent: Sunday, October 23, 2011 3:48 PM
To: Yury Katkov
Cc: Semediawiki-user; Markus Krötzsch; Semantic MediaWiki developers
Subject: Re: [SMW-devel] RFC Subobjects (aka internal objects) in SMW
Sorry for the late response.
Would it be reasonable to have the syntax be something like:
{{#subobject:name
| given=Jonathan
| family=Lang
| middle=LeRoy
| surname=Mr.
| {{{given}}} {{{middle}}} {{{family}}}
}}
{{#subobject:name
| given=Ranma
| family=Saotome
| {{{family}}} {{{given}}}
}}
This way, the subobject's formatting could be determined on a case-by-case
basis, and in a manner that people are used to (i.e., value on the left;
display on the right). In effect, the unnamed entry is assumed to contain an
inline template for display purposes. This saves you the trouble of writing
a new template every time you want to format a subobject differently.
If no inline template is given, there should be a default inline template on
the property page; possibly use the property page itself as the default
template, and rely on the usual tricks used by template pages to define text
that should only be available when viewing the property page and text that
should only be available when making use of it as a template.
BTW: subobject is technically accurate, but needlessly long. I'd recommend
going with object instead. Granted, this is a nitpick; but there you are.
--
Jonathan Dataweaver Lang
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] RFC Subobjects (aka internal objects) in SMW
Was I talkling gibberish or was the RDF export question too hard? :)
On Thu, Oct 13, 2011 at 2:47 AM, Yury Katkov katkov.ju...@gmail.com wrote:
Hello Markus,
First of all, your alternative proposal looks much better than the
original one because of more flexibility. And praise you for the great
solution of optional naming - I hope it will be possible to implement
it!
What about RDF export and Import vocabulary features? I have really
two questions concerning both those features:
== RDFExport+RDF store question==
As far I as I can see subobjects should be turned to the blank nodes,
shouldn't they?
== Import vocabulary question ==
Is it possible to map the subobject to RDF class? That can be
extremely useful even in simple vocabularies like FOAF.
Here is an example: we have the wiki-page of Yury who has an online
account in two social networks: Facebook and Vkontakte.
===Example===
It's pretty easy to describe this fact with subobjects:
# PAGE STARTS#
Yury has [[has account::{{#subobject:
service=http://facebook.com
accountname=ganqqwerty}}
|facebook account]],
[[has account:: {{#subobject:
service=vkontakte.ru
accountname=katkov}}
|Vkontakte.ru account]]
#PAGE ENDS#
===RDF Export===
If I map has account to foaf:account, map service to uring rdf export
we will get the following (simplified)
:Yury_id_in_wiki foaf:account
:Yury_id_in_wiki#tmpnum1 .
:Yury_id_in_wiki#tmpnum1 foaf:accountServiceHomepage http://facebook.com
:Yury_id_in_wiki#tmpnum1 foaf:accountNameganqqwerty
=== Problem ===
The problem is that the property foaf:account has range
foaf:OnlineAccount. Our RDF export now is a little bit incomplete.
===Proposal===
Make it possible to assign some kind of type to the subobject and map
those types to RDFS or OWL classes. I honestly don't know how this can
be done - probably with the special attribute type or category.
The typing can be needed now only in case of RDF export. If I have a
wiki with thousands of subobjects it would always be nice to see what
kind of subobjects are there.
Anyway the subobject feature will help me to tie together a bundle of
properties in Semantic Social Profile, for example Name of the country
of living, Name of the city of living, Street, house number as well as
Geographic coordinates of the place where the user lives.
Sorry if was late fo the discussion,
Yury
On Mon, Oct 3, 2011 at 1:02 PM, Markus Krötzsch
mar...@semantic-mediawiki.org wrote:
Following up the discussions we had at SMWCon in Berlin, we have now
implemented a new feature for internal objects in SMW. This email
explains this feature and starts the discussion on some open questions
for it to become stable.
== Goal ==
Allow SMW annotations to refer to objects that have their own
property-value pairs just like wiki pages, but that do not actually have
an article in the wiki. This can be used to group property-value pairs
given on one page without requiring new auxiliary pages to be created.
It also integrates the main functionality of the Semantic Internal
Objects (SIO) extension into SMW.
== Feature Overview: Current Prototype Implementation ==
SMW now has a new subobject feature. For example, you can use the
parserfunction #subobject on some page Example page as follows:
{{#subobject:street address
| street name=Parks Road
| postcode=OX1 3QD
| city=Oxford
| country=UK
}}
This does the following:
(A) create a new subobject called Example page#_anInternalId,
(B) assign the property values for street name, ..., country to this
subobject,
(C) assign the subobject Example page#_anInternalId as a property
value for street address to Example page.
You could have achieved a similar effect as follows:
(A') create a new page called my auxiliary page,
(B') edit this new page to contain the text:
[[street name::Parks Road]]
[[postcode::OX1 3QD]]
[[city::Oxford]]
[[country::UK]]
(C') edit the page Example page to contain the text:
[[street address::my auxiliary page]]
The difference when using #subobject is that you do not create a new
auxiliary page. Instead, a subobject of Example page is created by
SMW. Also, the function #subobject does not display anything unless an
error occurred that needs to be reported.
Subobjects are named automatically by following the schema Parent page
name#_someInternalId. When subobjects are displayed to users, they thus
appear like links to sections within their parent page. This can happen,
e.g., subobjects might occur in query results (example above: {{#ask:
[[postcode::OX1 3QD]] }}). Likewise, subobjects are also addressed by
this name Parent page
Re: [SMW-devel] RFC Subobjects (aka internal objects) in SMW
Sorry for the late response.
Would it be reasonable to have the syntax be something like:
{{#subobject:name
| given=Jonathan
| family=Lang
| middle=LeRoy
| surname=Mr.
| {{{given}}} {{{middle}}} {{{family}}}
}}
{{#subobject:name
| given=Ranma
| family=Saotome
| {{{family}}} {{{given}}}
}}
This way, the subobject's formatting could be determined on a case-by-case
basis, and in a manner that people are used to (i.e., value on the left;
display on the right). In effect, the unnamed entry is assumed to contain
an inline template for display purposes. This saves you the trouble of
writing a new template every time you want to format a subobject
differently.
If no inline template is given, there should be a default inline template on
the property page; possibly use the property page itself *as* the default
template, and rely on the usual tricks used by template pages to define text
that should only be available when viewing the property page and text that
should only be available when making use of it as a template.
BTW: subobject is technically accurate, but needlessly long. I'd
recommend going with object instead. Granted, this is a nitpick; but
there you are.
--
Jonathan Dataweaver Lang
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] RFC Subobjects (aka internal objects) in SMW
Hello Markus,
First of all, your alternative proposal looks much better than the
original one because of more flexibility. And praise you for the great
solution of optional naming - I hope it will be possible to implement
it!
What about RDF export and Import vocabulary features? I have really
two questions concerning both those features:
== RDFExport+RDF store question==
As far I as I can see subobjects should be turned to the blank nodes,
shouldn't they?
== Import vocabulary question ==
Is it possible to map the subobject to RDF class? That can be
extremely useful even in simple vocabularies like FOAF.
Here is an example: we have the wiki-page of Yury who has an online
account in two social networks: Facebook and Vkontakte.
===Example===
It's pretty easy to describe this fact with subobjects:
# PAGE STARTS#
Yury has [[has account::{{#subobject:
service=http://facebook.com
accountname=ganqqwerty}}
|facebook account]],
[[has account:: {{#subobject:
service=vkontakte.ru
accountname=katkov}}
|Vkontakte.ru account]]
#PAGE ENDS#
===RDF Export===
If I map has account to foaf:account, map service to uring rdf export
we will get the following (simplified)
:Yury_id_in_wiki foaf:account
:Yury_id_in_wiki#tmpnum1 .
:Yury_id_in_wiki#tmpnum1 foaf:accountServiceHomepage http://facebook.com
:Yury_id_in_wiki#tmpnum1 foaf:accountNameganqqwerty
=== Problem ===
The problem is that the property foaf:account has range
foaf:OnlineAccount. Our RDF export now is a little bit incomplete.
===Proposal===
Make it possible to assign some kind of type to the subobject and map
those types to RDFS or OWL classes. I honestly don't know how this can
be done - probably with the special attribute type or category.
The typing can be needed now only in case of RDF export. If I have a
wiki with thousands of subobjects it would always be nice to see what
kind of subobjects are there.
Anyway the subobject feature will help me to tie together a bundle of
properties in Semantic Social Profile, for example Name of the country
of living, Name of the city of living, Street, house number as well as
Geographic coordinates of the place where the user lives.
Sorry if was late fo the discussion,
Yury
On Mon, Oct 3, 2011 at 1:02 PM, Markus Krötzsch
mar...@semantic-mediawiki.org wrote:
Following up the discussions we had at SMWCon in Berlin, we have now
implemented a new feature for internal objects in SMW. This email
explains this feature and starts the discussion on some open questions
for it to become stable.
== Goal ==
Allow SMW annotations to refer to objects that have their own
property-value pairs just like wiki pages, but that do not actually have
an article in the wiki. This can be used to group property-value pairs
given on one page without requiring new auxiliary pages to be created.
It also integrates the main functionality of the Semantic Internal
Objects (SIO) extension into SMW.
== Feature Overview: Current Prototype Implementation ==
SMW now has a new subobject feature. For example, you can use the
parserfunction #subobject on some page Example page as follows:
{{#subobject:street address
| street name=Parks Road
| postcode=OX1 3QD
| city=Oxford
| country=UK
}}
This does the following:
(A) create a new subobject called Example page#_anInternalId,
(B) assign the property values for street name, ..., country to this
subobject,
(C) assign the subobject Example page#_anInternalId as a property
value for street address to Example page.
You could have achieved a similar effect as follows:
(A') create a new page called my auxiliary page,
(B') edit this new page to contain the text:
[[street name::Parks Road]]
[[postcode::OX1 3QD]]
[[city::Oxford]]
[[country::UK]]
(C') edit the page Example page to contain the text:
[[street address::my auxiliary page]]
The difference when using #subobject is that you do not create a new
auxiliary page. Instead, a subobject of Example page is created by
SMW. Also, the function #subobject does not display anything unless an
error occurred that needs to be reported.
Subobjects are named automatically by following the schema Parent page
name#_someInternalId. When subobjects are displayed to users, they thus
appear like links to sections within their parent page. This can happen,
e.g., subobjects might occur in query results (example above: {{#ask:
[[postcode::OX1 3QD]] }}). Likewise, subobjects are also addressed by
this name Parent page name#_someInternalId in all search and export
interfaces in SMW. For example, one can view the data for one particular
subobject in Special:Browse.
In general, subobjects should work like normal pages in most SMW
interfaces. The goal of this naming is to avoid any clashes
Re: [SMW-devel] RFC Subobjects (aka internal objects) in SMW
On 05/10/11 15:02, Gregor Hagedorn wrote: Would these subobjects interfere at some stage with the support of multi-value properties or replace them? Or will they remain an additional feature like the SIOs? Multi-valued properties in SMW 1.6 are already a special kind of subobject. Both kinds of subobject work well together (i.e., one can have Type:Record properties in subobjects). It is not planned to drop record support. Sorry to ask back: you mentioned the reversal of direction compared with SIO. At least for the second case of the subobject returning its ID I am not clear how to have tabular subobjects (i.e. many subobjects of the same type). The example of a singular adress is clear. Not clear is: a literature page (= wikipage) with a hypothetical repeatable subobject figure containing of the tupel fig_number, printed_page, and caption. Can this be done with a subobject? Subobjects as such do not have a type. They are defined by their content which is given by property-value pairs. So if you need many Figures on one page, you can simply create many subobjects with the required property values. But maybe you have been asking the opposite question? If you have *one* subobject that you want to use as a value to *many* properies, then just using the #subobject function in one property assignment would not work. To solve this, we would allow subobjects to have names to be assigned to them. So you could have a subobject figure_1 and this would have a stable ID pagename#figure_1 that can be used in as many places as you like. Markus -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] RFC Subobjects (aka internal objects) in SMW
Would these subobjects interfere at some stage with the support of multi-value properties or replace them? Or will they remain an additional feature like the SIOs? Multi-valued properties in SMW 1.6 are already a special kind of subobject. Both kinds of subobject work well together (i.e., one can have Type:Record properties in subobjects). It is not planned to drop record support. Sorry to ask back: you mentioned the reversal of direction compared with SIO. At least for the second case of the subobject returning its ID I am not clear how to have tabular subobjects (i.e. many subobjects of the same type). The example of a singular adress is clear. Not clear is: a literature page (= wikipage) with a hypothetical repeatable subobject figure containing of the tupel fig_number, printed_page, and caption. Can this be done with a subobject? Gregor -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] RFC Subobjects (aka internal objects) in SMW
Overall it does 'feel tidier' to have a simple set of content pages rather than many arbitrary 'data pages', but I'm just looking for a way to quantify it. (After all, users are likely to stick to content pages if that is where your site design keeps them). Our arguments for using subobjects (presently SIOs) are: * there is not semantic forms support * raw editing of a case where a pest occurs on 10 hosts in some of 100 countries, resulting in perhaps 300 pest-host-country tupels would be impossible with separate pages. * mediawiki has no distinction between content pages and data pages (one could use a new ns though) Raw wikitext editing is a value in itself. Support in Semantic forms for data pages would enable using this method at all. But the reverse question would be: Is there an advantage to put things that have no true identifier and no independent existence on arbitrarily created mediawiki pages? Gregor -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] RFC Subobjects (aka internal objects) in SMW
On 03/10/11 19:22, Dan Bolser wrote: On 3 October 2011 16:48, Markus Krötzschmar...@semantic-mediawiki.org wrote: On 03/10/11 10:50, Dan Bolser wrote: ... Thanks Markus, Perhaps a very dumb question, but what advantages are there to using subobjects over real pages? i.e. When is it recommended to use a subobject over a regular page? (That is, disregarding peoples sensibilities over 'too many' or 'messy' pages, which are purely subjective). Currently, the main reason I use SIO is because they work so nicely with multi-instance templates in SF, but this is a SF limitation rather than a decision driven by 'data design' or modelling considerations. (One form can only edit one page at a time). Probably this was discussed at SMWCon, but if there is no other permanent record you can point me at, it would be great if you could put the key points here. There was not too much of a discussion about the general motivation. Subobjects are really just like pages as far as the structure of the stored data is concerned. However, there really are cases where the creation of a page would seem inappropriate, e.g., when the subobject merely groups two values. For example, you would not want pages for 300g butter or margarine. In other cases, the policy of the wiki might be to not have individual pages for some item, even if it could be argued for as an individual subject (like my address example). Subobjects let you handle such situations in a more flexible way. I definately see the advantage when it comes to linking specific quantities with types, as quantities are infinitely variable, you wouldn't wan't a page for every specific permutation. Now I'm thinking about having [[butter::600g]] ... I guess it's good to have more than one way to do things. Overall it does 'feel tidier' to have a simple set of content pages rather than many arbitrary 'data pages', but I'm just looking for a way to quantify it. (After all, users are likely to stick to content pages if that is where your site design keeps them). I guess two suggested guidelines come to mind: 1) The subobject should be strictly dependent on its parent object, i.e. it only makes sense to store the data for that subobject on the parent page, and the data shouldn't be duplicated elsewhere (very often). 2) There should never be a need to add free text or otherwise discuss the subobject separately from the parent page (which stems from point 1 I guess). Yes, these are possible guidelines. In the end, I would expect the policies of each wiki to be different there (compare the Wikipedias' various policies about the articles that one should/shouldn't have). An advantage of data objects is that they lead to the same data structure as the creation of new pages. So both approaches are fully compatible in queries and one does not have to decide for one or the other approach consistently to make things work. One could even have a mixed approach where some subobjects are promoted to standalone pages when there is sufficient interest to write about them. Regards, Markus -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] RFC Subobjects (aka internal objects) in SMW
On 03/10/11 22:58, John McClure wrote:
Markus,
#subobject is great to hear about, though I look at
http://semantic-mediawiki.org/wiki/Special:Version and I don't see it yet
listed as a parser function; is there a schedule in mind for public testing?
And I'm not understanding how records are still useful given #subobject's
availability -- are records to become a backwards-compatibility thing?
Records are an independent feature that is not under discussion right
now. The fact that records largely are based on the same internal
mechanisms as subobects reduces the cost of keeping them in the code.
Anyway to give you a feel for my own perspective, I'm working to allow users
via forms to associate a page with attributes possibly annotated with, for
instance, provenance info. I store these attribute annotations in Dublin
Core properties within an attribute object attached to the page. Of course
users are not constrained at the same time from annotating a page's content
directly. I then had a choice between implementing the attribute objects as
records or as sio's - I chose SIO primarily because it preserves basic #ask
syntax, thank you Yaron, which can be used in compound queries.
Your note says to me though that you're reimplementing records to be
amenable to basic ask syntax (plus other goodies you mention).
This should already be the case. Records are stored like subobjects with
a fixed list of properties. So they can be queried in the same way too.
It'd help my
understanding alot to contrast use cases for various queries that retrieve
* all subobjects in the wiki with a particular propertyor value
There is no distinction between subobjects and normal pages. You can
find all things that have a particular property or property value but
you cannot filter this to only get subobjects (and no pages that match
the query).
* all pages in the wiki with a subobject having a particular propertyor
value
* the container subobject for a given nested subobject
* the container page for a given subobject or a given nested subobject
These are all easy to do, just as one would do the same queries for
pages. Again, there is no distinction between pages and subobjects, so
there is no difference between the last two queries. Also note that,
with the currently implemented parserfunction, you cannot create nested
subobjects for lack of syntax.
Other notes:
# re:Browse
* can subobjects be shown (in a subtable) on special:browse/Example_page,
not separate browse pages for each subobject
Possible, but this would need a new interface. Special:Browse is not
suitable for displaying nested property values (otherwise, one could do
a similar thing for arbitrary pages, not just for subobjects).
# re:#subobject syntax
* I definitely prefer {{#set:pageprop={{#subobject:
objname|prop1=val1|...
Yes, I also find this more logical.
* I'd like to store a formatting template name in the subobject too (see
below), eg
{{#set:pageprop={{#subobject: objname|templatename|prop1=val1|...
SMW does not support this since one can already achieve the same thing
by using a formatting template instead of #subobject, and use #subobject
within the template. We would like to leave formatting to MediaWiki and
keep the task of SMW to be data management.
# re:subobject annotations
* I much would like the object to preserve implicit formatting provided by a
modified syntax for instance:
[[[address::[[bldgnbr::123]] [[street name::Parks Road]], [[city::Oxford]]
[[postcode::OX1 3QD]] [[country::UK]] ]]]
which would be output by {{#show:{{FULLPAGENAME}}|?address=}}
This is not possible with SMW unless one would change the data model in
a quite fundamental fashion. Data in SMW is independent of formatting
and of the order in which it was given on a page. This basic data model
is the same for subobjects. Also, the above syntax with nested [[ ]]
does not work in SMW since we are lacking an efficient way to parse this
(there is a switch to enable this but this does not work with longer
pages unless the Perl regexp library in PHP became a lot more efficient
since I last tested it).
However, you can store formatted strings of wikitext like address in
your above example by using a property of Type:Text in #set. Using a
template, one could therefore store both the formatted address and the
subobject that is based on this data.
Another solution would be to create pages with the formatted content and
to transclude them whenever the original formatting is desired.
# re: ask templates
* can the param value for a subobject property optionally be its name OR its
formatted OR unformatted content
I don't think I understand what you mean here. But maybe this is already
moot given that formatting is not part of the stored data?
Bottom line, it's really good to see SIO functionality moved into core SMW.
Yes, I have been convinced that many users want this.
Regards,
Markus
Re: [SMW-devel] RFC Subobjects (aka internal objects) in SMW
On 3 October 2011 10:02, Markus Krötzsch mar...@semantic-mediawiki.org wrote:
Following up the discussions we had at SMWCon in Berlin, we have now
implemented a new feature for internal objects in SMW. This email
explains this feature and starts the discussion on some open questions
for it to become stable.
== Goal ==
Allow SMW annotations to refer to objects that have their own
property-value pairs just like wiki pages, but that do not actually have
an article in the wiki. This can be used to group property-value pairs
given on one page without requiring new auxiliary pages to be created.
It also integrates the main functionality of the Semantic Internal
Objects (SIO) extension into SMW.
== Feature Overview: Current Prototype Implementation ==
SMW now has a new subobject feature. For example, you can use the
parserfunction #subobject on some page Example page as follows:
{{#subobject:street address
| street name=Parks Road
| postcode=OX1 3QD
| city=Oxford
| country=UK
}}
This does the following:
(A) create a new subobject called Example page#_anInternalId,
(B) assign the property values for street name, ..., country to this
subobject,
(C) assign the subobject Example page#_anInternalId as a property
value for street address to Example page.
You could have achieved a similar effect as follows:
(A') create a new page called my auxiliary page,
(B') edit this new page to contain the text:
[[street name::Parks Road]]
[[postcode::OX1 3QD]]
[[city::Oxford]]
[[country::UK]]
(C') edit the page Example page to contain the text:
[[street address::my auxiliary page]]
The difference when using #subobject is that you do not create a new
auxiliary page. Instead, a subobject of Example page is created by
SMW. Also, the function #subobject does not display anything unless an
error occurred that needs to be reported.
Subobjects are named automatically by following the schema Parent page
name#_someInternalId. When subobjects are displayed to users, they thus
appear like links to sections within their parent page. This can happen,
e.g., subobjects might occur in query results (example above: {{#ask:
[[postcode::OX1 3QD]] }}). Likewise, subobjects are also addressed by
this name Parent page name#_someInternalId in all search and export
interfaces in SMW. For example, one can view the data for one particular
subobject in Special:Browse.
In general, subobjects should work like normal pages in most SMW
interfaces. The goal of this naming is to avoid any clashes with real
pages and with real sections in real pages while still allowing the same
methods to be used.
The feature can be tested in the current SVN version but it is still
unstable and might change significantly (read on).
== Relation to Semantic Internal Objects ==
The feature is very similar to the SIO extension. The difference is that
in SIO, the main property (street address above) points from the
subobject to the parent page. In the above example, street address
really means has street address while in SIO it would be used like is
street address of.
The other difference is that subobjects work with both SQL and RDF
stores, are exported in RDF and are compatible with interfaces like
Special:Browse.
== Alternative Proposal ==
Instead of having a parser function that creates a subobject and assigns
it to a property as a value, one could also have a parser function that
only does the first thing and that *returns* a subobject for later use.
This would require some further changes but it might be more elegant.
For example, a call like
{{#subobject: street name=Parks Road | postcode=OX1 3QD| city=Oxford }}
would just create such an object and return its name (e.g.
Example_page#_someId). Then one could use this name as a value to
other properties, e.g.:
[[street address::{{#subobject: street name=Parks Road
| postcode=OX1 3QD
| city=Oxford
}}]]
One advantage of this is that one could arbitrarily nest subobjects,
i.e. use subobjects as property values when declaring other subobjects
(SMW can already do this, just the input syntax does not support it).
Another advantage is that subobjects could (optionally) be named instead
of using the name generated by SMW now. For example, one could have
{{#subobject:department_address
|street name=Parks Road | postcode=OX1 3QD| city=Oxford }}
to create a subobject called Example page#department_address which
could be used in other annotations on *any* page (this is already
possible with subobjects now, but since their names are generated by SMW
they might not be stable over time). In this case, it might be less
desirable to return the name of the subobject.
Overall, this alternative approach would allow subobjects to be used as
first-class citizens of the SMW data space instead of viewing them as
auxiliary objects for encoding compound property values.
== Request for Comments ==
Feedback is
Re: [SMW-devel] RFC Subobjects (aka internal objects) in SMW
Would these subobjects interfere at some stage with the support of
multi-value properties or replace them? Or will they remain an additional
feature like the SIOs?
Gu
On Mon, 03 Oct 2011 10:02:32 +0100, Markus Krötzsch
mar...@semantic-mediawiki.org wrote:
Following up the discussions we had at SMWCon in Berlin, we have now
implemented a new feature for internal objects in SMW. This email
explains this feature and starts the discussion on some open questions
for it to become stable.
== Goal ==
Allow SMW annotations to refer to objects that have their own
property-value pairs just like wiki pages, but that do not actually have
an article in the wiki. This can be used to group property-value pairs
given on one page without requiring new auxiliary pages to be created.
It also integrates the main functionality of the Semantic Internal
Objects (SIO) extension into SMW.
== Feature Overview: Current Prototype Implementation ==
SMW now has a new subobject feature. For example, you can use the
parserfunction #subobject on some page Example page as follows:
{{#subobject:street address
| street name=Parks Road
| postcode=OX1 3QD
| city=Oxford
| country=UK
}}
This does the following:
(A) create a new subobject called Example page#_anInternalId,
(B) assign the property values for street name, ..., country to this
subobject,
(C) assign the subobject Example page#_anInternalId as a property
value for street address to Example page.
You could have achieved a similar effect as follows:
(A') create a new page called my auxiliary page,
(B') edit this new page to contain the text:
[[street name::Parks Road]]
[[postcode::OX1 3QD]]
[[city::Oxford]]
[[country::UK]]
(C') edit the page Example page to contain the text:
[[street address::my auxiliary page]]
The difference when using #subobject is that you do not create a new
auxiliary page. Instead, a subobject of Example page is created by
SMW. Also, the function #subobject does not display anything unless an
error occurred that needs to be reported.
Subobjects are named automatically by following the schema Parent page
name#_someInternalId. When subobjects are displayed to users, they thus
appear like links to sections within their parent page. This can happen,
e.g., subobjects might occur in query results (example above: {{#ask:
[[postcode::OX1 3QD]] }}). Likewise, subobjects are also addressed by
this name Parent page name#_someInternalId in all search and export
interfaces in SMW. For example, one can view the data for one particular
subobject in Special:Browse.
In general, subobjects should work like normal pages in most SMW
interfaces. The goal of this naming is to avoid any clashes with real
pages and with real sections in real pages while still allowing the same
methods to be used.
The feature can be tested in the current SVN version but it is still
unstable and might change significantly (read on).
== Relation to Semantic Internal Objects ==
The feature is very similar to the SIO extension. The difference is that
in SIO, the main property (street address above) points from the
subobject to the parent page. In the above example, street address
really means has street address while in SIO it would be used like is
street address of.
The other difference is that subobjects work with both SQL and RDF
stores, are exported in RDF and are compatible with interfaces like
Special:Browse.
== Alternative Proposal ==
Instead of having a parser function that creates a subobject and assigns
it to a property as a value, one could also have a parser function that
only does the first thing and that *returns* a subobject for later use.
This would require some further changes but it might be more elegant.
For example, a call like
{{#subobject: street name=Parks Road | postcode=OX1 3QD| city=Oxford }}
would just create such an object and return its name (e.g.
Example_page#_someId). Then one could use this name as a value to
other properties, e.g.:
[[street address::{{#subobject: street name=Parks Road
| postcode=OX1 3QD
| city=Oxford
}}]]
One advantage of this is that one could arbitrarily nest subobjects,
i.e. use subobjects as property values when declaring other subobjects
(SMW can already do this, just the input syntax does not support it).
Another advantage is that subobjects could (optionally) be named instead
of using the name generated by SMW now. For example, one could have
{{#subobject:department_address
|street name=Parks Road | postcode=OX1 3QD| city=Oxford }}
to create a subobject called Example page#department_address which
could be used in other annotations on *any* page (this is already
possible with subobjects now, but since their names are generated by SMW
they might not be stable over time). In this case, it might be less
desirable to return the name of
Re: [SMW-devel] RFC Subobjects (aka internal objects) in SMW
On 03/10/11 10:50, Dan Bolser wrote: ... Thanks Markus, Perhaps a very dumb question, but what advantages are there to using subobjects over real pages? i.e. When is it recommended to use a subobject over a regular page? (That is, disregarding peoples sensibilities over 'too many' or 'messy' pages, which are purely subjective). Currently, the main reason I use SIO is because they work so nicely with multi-instance templates in SF, but this is a SF limitation rather than a decision driven by 'data design' or modelling considerations. (One form can only edit one page at a time). Probably this was discussed at SMWCon, but if there is no other permanent record you can point me at, it would be great if you could put the key points here. There was not too much of a discussion about the general motivation. Subobjects are really just like pages as far as the structure of the stored data is concerned. However, there really are cases where the creation of a page would seem inappropriate, e.g., when the subobject merely groups two values. For example, you would not want pages for 300g butter or margarine. In other cases, the policy of the wiki might be to not have individual pages for some item, even if it could be argued for as an individual subject (like my address example). Subobjects let you handle such situations in a more flexible way. Regards, Markus -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] RFC Subobjects (aka internal objects) in SMW
On 03/10/11 11:48, zehetner wrote:
Would these subobjects interfere at some stage with the support of
multi-value properties or replace them? Or will they remain an additional
feature like the SIOs?
Multi-valued properties in SMW 1.6 are already a special kind of
subobject. Both kinds of subobject work well together (i.e., one can
have Type:Record properties in subobjects). It is not planned to drop
record support.
Markus
On Mon, 03 Oct 2011 10:02:32 +0100, Markus Krötzsch
mar...@semantic-mediawiki.org wrote:
Following up the discussions we had at SMWCon in Berlin, we have now
implemented a new feature for internal objects in SMW. This email
explains this feature and starts the discussion on some open questions
for it to become stable.
== Goal ==
Allow SMW annotations to refer to objects that have their own
property-value pairs just like wiki pages, but that do not actually have
an article in the wiki. This can be used to group property-value pairs
given on one page without requiring new auxiliary pages to be created.
It also integrates the main functionality of the Semantic Internal
Objects (SIO) extension into SMW.
== Feature Overview: Current Prototype Implementation ==
SMW now has a new subobject feature. For example, you can use the
parserfunction #subobject on some page Example page as follows:
{{#subobject:street address
| street name=Parks Road
| postcode=OX1 3QD
| city=Oxford
| country=UK
}}
This does the following:
(A) create a new subobject called Example page#_anInternalId,
(B) assign the property values for street name, ..., country to this
subobject,
(C) assign the subobject Example page#_anInternalId as a property
value for street address to Example page.
You could have achieved a similar effect as follows:
(A') create a new page called my auxiliary page,
(B') edit this new page to contain the text:
[[street name::Parks Road]]
[[postcode::OX1 3QD]]
[[city::Oxford]]
[[country::UK]]
(C') edit the page Example page to contain the text:
[[street address::my auxiliary page]]
The difference when using #subobject is that you do not create a new
auxiliary page. Instead, a subobject of Example page is created by
SMW. Also, the function #subobject does not display anything unless an
error occurred that needs to be reported.
Subobjects are named automatically by following the schema Parent page
name#_someInternalId. When subobjects are displayed to users, they thus
appear like links to sections within their parent page. This can happen,
e.g., subobjects might occur in query results (example above: {{#ask:
[[postcode::OX1 3QD]] }}). Likewise, subobjects are also addressed by
this name Parent page name#_someInternalId in all search and export
interfaces in SMW. For example, one can view the data for one particular
subobject in Special:Browse.
In general, subobjects should work like normal pages in most SMW
interfaces. The goal of this naming is to avoid any clashes with real
pages and with real sections in real pages while still allowing the same
methods to be used.
The feature can be tested in the current SVN version but it is still
unstable and might change significantly (read on).
== Relation to Semantic Internal Objects ==
The feature is very similar to the SIO extension. The difference is that
in SIO, the main property (street address above) points from the
subobject to the parent page. In the above example, street address
really means has street address while in SIO it would be used like is
street address of.
The other difference is that subobjects work with both SQL and RDF
stores, are exported in RDF and are compatible with interfaces like
Special:Browse.
== Alternative Proposal ==
Instead of having a parser function that creates a subobject and assigns
it to a property as a value, one could also have a parser function that
only does the first thing and that *returns* a subobject for later use.
This would require some further changes but it might be more elegant.
For example, a call like
{{#subobject: street name=Parks Road | postcode=OX1 3QD| city=Oxford }}
would just create such an object and return its name (e.g.
Example_page#_someId). Then one could use this name as a value to
other properties, e.g.:
[[street address::{{#subobject: street name=Parks Road
| postcode=OX1 3QD
| city=Oxford
}}]]
One advantage of this is that one could arbitrarily nest subobjects,
i.e. use subobjects as property values when declaring other subobjects
(SMW can already do this, just the input syntax does not support it).
Another advantage is that subobjects could (optionally) be named instead
of using the name generated by SMW now. For example, one could have
{{#subobject:department_address
|street name=Parks Road | postcode=OX1 3QD| city=Oxford }}
to create a subobject called Example page#department_address which
could be used in other
Re: [SMW-devel] RFC Subobjects (aka internal objects) in SMW
On 3 October 2011 16:48, Markus Krötzsch mar...@semantic-mediawiki.org wrote: On 03/10/11 10:50, Dan Bolser wrote: ... Thanks Markus, Perhaps a very dumb question, but what advantages are there to using subobjects over real pages? i.e. When is it recommended to use a subobject over a regular page? (That is, disregarding peoples sensibilities over 'too many' or 'messy' pages, which are purely subjective). Currently, the main reason I use SIO is because they work so nicely with multi-instance templates in SF, but this is a SF limitation rather than a decision driven by 'data design' or modelling considerations. (One form can only edit one page at a time). Probably this was discussed at SMWCon, but if there is no other permanent record you can point me at, it would be great if you could put the key points here. There was not too much of a discussion about the general motivation. Subobjects are really just like pages as far as the structure of the stored data is concerned. However, there really are cases where the creation of a page would seem inappropriate, e.g., when the subobject merely groups two values. For example, you would not want pages for 300g butter or margarine. In other cases, the policy of the wiki might be to not have individual pages for some item, even if it could be argued for as an individual subject (like my address example). Subobjects let you handle such situations in a more flexible way. I definately see the advantage when it comes to linking specific quantities with types, as quantities are infinitely variable, you wouldn't wan't a page for every specific permutation. Now I'm thinking about having [[butter::600g]] ... I guess it's good to have more than one way to do things. Overall it does 'feel tidier' to have a simple set of content pages rather than many arbitrary 'data pages', but I'm just looking for a way to quantify it. (After all, users are likely to stick to content pages if that is where your site design keeps them). I guess two suggested guidelines come to mind: 1) The subobject should be strictly dependent on its parent object, i.e. it only makes sense to store the data for that subobject on the parent page, and the data shouldn't be duplicated elsewhere (very often). 2) There should never be a need to add free text or otherwise discuss the subobject separately from the parent page (which stems from point 1 I guess). Cheers, Dan. Regards, Markus -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
