Re: [SMW-devel] RFC Subobjects (aka "internal objects") in SMW

[Jon Lang]

OK: going back to basics here, as I may have jumped to some conclusions
and/or missed some details:

On Mon, Oct 3, 2011 at 2:02 AM, Markus Krötzsch <
mar...@semantic-mediawiki.org> wrote:

> == 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]]
>

In the latter case, you may have Property Pages for street name, postcode,
city, and country, and these Property Pages potentially have [[has type]]
properties of their own, letting you (for example) specify that "city" is a
page reference whereas "street name" is text.  I'm assuming that the same
holds true for the subobject?  That is, for each label=value pair in the
subobject, the label is the name of a property page that provides
information about how to interpret the value.

As well, there's potentially a property page for "street address".  In the
latter case, it [[has type::Page]]; what does it have in the former case?
I'm guessing something like [[has type::subobject]].

Question: can you define a "property subobject" instead of a property page
for a subobject's property/value pairs?  That is, on Property:street
address, can you say something like:

[[has value::subobject]]
{{#subobject: street name | has type=Text}}
{{#subobject: postcode | has type=Text}}
{{#subobject: city | has type=Page}}
{{#subobject: country | has type=Page}}

...and thus define the types of the property values that appear in a
"street address" subobject all in one place?

-- 
Jonathan "Dataweaver" Lang
--
RSA® Conference 2012
Save $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

[Jonathan Lang]

Markus Krötzsch wrote:

> 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.

Fair enough.  That said, it's a data management extension to an application 
that is centered on human readability, which means that data 
formatting/visualization carries a higher priority than it would for a strictly 
data management application.  That said:

> 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.

This is a very true point.  Then again, creating a spinoff of #subobject 
strictly to add an optional visualization feature to it feels a little awkward. 
 Still, it would be a good learning experience.  

Could we at least get a positional parameter for #subobject that simply 
replaces the data?  No "inline template parameters" or anything fancy; just a 
straight "display this wiki code instead of what you'd normally show": 

{{#subobject name
  | personal=Jonathan
  | nickname=Jon
  | family=Lang
  | title=Mr.
  | Jon Lang
}}

It's not as versatile as I'd like; but at least it lets the page author 
seamlessly integrate the machine-readable data into the human-readable text of 
the page without having to create a (single-use) template page to format it the 
way he wants.  
--
RSA® Conference 2012
Save $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

[Markus Krötzsch]

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

--
RSA® Conference 2012
Save $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

[Jonathan Lang]

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.  
--
RSA® Conference 2012
Save $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

[Markus Krötzsch]

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™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. 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

[Markus Krötzsch]

On 30/10/11 17:53, John McClure wrote:
> great Markus. So all objects are always '#set' as a value of some property
> for a page at all times. Is this value removed from 'has subobject' when it
> is assigned to its actual property for the page, or when it is assigned as a
> property value for an object of the page?

No, it is always there.

Regards,

Markus


>
> -Original Message-
> From: Markus Krötzsch [mailto:mar...@semantic-mediawiki.org]
> Sent: Sunday, October 30, 2011 4:02 AM
>
> 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
>
>


--
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. 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

[John McClure]

great Markus. So all objects are always '#set' as a value of some property
for a page at all times. Is this value removed from 'has subobject' when it
is assigned to its actual property for the page, or when it is assigned as a
property value for an object of the page?
Thanks - john

-Original Message-
From: Markus Krötzsch [mailto:mar...@semantic-mediawiki.org]
Sent: Sunday, October 30, 2011 4:02 AM

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


--
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. 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

[Markus Krötzsch]

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™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. 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

[Markus Krötzsch]

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™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. 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

[Markus Krötzsch]

On 23/10/11 10:36, Yury Katkov wrote:
> Was I talkling gibberish or was the RDF export question too hard? :)

The latter ;-) I have not had the time yet to answer this yet. Below is 
my reply.

>
> On Thu, Oct 13, 2011 at 2:47 AM, Yury Katkov  > 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!

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.

>
> 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?

Not really. They are named and they can be addressed by that name from 
all over the wiki. This includes RDF export functions: you can export 
the data for one subobject using its name. With blank nodes, this would 
not work. Even the anonymous subobjects (currently used for Type:Record) 
are simply subobjects with auto-generated names, not really unnamed ones.

>
> == 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
> 
> :Yury_id_in_wiki#tmpnum1 foaf:accountName "ganqqwerty"
> === 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.

If I understand correctly, you suggest to have a mechanism to associate 
a class (category) with subobjects. This is indeed not possible now 
since Categories are a MediaWiki feature that cannot be used with 
subobjects. The issue here is not even in doing this automatically for 
certain cases, but in doing it at all.

In your example, this is not really necessary. As you rightly say, there 
already is a range declaration on foaf:account. The meaning of range in 
RDFS is: even if you do not specify a class, it will be inferred that 
the object is in the range class if it is used as a value to the 
property. So your example actually illustrates a case where an 
additional class assignment would not add any information to the data 
(in the view of an RDFS processor that is aware of the FOAF ontology; of 
course an RDF processor that does not know what rdfs:range means would 
not be able to use this information).

It would still be nice to allow categorization of subobjects, but I 
don't see now how to make this work properly with the current 
category=class approach in SMW without introducing discrepancies between 
SMW category/class information and MediaWiki category information.


Markus


--
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. Discover just how easy and simple 
it is! http://p.sf.net/sfu/android-dev2dev

Re: [SMW-devel] RFC Subobjects (aka "internal objects") in SMW

[Markus Krötzsch]

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

Re: [SMW-devel] RFC Subobjects (aka "internal objects") in SMW

[Jon Lang]

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

[John McClure]

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.

-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


--
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

[John McClure]

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

[Yury Katkov]

surrounded by curly brackets of course :)

On Mon, Oct 24, 2011 at 12:13 PM, Yury Katkov wrote:

> 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  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

[Yury Katkov]

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  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

[Jon Lang]

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

[Yury Katkov]

Was I talkling gibberish or was the RDF export question too hard? :)

On Thu, Oct 13, 2011 at 2:47 AM, Yury Katkov  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  >
> :Yury_id_in_wiki#tmpnum1 foaf:accountName"ganqqwerty"
> === 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
>  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., sub

Re: [SMW-devel] RFC Subobjects (aka "internal objects") in SMW

[Yury Katkov]

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 
:Yury_id_in_wiki#tmpnum1 foaf:accountName"ganqqwerty"
=== 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
 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 pag

Re: [SMW-devel] RFC Subobjects (aka "internal objects") in SMW

[Markus Krötzsch]

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

[Gregor Hagedorn]

> 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

[Gregor Hagedorn]

>> 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

[Markus Krötzsch]

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 property&or 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 property&or
> 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 th

Re: [SMW-devel] RFC Subobjects (aka "internal objects") in SMW

[Markus Krötzsch]

On 03/10/11 19:22, Dan Bolser wrote:
> 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).

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

[John McClure]

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

[Dan Bolser]

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] RFC Subobjects (aka "internal objects") in SMW

[Markus Krötzsch]

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

[Markus Krötzsch]

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

[zehetner]

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

[Dan Bolser]

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

[Markus Krötzsch]

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