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

2011-10-30 Thread 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: Naming

2011-10-30 Thread Dan Bolser 
I can think of lots of options too...

multi value property (I know)
composite property
virtual page
internal page
internal object (I know)

Ultimately, I think "subobject" and "has subobject" win in my head
because of precedence. I don't think 'object' is too far from the
truth here, in so far as a page can be described as a class
instance... It's not quite right though...

If I had to go with a new name, I may pick 'page element' and 'has
page element', as it's specific enough to not likely cause conflicts,
yet generic enough to not really imply any functionality beyond what
you read in the documentation ;-)

Great functionality though, no matter what it gets called!


Cheers,
Dan.

On 30 October 2011 11:50, Markus Krötzsch  wrote:
> Here is another aggregated reply, this time about the naming.
>
> I agree that #subobject is not ideal. I agree that "object" has
> technical connotations, but not that they are necessarily related to
> anything specific; it's just a very general term that has all kinds of
> meanings in all kinds of areas. My wife laughed at me when I told her
> that we call the "objects" that are associated with "subjects"
> "subobjects" :-D
>
> There are two naming strategies: (1) use a name that refers to the
> "object" or (2) use a name that refers to the "group" of property-value
> pairs. Maybe *named* subobjects should be based on (1) while anonymous
> ones could be based on (2). Here are some variants for each:
>
> (1) object, subobject, entity, thing, element, component, part, description
>
> (2) group, vector, collection, bag, container
>
> I would avoid entity/thing as too vague, and vector since it suggests an
> ordering of content. Maybe one should have parser functions that suggest
> an action as opposed to a thing that the action creates. For instance,
> we could have
>
> {{#describe:My office address| ...}}
>
> A related question is: how should the property be called that relates
> pages to their subobjects. It now is called "has subobject" but this
> just comes from the current name #subobject. I also found "subobject"
> hard to translate into other languages (English is still least weird
> since there are many such technical terms in computer English). A less
> technical choice of words might help there.
>
> 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/semediawi

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

2011-10-30 Thread 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

2011-10-30 Thread 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: Naming

2011-10-30 Thread Markus Krötzsch 
Here is another aggregated reply, this time about the naming.

I agree that #subobject is not ideal. I agree that "object" has 
technical connotations, but not that they are necessarily related to 
anything specific; it's just a very general term that has all kinds of 
meanings in all kinds of areas. My wife laughed at me when I told her 
that we call the "objects" that are associated with "subjects" 
"subobjects" :-D

There are two naming strategies: (1) use a name that refers to the 
"object" or (2) use a name that refers to the "group" of property-value 
pairs. Maybe *named* subobjects should be based on (1) while anonymous 
ones could be based on (2). Here are some variants for each:

(1) object, subobject, entity, thing, element, component, part, description

(2) group, vector, collection, bag, container

I would avoid entity/thing as too vague, and vector since it suggests an 
ordering of content. Maybe one should have parser functions that suggest 
an action as opposed to a thing that the action creates. For instance, 
we could have

{{#describe:My office address| ...}}

A related question is: how should the property be called that relates 
pages to their subobjects. It now is called "has subobject" but this 
just comes from the current name #subobject. I also found "subobject" 
hard to translate into other languages (English is still least weird 
since there are many such technical terms in computer English). A less 
technical choice of words might help there.

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

2011-10-30 Thread 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] Recommended way to use WOM from other extensions?

2011-10-30 Thread Ning Hu 
Hi Samuel,

WOM api is recommended in remote using, for local use, object functions are
recommended.

   -
   http://wiking.vulcan.com/dev/index.php/Extension:Wiki_Object_Model/Functions
   -
   
http://wiking.vulcan.com/dev/index.php/Extension:Wiki_Object_Model/ObjectModels

As to sentence object, sentence object is not a standard Wiki object.
It is treated as an 'object collection', which may contain the following
object types.  ( extensions\WikiObjectModel\includes\WOM_Setup.php
$wgOMSentenceObjectTypes )

   - text
   - property (SMW)
   - link
   - category
   - magicword
   - template field holder ( {{{xxx}}} )

The first code piece in the sample is to get the first sentence object.
Code piece to get the 'first text' is not there. Text object is inside
sentence object.
Sorry for the misleading, I just update the document.

http://wiking.vulcan.com/dev/index.php/Extension:Wiki_Object_Model/Functions#Set_Wiki_object

Hope it will help.

Thanks,
Ning

On Sun, Oct 30, 2011 at 8:30 AM, Jesse Wang  wrote:

> Hi, Samuel,
> Just got a chance to write back, I've busy dealing with jet lag and trick
> or treat :-)
> For developers, the recommended way is to use the WOM Functions directly
> because you have more control and it'll be faster too.
> I'm not sure what caused the error you mentioned, can you send me and Ning
> (cc-ed here too) more details about the repro of the issue (such as your
> browser version, OS, etc.)?
> Have a good weekend!
> Jesse
>
> On Fri, Oct 28, 2011 at 12:42 PM, Samuel Lampa 
> wrote:
>
>> Hi Jesse (cc SMW-devel, if someone else has some input),
>>
>> I'm looking into using the WOM extension in RDFIO.
>>
>> I was wondering what the recommended way is to access the WOM API from
>> other extensions ... Is it via the API functions (described in
>> http://wiking.vulcan.com/dev/**index.php/Extension:Wiki_**
>> Object_Model/Apis),
>>  for example via fauxRequest, or by using the WOMProcessor and related
>> functions directly (as seen in http://wiking.vulcan.com/dev/**
>> index.php/Extension:Wiki_**Object_Model/Functions#WOM_**Functions)?
>>
>> I guess both might work(?), but I was looking for the pros/cons of each,
>> and any other hints?
>>
>> Cheers,
>> // Samuel
>>
>> --
>> Samuel Lampa
>> --**-
>>  Bioinformatician @ Uppsala University
>>   Blog: http://saml.rilspace.org
>> --**-
>>
>
>
--
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] One week RDFIO sprint from now

2011-10-30 Thread Markus Krötzsch 
On 28/10/11 19:30, Samuel Lampa wrote:
> JFYI, I'm taking one week off from work, next week, to try to do
> something about RDFIO, to get it in a usable state, and hopefully do
> quite a lot of overall improvements as well.
>
> I summarized the plans here:
> http://saml.rilspace.org/one-week-off-to-work-on-rdfio
>
> Since I don't have too much time to work on this except when taking time
> off from work like this, I will much appreciate any input on the
> plans/progress during this coming week!
>
> I'll come back with a GitHub link for the repo (guess I better set up a
> temporary working repo, before checking into MW repos, due to the big
> changes that are planned ... will probably really break things for a
> while ...).

Nice :-) The general goals look very good -- hope you are making good 
progress. Feel free to skype me if you have questions (I know that I 
have not managed to complete the architecture guide yet).

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

2011-10-30 Thread 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