Re: [SMW-devel] [Semediawiki-user] RFC Subobjects (aka "internal objects") in SMW
Markus,
Thanks for taking this on. I talked myself out of both solutions three
times, just in the span of writing a response. This is a tough problem, I
think. So, what niggles at me is whether it is reasonable to argue for
solution 1 or solution 2 based on whether the "something" in the middle is
real or abstract?
I mean, you gave an example using an address but Yaron usually talks about
N-ary relations using a recipe analogy. An address is a real thing that
exists irregardless of where it's mentioned in the wiki and the address has
parts (which also have some sort of relatedness in the real world). I think
that in the case of the address, it would be OK to make a wiki page for that
data--12 Downing Street is relevant even if the PM moves to 14 Downing St,
because it's still a real place. It's relevant because some person or
business occupies (or "Has") that address.
Whereas the recipe example (quantity+ingredient) is more of an adverb+verb
combination and they are only relevant to each other in the specific
instance (and completely meaningless outside of the recipe context). "500g
of flour" would never deserve its own wiki page.
I think solution 1 suits the real case better but, would work for both
cases. Solution 2 really only works for the abstract case. However, since
the real case can be solved by making a wiki page but the abstract case
cannot, maybe solution 2 is the preferable option. That way,people won't go
around NOT making wiki pages about things that really ought to have pages
made about them.
-Clarence
On Mon, Oct 3, 2011 at 5:02 AM, 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 Proposa
Re: [SMW-devel] RFC Subobjects (aka "internal objects") in SMW
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?
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). It'd help my
understanding alot to contrast use cases for various queries that retrieve
* all subobjects in the wiki with a particular property &or value
* all pages in the wiki with a subobject having a particular property &or
value
* the container subobject for a given nested subobject
* the container page for a given subobject or a given nested subobject
Other notes:
# re:Browse
* can subobjects be shown (in a subtable) on special:browse/Example_page,
not separate browse pages for each subobject
# re:#subobject syntax
* I definitely prefer {{#set:pageprop={{#subobject:
objname|prop1=val1|...
* I'd like to store a formatting template name in the subobject too (see
below), eg
{{#set:pageprop={{#subobject: objname|templatename|prop1=val1|...
# 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=}}
# re: ask templates
* can the param value for a subobject property optionally be its name OR its
formatted OR unformatted content
Bottom line, it's really good to see SIO functionality moved into core SMW.
Thanks, John
--
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 3 October 2011 16:48, Markus Krötzsch 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
Re: [SMW-devel] Is SMW 1.6.2 released?
On 29/09/11 13:05, Toni Hermoso Pulido wrote: > Hello, > > I was checking http://semantic-mediawiki.org/ and current version > number is 1.6.2, but it doesn't appear here: > http://sourceforge.net/projects/semediawiki/files/semediawiki/ SMW 1.6.2 provides a few bugfixes that we wanted to make available, but it also did some internal changes in parameter handling that have been found to cause new incompatibilities. Therefore, we decided to discourage the use of SMW 1.6.2 for now and keep SMW 1.6.1 as the main download package. We plan to release an update sometime soon that completes the transition to the new parameter handling system (remaining incompatible where it is now, but in a decisive 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
> 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 nam
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
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
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
Re: [SMW-devel] RFC Subobjects (aka "internal objects") in SMW
On 3 October 2011 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 "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 s
[SMW-devel] RFC Subobjects (aka "internal objects") in SMW
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 welcome. The first question is which approach to subobjects
should eventually
Re: [SMW-devel] inference on printout statements
After reading all the info in that bug report, and all the info in the
'duplicate' bugs, I'm confused about what subproperties *should* do,
and what they currently do and don't do.
Could someone please summarise what is expected, currently implemented
and currently broken? I think such a table of features could be
maintained here:
http://semantic-mediawiki.org/wiki/Property:Subproperty_of
I'll start work on it when I have some time, but I've only just
started to use subproperties, so someone with more direct experience
should be able to do this much faster than me (I hope).
For the record, my opinion is that we have enough syntax already.
Anyone using subproperties should be aware of the implications, and
shouldn't need special query syntax to ask for 'direct' vs. 'indirect'
values of a superproperty. If they wan't only the direct values, they
shouldn't use subproperties... IMHO.
Cheers,
Dan.
On 2 October 2011 21:17, Yury Katkov wrote:
> It seems that it's a planned feature
> Everyone who is interested in this new feature, please vote for this
> issue in Bugzilla:
>
> https://bugzilla.wikimedia.org/show_bug.cgi?id=12822
>
> On Sun, Oct 2, 2011 at 9:34 PM, Dan Bolser wrote:
>> On 1 October 2011 19:07, Yury Katkov wrote:
>>> Hi everyone, developers and users!
>>>
>>> ==Problem==
>>>
>>> The printout statements are not currently engaged in inference in
>>> Semantic MediaWiki.
>>> For example if I have a page Moskow with a property [[is capital
>>> of::Russia]], which is a subproperty of the property [[located in]].
>>> If I construct the following query
>>>
>>> {{#ask:
>>> [[is capital of::Russia]]
>>> | ?located in
>>> }}
>>>
>>> there will be nothing in a located in column.
>>> == Questions ==
>>>
>>> # are there any plans to add inference in printout statements?
>>> # how hard is this task?
>>> # how many people besides myself are in need of this feature? The
>>> possible workarounds just seem wrong...
>>
>> I agree that the above query should return "Moscow, Moscow", according
>> to the definition of subproperties [1].
>>
>> To the extent that I expect things like "autocomplete on property =
>> located in" to return 'Moscow' as one of the possibilities in SF
>> (currently fails, but is this related?), then yes, I need features
>> like this.
>>
>>
>> Cheers,
>> Dan.
>>
>> [1] http://semantic-mediawiki.org/wiki/Property:Subproperty_of
>>
>>> Sincerely yours,
>>> --
>>> Yury V. Katkov
>>> WikiVote! llc
>>>
>>> --
>>> 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
>>>
>>
>
>
>
> --
> Yury V. Katkov
> WikiVote! llc
>
--
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
