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

[James Hong Kong]

Hi,

Thanks but we rather would try to avoid having any heavy programming
logic within templates. Your proposal might be a viable solution for
certain type of tasks but since this wouldn't be a native
implementation it will influence performance and require additional
logic within a template.

Cheers

On Wed, Nov 30, 2011 at 5:37 AM, Van de Bugger  wrote:
> Try to use variables, e. g.:
>
> 
> {{  #vardefine: #
>    |   {{  #expr: {{ #var: # | 0 }} + 1
>        }}
> }}
> {{  #subobject: {{ #var: # }}
>    |   property = value...
> }}
>
> 
> {{ X | ... }} 
> {{ X | ... }} 
> etc.
>
>
> On Tue, 2011-11-29 at 23:17 +0900, James Hong Kong wrote:
>> Hi Markus,
>>
>> While testing  #subobjects on MW 1.18 (on SMW 1.7alpha), we started to
>> convert our SIO objects into SMW-subobjects (we hope that with this we
>> can avoid double entries that now and then appear due to problems in
>> SIO ). One advantage of SIO is that its assigns individual object-ids
>> (#1... etc.) but for #subobjects we have to state explicitly the
>> object id, considering only one or two objects then this procedure
>> just works fine. For a larger set of objects per page (some of our
>> pages contain a data set of 100-200 numerical statistics)  we would
>> wish #subobject would identify that no object identifier is present
>> and than it would automatically assign a number (such as #1 ) so any
>> object can be identified individually.
>>
>> Cheers,
>>
>> MWJames
>>
>> On Mon, Oct 3, 2011 at 6: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.
>> >
>> >
>>
>> ...
>>
>> --
>> 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. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> ___
>> Semediawiki-user mailing list
>> semediawiki-u...@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
>
>

--
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. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel

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

[James Hong Kong]

Hi Markus,

While testing  #subobjects on MW 1.18 (on SMW 1.7alpha), we started to
convert our SIO objects into SMW-subobjects (we hope that with this we
can avoid double entries that now and then appear due to problems in
SIO ). One advantage of SIO is that its assigns individual object-ids
(#1... etc.) but for #subobjects we have to state explicitly the
object id, considering only one or two objects then this procedure
just works fine. For a larger set of objects per page (some of our
pages contain a data set of 100-200 numerical statistics)  we would
wish #subobject would identify that no object identifier is present
and than it would automatically assign a number (such as #1 ) so any
object can be identified individually.

Cheers,

MWJames

On Mon, Oct 3, 2011 at 6: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.
>
>

...

--
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. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel

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

[Stephan Gambke]

Am 02.11.2011 00:17, schrieb Jon Lang:
> Stephan Gambke wrote:
> 
> Am 01.11.2011 20:11, schrieb Jon Lang:
> > Thank you; this gives me a means of illustrating my point.
> >
> > Take the example of my name as given by Marcus:
> >
> > Jon Lang{{#subobject name|personal=Jonathan|nickname=Jon|family=Lang}}
> >
> > In order to set up a Semantic Glossary that uses Jon Lang as the term
> > and information from {{#subobject
> > name|personal=Jonathan|nickname=Jon|family=Lang}}to build a
> definition,
> > you would need a person to intervene, as there are no semantics
> > connecting the former to the latter: human intuition can make the
> > connection, but a machine lacks the necessary tagging to do so.
> > Contrast this with:
> >
> > {{#subobject name|personal=Jonathan|nickname=Jon|family=Lang|Jon
> Lang}}
> >
> > In this case, it would be trivial for a machine to deduce that Jon
> Lang
> > should be the term associated with the definition that's built
> from the
> > rest of the #subobject.
> 
> The semantic object you are assigning values to here is derived from
> 'name', e.g. if the above parser function call were to appear on the
> page 'Jon Lang' the call would result in a semantic object 'Jon
> Lang#name'. 
> 
> 
> So you're creating a glossary entry based off of the properties of a
> page.  I was talking about creating a glossary entry based off of the
> values of a subobject.  That is, the information in question doesn't
> appear on a page called "Jon Lang"; it appears on a page called "SMW
> participants".  For the sake of this illustration, my first, middle, and
> last names aren't specified as page properties anywhere on the wiki; the
> only place they appear is within a subobject on the aforementioned "SMW
> Participants" page. 
> 

In that case use
{{#subobject:Jon Lang|Glossary-Term=Jon|Glossary-Definition=Jonathan
Lang|Glossary-Link=Jon Lang}}

Or if you want to collect it all in one subobject

{{#subobject:Jon Lang
|personal=Jonathan
|nickname=Jon
|family=Lang
|Glossary-Term=Jon
|Glossary-Definition=Jonathan Lang
|Glossary-Link=Jon Lang
}}


Stephan

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

[Jon Lang]

Stephan Gambke wrote:

> Am 01.11.2011 20:11, schrieb Jon Lang:
> > Thank you; this gives me a means of illustrating my point.
> >
> > Take the example of my name as given by Marcus:
> >
> > Jon Lang{{#subobject name|personal=Jonathan|nickname=Jon|family=Lang}}
> >
> > In order to set up a Semantic Glossary that uses Jon Lang as the term
> > and information from {{#subobject
> > name|personal=Jonathan|nickname=Jon|family=Lang}}to build a definition,
> > you would need a person to intervene, as there are no semantics
> > connecting the former to the latter: human intuition can make the
> > connection, but a machine lacks the necessary tagging to do so.
> > Contrast this with:
> >
> > {{#subobject name|personal=Jonathan|nickname=Jon|family=Lang|Jon Lang}}
> >
> > In this case, it would be trivial for a machine to deduce that Jon Lang
> > should be the term associated with the definition that's built from the
> > rest of the #subobject.
>
> The semantic object you are assigning values to here is derived from
> 'name', e.g. if the above parser function call were to appear on the
> page 'Jon Lang' the call would result in a semantic object 'Jon
> Lang#name'.


So you're creating a glossary entry based off of the properties of a page.
I was talking about creating a glossary entry based off of the values of a
subobject.  That is, the information in question doesn't appear on a page
called "Jon Lang"; it appears on a page called "SMW participants".  For the
sake of this illustration, my first, middle, and last names aren't
specified as page properties anywhere on the wiki; the only place they
appear is within a subobject on the aforementioned "SMW Participants"
page.

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

[Stephan Gambke]

Am 01.11.2011 20:11, schrieb Jon Lang:
> Thank you; this gives me a means of illustrating my point. 
> 
> Take the example of my name as given by Marcus:
> 
> Jon Lang{{#subobject name|personal=Jonathan|nickname=Jon|family=Lang}}
> 
> In order to set up a Semantic Glossary that uses Jon Lang as the term
> and information from {{#subobject
> name|personal=Jonathan|nickname=Jon|family=Lang}}to build a definition,
> you would need a person to intervene, as there are no semantics
> connecting the former to the latter: human intuition can make the
> connection, but a machine lacks the necessary tagging to do so. 
> Contrast this with:
> 
> {{#subobject name|personal=Jonathan|nickname=Jon|family=Lang|Jon Lang}}
> 
> In this case, it would be trivial for a machine to deduce that Jon Lang
> should be the term associated with the definition that's built from the
> rest of the #subobject. 

The semantic object you are assigning values to here is derived from
'name', e.g. if the above parser function call where to appear on the
page 'Jon Lang' the call would result in a semantic object 'Jon
Lang#name'. If you instead want to assign values to the properties of
'Jon Lang' you can do so by using the usual notation on the 'Jon Lang'
page, e.g. having [[personal::Jonathan]][[nickname::Jon]] and so on.

Now, if you wanted to setup a Semantic Glossary entry for John, what I
would do is something like
{{#subobject:glossaryentry|Glossary-Term=Jon|Glossary-Definition=Jonathan 
Lang|Glossary-Link={{PAGENAME
and I would be very happy that none of this actually produces any output
because I don't want to have that stuff appear on the page of the person.

BTW, as an afterthought, there already are quite some parser functions
that do not produce any output. In fact, it would be very awkward if
they did (e.g. [1], [2], [3]).

Cheers,
Stephan


[1]
http://semantic-mediawiki.org/wiki/Help:Properties_and_types#Silent_annotations_using_.23set
[2] http://www.mediawiki.org/wiki/Extension:VariablesExtension
[3] http://www.mediawiki.org/wiki/Extension:Loops

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

[Jon Lang]

Thank you; this gives me a means of illustrating my point.

Take the example of my name as given by Marcus:

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

In order to set up a Semantic Glossary that uses Jon Lang as the term and
information from {{#subobject
name|personal=Jonathan|nickname=Jon|family=Lang}} to build a definition, you
would need a person to intervene, as there are no semantics connecting the
former to the latter: human intuition can make the connection, but a
machine lacks the necessary tagging to do so.  Contrast this with:

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

In this case, it would be trivial for a machine to deduce that Jon
Langshould be the term associated with the definition that's built
from the
rest of the #subobject.

Stephan Gambke wrote:

> Sorry for interjecting and probably I did not really get your point
> here, but Semantic Glossary [1] has just been released in its first
> (hopefully) stable version and it does not care at all about how the
> data gets into the system as long as it is there. With your approach,
> what functionality could it have, that is not yet in?
>
> Cheers,
> Stephan
>
>
> [1] http://www.mediawiki.org/wiki/Extension:Semantic_Glossary
>
>
-- 
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] [Semediawiki-user] RFC Subobjects (aka "internal objects") in SMW

[Stephan Gambke]

Am 01.11.2011 17:13, schrieb Jon Lang:
> manner when the page is displayed. As well, decoupling the
> #subobject from any sort of wiki text makes it difficult to write
> other extensions that might do such things as, say, presenting the
> semantics of a term on a page as a footnote or tooltip.

Sorry for interjecting and probably I did not really get your point
here, but Semantic Glossary [1] has just been released in its first
(hopefully) stable version and it does not care at all about how the
data gets into the system as long as it is there. With your approach,
what functionality could it have, that is not yet in?

Cheers,
Stephan


[1] http://www.mediawiki.org/wiki/Extension:Semantic_Glossary

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

[Jon Lang]

Markus Krötzsch wrote:

> On 01/11/11 14:11, Jonathan Lang wrote:
>
>> 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.
>>
>
> It does not have to be a spinoff. I am happy to include contributed code
> into SMW as long as there are some maintainers for it.


OK; I'll look into it - though hopefully the result won't be something that
needs maintenance.  (I know; wishful thinking.)

I understand, but #subobject calls do not return anything anyway. So you
> can simply write
>
> Jon Lang{{#subobject name|personal=Jonathan|**nickname=Jon|family=Lang}}
>
> if you like. I don't see a real advantage of piping this string through
> the parser function.
>

Hmm; I overlooked that.

I was drawn to SMW due to its dual-nature approach of tagging
human-readable text (arguably the primary purpose of MW) with
machine-readable data (the S in SMW); an SMW parser function that merely
provides data without having any sort of presence in the human-readable
side of things just feels wrong to me, like adding Properties to a page
without them showing up in the page's text.  From a page author's
perspective, I would expect "{{#subobject ...}}" to show up in some manner
when the page is displayed.  As well, decoupling the #subobject from any
sort of wiki text makes it difficult to write other extensions that might
do such things as, say, presenting the semantics of a term on a page as a
footnote or tooltip.

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

[Markus Krötzsch]

On 01/11/11 14:11, Jonathan Lang wrote:
> 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.

It does not have to be a spinoff. I am happy to include contributed code 
into SMW as long as there are some maintainers for it.

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

I understand, but #subobject calls do not return anything anyway. So you 
can simply write

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

if you like. I don't see a real advantage of piping this string through 
the parser function.

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

[Yaron Koren]

Hi,

Why not just do:

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

In other words, why not just take the display of the data out of the
#subobject call (assuming that's what the function will be called)
altogether?

-Yaron

On Tue, Nov 1, 2011 at 10:11 AM, Jonathan Lang  wrote:
> 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-user mailing list
> semediawiki-u...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
>



-- 
WikiWorks · MediaWiki Consulting · http://wikiworks.com

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

[Markus Krötzsch]

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

--
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-d2d-oct
___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel

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

[John McClure]

Under #2 scenario, if a template creates a subobject but never uses it in
{{#set}} then what is the impact?
Thanks


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

[Markus Krötzsch]

On 06/10/11 16:09, CW Dillon wrote:
> Jesse,
> Ooh. I hadn't thought of that, with the recipe example. You're right.
> ...there's always so much more that can be done!
>
> So, in addition to the "elegance" of option #2 is the flexibility of not
> *needing* an interim object to get at it's data. If a data page is
> desired/required, it can be created. OK. I'm convinced but, I'm only a
> user.
>
> Markus, Which way are you leaning?

Still toward #2. The only issue with this is that I will have to 
implement a bit more to make it work.

Another nice aspect of #2 is that it completely voids the "property 
direction" discussion that we had regarding the fact that SIO internal 
objects point towards a page while Option #1 points away from it. With 
Option #2, there is no property required at all and one can create 
properties in either direction.

Cheers,

Markus


> On Wed, Oct 5, 2011 at 3:16 PM, Jesse Wang  > wrote:
>
> Clarence, I regard your distinction between "address" and "recipe"
> as a practical modeling choice, it is case by case as you said. If
> "500g of flour" or "a teaspoon of sugar" is used often enough, maybe
> it makes sense to create a page for it, and you can add extra
> properties to it such as calories...
>
> Back to the choices. I favor #2.  As Markus said, it looks elegant,
> and inline with existing SMW syntax. Moreover, it feels to be Object
> Oriented, and you can parse it and treat it as an object so that you
> can develop API, and further some kind of semantic object editor, to
> handle it. The fact that it can be nested is also big, it opens
> opportunities. Parsing and replacing text may also be easier. Say,
> one day, you decide to change "Street Address" into "Physical
> Address" then parsing and replacing existing properties should be
> easier - does not have to go to all "#subobject" parser functions to
> do it...
>
> Jesse
>
> On Mon, Oct 3, 2011 at 6:50 PM, CW Dillon  > wrote:
>
> 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
>  > 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 ==
>
>   

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

[CW Dillon]

Jesse,
Ooh. I hadn't thought of that, with the recipe example. You're right.
...there's always so much more that can be done!

So, in addition to the "elegance" of option #2 is the flexibility of not
*needing* an interim object to get at it's data. If a data page is
desired/required, it can be created. OK. I'm convinced but, I'm only a user.


Markus, Which way are you leaning?

-Clarence

On Wed, Oct 5, 2011 at 3:16 PM, Jesse Wang  wrote:

> Clarence, I regard your distinction between "address" and "recipe" as a
> practical modeling choice, it is case by case as you said. If "500g of
> flour" or "a teaspoon of sugar" is used often enough, maybe it makes sense
> to create a page for it, and you can add extra properties to it such as
> calories...
>
> Back to the choices. I favor #2.  As Markus said, it looks elegant, and
> inline with existing SMW syntax. Moreover, it feels to be Object Oriented,
> and you can parse it and treat it as an object so that you can develop API,
> and further some kind of semantic object editor, to handle it. The fact that
> it can be nested is also big, it opens opportunities. Parsing and replacing
> text may also be easier. Say, one day, you decide to change "Street Address"
> into "Physical Address" then parsing and replacing existing properties
> should be easier - does not have to go to all "#subobject" parser functions
> to do it...
>
> Jesse
>
> On Mon, Oct 3, 2011 at 6:50 PM, CW Dillon  wrote:
>
>> 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

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

[Jesse Wang]

Clarence, I regard your distinction between "address" and "recipe" as a
practical modeling choice, it is case by case as you said. If "500g of
flour" or "a teaspoon of sugar" is used often enough, maybe it makes sense
to create a page for it, and you can add extra properties to it such as
calories...

Back to the choices. I favor #2.  As Markus said, it looks elegant, and
inline with existing SMW syntax. Moreover, it feels to be Object Oriented,
and you can parse it and treat it as an object so that you can develop API,
and further some kind of semantic object editor, to handle it. The fact that
it can be nested is also big, it opens opportunities. Parsing and replacing
text may also be easier. Say, one day, you decide to change "Street Address"
into "Physical Address" then parsing and replacing existing properties
should be easier - does not have to go to all "#subobject" parser functions
to do it...

Jesse

On Mon, Oct 3, 2011 at 6:50 PM, CW Dillon  wrote:

> 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

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

[Markus Krötzsch]

Hi Clarence,

I agree that the implications for modelling are not easy to see in 
general. The distinction you make between proper objects (i.e., property 
values that are connected by an object) and n-ary relations (i.e., 
property values that are related in a given context) is important for 
developing modelling guidelines.

However, at the moment I would rather like to retreat to a purely 
technical perspective to decide how the "wikitext programmer" should 
invoke SMW's subobject features. What these subobjects represent in the 
application context of a wiki remains the decision of the people who use 
them (just like with any SMW annotation). SMW can only provide 
structure, not grounding.

Regards,

Markus

On 04/10/11 02:50, CW Dillon wrote:
> 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
> mailto: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
> int

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

[CW Dillon]

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