Re: [SMW-devel] RFC Subobjects (aka "internal objects") in SMW
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] Recommended way to use WOM from other extensions?
Thanks Jesse and Ning for the replies!
(I just saw your mails, they got sorted incorrectly in my mailbox...)
Will try out the updated code!
// Samuel
On 10/30/2011 12:03 PM, Ning Hu wrote:
> 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
> mailto:samuel.lamp...@rilnet.com>> 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
> --__-
>
>
>
--
Samuel Lampa
---
Bioinformatician @ Uppsala University
Blog: http://saml.rilspace.org
---
--
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] New way to format tabular results?
Good to know that there's an easy way to resolve the template-vs-inline
parameter collision issue without resorting to mandatory prepended hash
marks. Still, it would be nice to have a way to minimize the chances of
such parameter collisions. More on this below.
Van de Bugger wrote:
> Regarding the other stuff... I think a "personal" template for each
> printout statement my be overkill... However, I do not like numbered
> placeholders as well. We already have /names/ of properties, why don't
> use them? For example:
>
> {{ #ask: [[Category:City]] [[Area::+]] [[Population::+]]
>| ?Population=Inhabitants
>| ?Area#km²=Size in km²
>| format=inline
> | inline={{{Population}}} people squeeze into the {{{Area}}} of
> {{{City}}}.
>| limit=3
> }}
>
> Van.
>
I tend to prefer named parameters to positional ones, myself.
Unfortunately, the template result format has set the precedent of using
positional parameters; and changing it over to named parameters just isn't
feasible. For reasons of consistency, I'd rather have an inline result
format that apes the template result format as much as possible; it makes
it easier to convert between an inline result format and a template result
format: so if I find that I've been using the same inline result format in
a bunch of different #asks, I can create a template out of one of the
inlines with little effort.
That said, is there a reason why the template result format can't be
changed to allow for both? That is: where ?Population is currently passed
in to a template result format as {{{1}}}, could it instead be passed in as
*both* {{{1}}} *and* {{{Population}}}? Where named placeholders have the
virtue of being clear, numbered placeholders have the virtue of being
brief; and this would let the writer of the template choose which one he
values most. Or would this be needless overhead?
I mentioned before the idea of an inline result format aping the template
result format. I also mentioned that I'd like to minimize the chances of
collisions between inline parameters and template parameters. Using named
parameters is useful in this regard, because the set of inline parameter
names stands a good chance of being different from the set of template
parameter names - whereas numbered placeholders are virtually guaranteed to
collide. But maybe there's another option: for inline parameters, prepend
the placeholder with, say, a question mark, and do this whether the
placeholder is named or numerical. In this case, the situations flip:
numbered placeholders become virtually guaranteed *not* to collide, making
named placeholders the more likely source of collisions.
This is similar to my original proposal in that it seeks to avoid
collisions by tweaking the inline names in a way that the template names
are unlikely to duplicate; it differs in that the nature of this tweak is
something that could be incorporated directly into the inline parameter's
identifier, eliminating the need for a MW hack to cope with inline
parameters:
{{ #ask: [[Category:City]] [[Area::+]] [[Population::+]]
| ?Population=Inhabitants
| ?Area#km²=Size in km²
| format=inline
| inline={{{?2}}} people squeeze into the {{{?3}}} of {{{?1}}}.
| limit=3
}}
or:
{{ #ask: [[Category:City]] [[Area::+]] [[Population::+]]
| ?Population=Inhabitants
| ?Area#km²=Size in km²
| format=inline
| inline={{{?Population}}} people squeeze into the {{{?Area}}} of
{{{?City}}}.
| limit=3
}}
...depending on whether you're looking for brevity or clarity.
--
Going back to Dan Bolzer's original proposal: I'm wondering if inline
result formats might be a decent *replacement* for said proposal, in the
interest of keeping things as lightweight as possible. That said, they do
serve slightly different purposes: Dan's proposal allows for formatting on
a field-by-field basis, within the context of whatever result format is
chosen for the overall #ask, whereas my proposal simply provides another
possible context for the result format. That is, Dan's proposal lets you
format ?Population without regard to whether the results will be presented
as a table, a bullet list, a set of comma-delimited values, or something
else; whereas my inline result format would not format ?Population at all.
So: assuming that both get implemented, I'd like Dan's proposal to use
inline templates instead of a template name, with the sole parameter being
passed in as something like {{{?0}}} or {{{?this}}}:
{{#ask: [[Category:City]] [[Area::+]] [[Population::+]]
| ?Population=Inhabitants # {{{?this}}} people
| ?Area#km²=Size in km²
| format=inline
| inline={{{?Population}}} squeeze into the {{{?Area}}} of {{{?City}}}.
| limit=3
}}
or:
{{#ask: [[Category:City]] [[Area::+]] [[Population::+]]
| ?Population=Inhabitants # {{{?0}}} people
| ?Area#km²=Size in km²
| format=inline
| inline={{{?2}}} squeeze into the {{{?3}}} of {{{?1}}}.
| limit=3
}}
--
Jon
Re: [SMW-devel] Reminder of Architecture Overview update
On 10/31/2011 07:43 PM, Markus Krötzsch wrote: > The extension of this code would make sense in SMW. One could also > imagine that this is later used for importing SPARQL results into SMW > data for general forms of SPARQL queries. I'm not sure I followed this part: "importing SPARQL results into SMW data for general forms of SPARQL queries." ... though it sounds interesting. Could you please elaborate? Overall, though, I think, supporting full roundtrip of SMW<->RDF data structures, is indeed interesting, and would enable a whole bunch of new use cases ... Just got to think about one ... that combined with a general and robust SMWSemanticData importer (into wiki pages), it would be enable to make explicit facts that are only implicit in the wiki, by the means of SPARQL CONSTRUCT queries, and persisting these new explicitized facts in the wiki ... that is, one thing of which is typically done by reasoners these days ... // 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] Reminder of Architecture Overview update
On 10/31/2011 07:55 PM, Markus Krötzsch wrote: > On 31/10/11 18:13, Samuel Lampa wrote: >> On 10/31/2011 06:52 PM, Samuel Lampa wrote: >>> === Q2: Status of SMWData/SMWDataItem as API? === >>> >>> Also I wondered what status the SMWData/SMWDataItem classes are supposed >>> to have, as a general API? ... Are they the supposed API, or is SMW >>> going towards preferring to talk SPARQL with all extensions ... or even >>> SMWExpElements? >>> >>> I ask this since it does not seem clear that I will really*need* to use >>> the SMWData/SMWDataItem combo as a representation, if I do the wiki page >>> updates either with the Wiki Object Model extension or an own writer >>> class. >>> >>> I would still prefer to use it, if it is pushed as a preferred API for >>> these kind of things, but I wondered whether that is so for the >>> foreseeable future? >> >> >> The thing that makes me wonder, is since we're basically talking about >> two slightly different (though very much overlapping) representations: >> RDF (as represented by SMWExpElement rel. classes), and Semantic >> MediaWiki facts (as repr. by SMWData/SMWDataItem). >> >> My problem, in the context of RDFIO, is that it seems I actually need >> both of these to capture the information from both worlds ... since: >> >> a. I need to store the URI:s, which only SMWExpElement classes do >> b. I need to store the wiki page titles that I choose to use (as part of >> RDFIO:s algorithm), which only the SMWData/SMWData combo does. >> >> ... thus it seems there's at least two options: >> >> 1. RDFIO creates an own more general data container, which wraps both >> the SMWData/SMWDataItem one, and the RDF one (possibly both the >> SMWExpElement one, and ARC2:s data structures), with in-built converters >> between all of these, >> >> 2. SMWData/SMWDataItem classes are updated to contain the "Original >> URI", and then this format will be the only needed one, in addition to >> possibly the ARC2 format, just for making use of it's parsers. >> >> >> Number one is the one I've been pondering so far ... I just wanted to >> point out this now and ask whether there would be any interest in >> storing also the original URI directly in the SMWData/SMWDataItem >> classes ... (which would not need to be required, for data that has no >> counterpart in the outside world, though ... or maybe can just be >> prefilled with the URIResolver URI:s ... this maybe on-the-fly, in a >> getter method)? >> >> ... it seems that would make the SMWData/SMWDI combo more general, and >> of course would make RDFIO add a lot less overhead :") >> >> (I know we discussed this on SMWCon already, but these things weren't >> really that clear to me then, about the partly but not completely >> overlap between RDF and SMW data representations ... so wanted to point >> it out ... ) > > I suggest to go for (1) if you need the full information in one object. > You should think of SMW data items as small and simple "values", similar > to an integer or a char in a programming language. They should be used > like constants of datatypes. They should only be used for storing data, > not for converting data or for augmenting it. They are pure data and > know nothing about HTML, wikitext or RDF. [Exception: the SMWDIContainer > type is a placeholder for compound data; it is not really considered as > an atomic value in SMW but just used for transporting compound data in > the API] > > With this view in mind, making an object that holds a URI and a dataitem > does not seem a bad idea (like making an object that holds an integer > and a string). > > Alternatively, you could of course represent URIs in an SMW data item as > well and relate them to wiki page with a property, stored together in an > SMWSemanticData. Ok, many thanks for the feedback! The suggestions sounds reasonable - keeping in line with the modelling approach already taken. The only little caution I'd like to make, is that the decision keeping data objects atomic makes them follow the Anemic Model antipattern [1] a bit. But that is of course a question about model design approach overall, and not this specific case only - that is, whether one wants to follow Domain Driven Design patterns [2] or not. ... so for the moment I'm happy to follow the existing model design approach :) // Samuel [1] http://martinfowler.com/bliki/AnemicDomainModel.html [2] http://en.wikipedia.org/wiki/Domain-driven_design -- 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 m
Re: [SMW-devel] Reminder of Architecture Overview update
On 31/10/11 18:13, Samuel Lampa wrote: > On 10/31/2011 06:52 PM, Samuel Lampa wrote: >> === Q2: Status of SMWData/SMWDataItem as API? === >> >> Also I wondered what status the SMWData/SMWDataItem classes are supposed >> to have, as a general API? ... Are they the supposed API, or is SMW >> going towards preferring to talk SPARQL with all extensions ... or even >> SMWExpElements? >> >> I ask this since it does not seem clear that I will really*need* to use >> the SMWData/SMWDataItem combo as a representation, if I do the wiki page >> updates either with the Wiki Object Model extension or an own writer >> class. >> >> I would still prefer to use it, if it is pushed as a preferred API for >> these kind of things, but I wondered whether that is so for the >> foreseeable future? > > > The thing that makes me wonder, is since we're basically talking about > two slightly different (though very much overlapping) representations: > RDF (as represented by SMWExpElement rel. classes), and Semantic > MediaWiki facts (as repr. by SMWData/SMWDataItem). > > My problem, in the context of RDFIO, is that it seems I actually need > both of these to capture the information from both worlds ... since: > > a. I need to store the URI:s, which only SMWExpElement classes do > b. I need to store the wiki page titles that I choose to use (as part of > RDFIO:s algorithm), which only the SMWData/SMWData combo does. > > ... thus it seems there's at least two options: > > 1. RDFIO creates an own more general data container, which wraps both > the SMWData/SMWDataItem one, and the RDF one (possibly both the > SMWExpElement one, and ARC2:s data structures), with in-built converters > between all of these, > > 2. SMWData/SMWDataItem classes are updated to contain the "Original > URI", and then this format will be the only needed one, in addition to > possibly the ARC2 format, just for making use of it's parsers. > > > Number one is the one I've been pondering so far ... I just wanted to > point out this now and ask whether there would be any interest in > storing also the original URI directly in the SMWData/SMWDataItem > classes ... (which would not need to be required, for data that has no > counterpart in the outside world, though ... or maybe can just be > prefilled with the URIResolver URI:s ... this maybe on-the-fly, in a > getter method)? > > ... it seems that would make the SMWData/SMWDI combo more general, and > of course would make RDFIO add a lot less overhead :") > > (I know we discussed this on SMWCon already, but these things weren't > really that clear to me then, about the partly but not completely > overlap between RDF and SMW data representations ... so wanted to point > it out ... ) I suggest to go for (1) if you need the full information in one object. You should think of SMW data items as small and simple "values", similar to an integer or a char in a programming language. They should be used like constants of datatypes. They should only be used for storing data, not for converting data or for augmenting it. They are pure data and know nothing about HTML, wikitext or RDF. [Exception: the SMWDIContainer type is a placeholder for compound data; it is not really considered as an atomic value in SMW but just used for transporting compound data in the API] With this view in mind, making an object that holds a URI and a dataitem does not seem a bad idea (like making an object that holds an integer and a string). Alternatively, you could of course represent URIs in an SMW data item as well and relate them to wiki page with a property, stored together in an SMWSemanticData. 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] Reminder of Architecture Overview update
On 31/10/11 17:52, Samuel Lampa wrote: > On 09/25/2011 11:05 AM, Markus Krötzsch wrote: >> RDF data is represented by a smaller set of classes under SMWExpElement. >> These classes represent triples for the purpose of serialisation (they >> abstract RDF before fixing a concrete syntax such as RDF/XML or Turtle). > > Got two questions: > > === Q1: Any SMWExpElements / SMWData converter? === > > Are there converters from/to the SMWExpElement related classes and the > SMWData/SMWDataItems combo already? > > I ask since so far I have been thinking about using the > SMWData/SMWDataItem combo as native format in RDFIO, but it strikes me > that the SMWExpElement related classes much more closely matches the > data structure that you get from ARC2's RDF parsers. > > Thus, I was thinking that if I can do only the conversion from ARC2 data > structures to SMWExpElements classes, and then there is already some > converters to SMWData/SMWDataItem, I wouldn't need to reinvent that > wheel...? Yes, the SMWExpElement classes are meant as an abstraction of RDF terms and triples. They are used (1) as a pre-serialisation format for producing RDF (in any syntax) and (2) as a post-parsing format for interpreting SPARQL results. * Due to (1), there is a complete implementation for the conversion SMWDataItem/SMWSemanticData => SMWExpElement This is done in the class SMWExporter (various methods, should be easy to find). * Due to (2), there is an incomplete conversion SMWExpElement => SMWDataItem It is incomplete since we only need to interpret URIs as wiki pages when reading SPARQL results. Other types of RDF terms are not relevant in the SPARQL results we interpret. This conversion is implemented in SMWExporter::findDataItemForExpElement(). This method could be extended to create SMWDataItems for other types of input on a best-effort basis. Since SPARQL results are plain lists (no graphs), there is no method yet for turning sets of triples into (necessarily many) SMWSemanticData objects. This could be added to SMWExporter as well, if needed. The extension of this code would make sense in SMW. One could also imagine that this is later used for importing SPARQL results into SMW data for general forms of SPARQL queries. Note, however, that a main design goal for such an extension would be to round-trip the data that SMW exports as good as possible. > > === Q2: Status of SMWData/SMWDataItem as API? === > > Also I wondered what status the SMWData/SMWDataItem classes are supposed > to have, as a general API? ... Are they the supposed API, or is SMW > going towards preferring to talk SPARQL with all extensions ... or even > SMWExpElements? > > I ask this since it does not seem clear that I will really *need* to use > the SMWData/SMWDataItem combo as a representation, if I do the wiki page > updates either with the Wiki Object Model extension or an own writer class. > > I would still prefer to use it, if it is pushed as a preferred API for > these kind of things, but I wondered whether that is so for the > foreseeable future? SMWDataItems are supposed to be the main atomic data representation API in SMW. SMWSemanticData is the main annotation (property assignment) API in SMW. Both are assumed to stay in this position for the foreseeable future. SMWExpElement is based on the RDF data model and is therefore not suitable for representing SMW data where we have special elements like wiki pages, properties or geographic coordinates that are not represented explicitly in RDF. We need an API that distinguishes data items by their functional role in SMW (e.g., wiki page vs. property vs. URI) where this distinction does not exist in RDF. For these reasons, data items and semantic data containers are the main API for passing around data in SMW. 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] Reminder of Architecture Overview update
On 10/31/2011 07:13 PM, Samuel Lampa wrote: > (which would not need to be required, for data that has no > counterpart in the outside world, I mean, these "Original URI" fields would not be required to be filled. (Sorry for the possible confusion) // 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] Reminder of Architecture Overview update
On 10/31/2011 06:52 PM, Samuel Lampa wrote: > === Q2: Status of SMWData/SMWDataItem as API? === > > Also I wondered what status the SMWData/SMWDataItem classes are supposed > to have, as a general API? ... Are they the supposed API, or is SMW > going towards preferring to talk SPARQL with all extensions ... or even > SMWExpElements? > > I ask this since it does not seem clear that I will really*need* to use > the SMWData/SMWDataItem combo as a representation, if I do the wiki page > updates either with the Wiki Object Model extension or an own writer class. > > I would still prefer to use it, if it is pushed as a preferred API for > these kind of things, but I wondered whether that is so for the > foreseeable future? The thing that makes me wonder, is since we're basically talking about two slightly different (though very much overlapping) representations: RDF (as represented by SMWExpElement rel. classes), and Semantic MediaWiki facts (as repr. by SMWData/SMWDataItem). My problem, in the context of RDFIO, is that it seems I actually need both of these to capture the information from both worlds ... since: a. I need to store the URI:s, which only SMWExpElement classes do b. I need to store the wiki page titles that I choose to use (as part of RDFIO:s algorithm), which only the SMWData/SMWData combo does. ... thus it seems there's at least two options: 1. RDFIO creates an own more general data container, which wraps both the SMWData/SMWDataItem one, and the RDF one (possibly both the SMWExpElement one, and ARC2:s data structures), with in-built converters between all of these, 2. SMWData/SMWDataItem classes are updated to contain the "Original URI", and then this format will be the only needed one, in addition to possibly the ARC2 format, just for making use of it's parsers. Number one is the one I've been pondering so far ... I just wanted to point out this now and ask whether there would be any interest in storing also the original URI directly in the SMWData/SMWDataItem classes ... (which would not need to be required, for data that has no counterpart in the outside world, though ... or maybe can just be prefilled with the URIResolver URI:s ... this maybe on-the-fly, in a getter method)? ... it seems that would make the SMWData/SMWDI combo more general, and of course would make RDFIO add a lot less overhead :") (I know we discussed this on SMWCon already, but these things weren't really that clear to me then, about the partly but not completely overlap between RDF and SMW data representations ... so wanted to point it out ... ) // 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] Reminder of Architecture Overview update
On 09/25/2011 11:05 AM, Markus Krötzsch wrote: > RDF data is represented by a smaller set of classes under SMWExpElement. > These classes represent triples for the purpose of serialisation (they > abstract RDF before fixing a concrete syntax such as RDF/XML or Turtle). Got two questions: === Q1: Any SMWExpElements / SMWData converter? === Are there converters from/to the SMWExpElement related classes and the SMWData/SMWDataItems combo already? I ask since so far I have been thinking about using the SMWData/SMWDataItem combo as native format in RDFIO, but it strikes me that the SMWExpElement related classes much more closely matches the data structure that you get from ARC2's RDF parsers. Thus, I was thinking that if I can do only the conversion from ARC2 data structures to SMWExpElements classes, and then there is already some converters to SMWData/SMWDataItem, I wouldn't need to reinvent that wheel...? === Q2: Status of SMWData/SMWDataItem as API? === Also I wondered what status the SMWData/SMWDataItem classes are supposed to have, as a general API? ... Are they the supposed API, or is SMW going towards preferring to talk SPARQL with all extensions ... or even SMWExpElements? I ask this since it does not seem clear that I will really *need* to use the SMWData/SMWDataItem combo as a representation, if I do the wiki page updates either with the Wiki Object Model extension or an own writer class. I would still prefer to use it, if it is pushed as a preferred API for these kind of things, but I wondered whether that is so for the foreseeable future? // 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] [Semediawiki-user] New way to format tabular results?
Hi.
I think this would be a great supplement to the existing functionality,
but I would not like to see the existing template functionality dropped
as it allows for very slick and precise control of the output of a query.
Regards
Neill.
On 31/10/11 14:39, Yaron Koren wrote:
> Hi,
>
> This seems like good timing, because Markus gave a good talk at the
> most recent SMWCon, in Berlin, that included a discussion about
> template queries; and that talk has been uploaded, so you can see it
> here:
>
> http://www.youtube.com/watch?v=e0DI_GyIBbw
>
> (Not all of the videos from last month's SMWCon have been uploaded yet
> - there will hopefully be another email sent out when that happens.)
>
> Anyway, the relevant recommendation from that talk is, instead of
> using additional templates, to add to the template where the data is
> stored a silent property like "Has query display", that stores the
> wiki-text for that record in the query result, and then just display
> that in the query. (You would still need to put the table header and
> footer around the query itself, if you wanted to show the results as a
> table.) This approach might not be as slick-looking as direct inline
> formatting of the results, but performance-wise, it's quite a bit more
> efficient than any of the three options mentioned before.
>
> -Yaron
>
> On Sat, Oct 29, 2011 at 2:50 PM, Dan Bolser wrote:
>> I like this idea too. However, I suspect it will be hard to get MW to
>> ignore {{{#n}}} just for the purposes of SMW.
>>
>> Is there a cleaner way to 'inline' a format template in the query?
>>
>> I totally agree that creating two or three templates for one ask query
>> is the main reason that template format is a pain.
>>
>>
>> Cheers,
>> Dan.
>>
>> On 28 October 2011 23:18, Jon Lang wrote:
>>> Dan Bolser wrote:
Hi,
Currently we have tabular format results and, if we want
customization, we have 'template' format results.
* Tabular format is great, but is quite inflexible.
* Template format is very flexible, but complex, hard to develop and
maintain.
I'd like to suggest a half way house for simple column based tabular
formatting. Something along the lines of the following:
{{#ask: [[My Cat]]
|? My prop 1 # Template for p1
|? My prop 2 # Template for p2
|? My prop 3
|? My prop 4 = P4
}}
For each row, this would call the template 'Template for p1' with just
one parameter, the value for 'My prop 1'. The resulting wikitext would
then be passed back for regular tabular layout. As implied, these 'per
column' templates could be mixed with 'unadorned' values, that would
appear just as in regular tabular output.
This would be a much lighter and easier way to 'tweak' the results of
tabular format without going to the full blown (and sometimes
unpopular) template format.
I've posted here for discussion, but we can start a feature request
instead.
>>> I like this idea, and would like to piggyback a suggestion of my own here.
>>>
>>> Sometimes, the reason why the template format is unpopular is because it is
>>> overkill. For instance, if you're only going to be formatting a single
>>> #ask, creating a full template page for it seems like a bit much. I'd like
>>> to see an "inline" result format that works just like the template result
>>> format except that it embeds the template directly into the query. For
>>> example:
>>>
>>> {{#ask: [[Category:City]] [[Area::+]] [[Population::+]]
>>>| ?Population=Inhabitants
>>>| ?Area#km²=Size in km²
>>>| format=inline
>>>| inline={{{#2}}} people squeeze into the {{{#3}}} of {{{#1}}}.
>>>| limit=3
>>> }}
>>>
>>> The hash marks inside the triple-curlies are to distinguish these "inline
>>> template" parameters from any regular template parameters that may be in
>>> play if the #ask appears on a template page.
>>>
>>> This is germane to Dan's proposal in that I would recommend inline templates
>>> for what he's suggesting rather than regular templates:
>>>
>>> {{#ask: [[My Cat]]
>>>|? My prop 1 # format string for p1
>>>|? My prop 2 # format string for p2
>>>|? My prop 3
>>>|? My prop 4 = P4
>>> }}
>>>
>>> As with my "inline result format" suggestion above, the value for each
>>> cell's format would be specified as {{{#1}}}. So:
>>>
>>> {{#ask: [[Category:City]] [[Area::+]] [[Population::+]]
>>>| ?Population=Inhabitants # {{{#1}}} people
>>>| ?Area#km²=Size in km²
>>>| limit=3
>>> }}
>>>
>>> would produce something like:
>>>
>>> {|
>>> ! Inhabitants !! Size in km²
>>> |-
>>> | Berlin || 3,391,409 people || 891.85 km²
>>> |-
>>> | Frankfurt || 679,664 people || 248.31 km²
>>> |-
>>> | Karlsruhe || 285,812 people || 173.46 km²
>>> |}
>>>
>>> If you wish to utilize an actual template page, you can do so using the
>>> regular wiki syntax for including a template; the only catch is that I think
>>> that yo
Re: [SMW-devel] [Semediawiki-user] New way to format tabular results?
Thanks for this tip Yaron (and thanks for the pointer to the vid). For
some reason I didn't think of storing the 'display-version' of the
property, but it makes sense.
On 31 October 2011 14:39, Yaron Koren wrote:
> Hi,
>
> This seems like good timing, because Markus gave a good talk at the
> most recent SMWCon, in Berlin, that included a discussion about
> template queries; and that talk has been uploaded, so you can see it
> here:
>
> http://www.youtube.com/watch?v=e0DI_GyIBbw
>
> (Not all of the videos from last month's SMWCon have been uploaded yet
> - there will hopefully be another email sent out when that happens.)
>
> Anyway, the relevant recommendation from that talk is, instead of
> using additional templates, to add to the template where the data is
> stored a silent property like "Has query display", that stores the
> wiki-text for that record in the query result, and then just display
> that in the query. (You would still need to put the table header and
> footer around the query itself, if you wanted to show the results as a
> table.) This approach might not be as slick-looking as direct inline
> formatting of the results, but performance-wise, it's quite a bit more
> efficient than any of the three options mentioned before.
>
> -Yaron
>
> On Sat, Oct 29, 2011 at 2:50 PM, Dan Bolser wrote:
>> I like this idea too. However, I suspect it will be hard to get MW to
>> ignore {{{#n}}} just for the purposes of SMW.
>>
>> Is there a cleaner way to 'inline' a format template in the query?
>>
>> I totally agree that creating two or three templates for one ask query
>> is the main reason that template format is a pain.
>>
>>
>> Cheers,
>> Dan.
>>
>> On 28 October 2011 23:18, Jon Lang wrote:
>>> Dan Bolser wrote:
Hi,
Currently we have tabular format results and, if we want
customization, we have 'template' format results.
* Tabular format is great, but is quite inflexible.
* Template format is very flexible, but complex, hard to develop and
maintain.
I'd like to suggest a half way house for simple column based tabular
formatting. Something along the lines of the following:
{{#ask: [[My Cat]]
|? My prop 1 # Template for p1
|? My prop 2 # Template for p2
|? My prop 3
|? My prop 4 = P4
}}
For each row, this would call the template 'Template for p1' with just
one parameter, the value for 'My prop 1'. The resulting wikitext would
then be passed back for regular tabular layout. As implied, these 'per
column' templates could be mixed with 'unadorned' values, that would
appear just as in regular tabular output.
This would be a much lighter and easier way to 'tweak' the results of
tabular format without going to the full blown (and sometimes
unpopular) template format.
I've posted here for discussion, but we can start a feature request
instead.
>>>
>>> I like this idea, and would like to piggyback a suggestion of my own here.
>>>
>>> Sometimes, the reason why the template format is unpopular is because it is
>>> overkill. For instance, if you're only going to be formatting a single
>>> #ask, creating a full template page for it seems like a bit much. I'd like
>>> to see an "inline" result format that works just like the template result
>>> format except that it embeds the template directly into the query. For
>>> example:
>>>
>>> {{#ask: [[Category:City]] [[Area::+]] [[Population::+]]
>>> | ?Population=Inhabitants
>>> | ?Area#km²=Size in km²
>>> | format=inline
>>> | inline={{{#2}}} people squeeze into the {{{#3}}} of {{{#1}}}.
>>> | limit=3
>>> }}
>>>
>>> The hash marks inside the triple-curlies are to distinguish these "inline
>>> template" parameters from any regular template parameters that may be in
>>> play if the #ask appears on a template page.
>>>
>>> This is germane to Dan's proposal in that I would recommend inline templates
>>> for what he's suggesting rather than regular templates:
>>>
>>> {{#ask: [[My Cat]]
>>> |? My prop 1 # format string for p1
>>> |? My prop 2 # format string for p2
>>> |? My prop 3
>>> |? My prop 4 = P4
>>> }}
>>>
>>> As with my "inline result format" suggestion above, the value for each
>>> cell's format would be specified as {{{#1}}}. So:
>>>
>>> {{#ask: [[Category:City]] [[Area::+]] [[Population::+]]
>>> | ?Population=Inhabitants # {{{#1}}} people
>>> | ?Area#km²=Size in km²
>>> | limit=3
>>> }}
>>>
>>> would produce something like:
>>>
>>> {|
>>> ! Inhabitants !! Size in km²
>>> |-
>>> | Berlin || 3,391,409 people || 891.85 km²
>>> |-
>>> | Frankfurt || 679,664 people || 248.31 km²
>>> |-
>>> | Karlsruhe || 285,812 people || 173.46 km²
>>> |}
>>>
>>> If you wish to utilize an actual template page, you can do so using the
>>> regular wiki syntax for including a template; the only catch is that I think
>>> that you'd have to explicitly pass the value into the template:
>>>
>>> {{#ask
Re: [SMW-devel] [Semediawiki-user] New way to format tabular results?
Hi,
This seems like good timing, because Markus gave a good talk at the
most recent SMWCon, in Berlin, that included a discussion about
template queries; and that talk has been uploaded, so you can see it
here:
http://www.youtube.com/watch?v=e0DI_GyIBbw
(Not all of the videos from last month's SMWCon have been uploaded yet
- there will hopefully be another email sent out when that happens.)
Anyway, the relevant recommendation from that talk is, instead of
using additional templates, to add to the template where the data is
stored a silent property like "Has query display", that stores the
wiki-text for that record in the query result, and then just display
that in the query. (You would still need to put the table header and
footer around the query itself, if you wanted to show the results as a
table.) This approach might not be as slick-looking as direct inline
formatting of the results, but performance-wise, it's quite a bit more
efficient than any of the three options mentioned before.
-Yaron
On Sat, Oct 29, 2011 at 2:50 PM, Dan Bolser wrote:
> I like this idea too. However, I suspect it will be hard to get MW to
> ignore {{{#n}}} just for the purposes of SMW.
>
> Is there a cleaner way to 'inline' a format template in the query?
>
> I totally agree that creating two or three templates for one ask query
> is the main reason that template format is a pain.
>
>
> Cheers,
> Dan.
>
> On 28 October 2011 23:18, Jon Lang wrote:
>> Dan Bolser wrote:
>>>
>>> Hi,
>>>
>>> Currently we have tabular format results and, if we want
>>> customization, we have 'template' format results.
>>> * Tabular format is great, but is quite inflexible.
>>> * Template format is very flexible, but complex, hard to develop and
>>> maintain.
>>>
>>> I'd like to suggest a half way house for simple column based tabular
>>> formatting. Something along the lines of the following:
>>>
>>> {{#ask: [[My Cat]]
>>> |? My prop 1 # Template for p1
>>> |? My prop 2 # Template for p2
>>> |? My prop 3
>>> |? My prop 4 = P4
>>> }}
>>>
>>> For each row, this would call the template 'Template for p1' with just
>>> one parameter, the value for 'My prop 1'. The resulting wikitext would
>>> then be passed back for regular tabular layout. As implied, these 'per
>>> column' templates could be mixed with 'unadorned' values, that would
>>> appear just as in regular tabular output.
>>>
>>> This would be a much lighter and easier way to 'tweak' the results of
>>> tabular format without going to the full blown (and sometimes
>>> unpopular) template format.
>>>
>>> I've posted here for discussion, but we can start a feature request
>>> instead.
>>>
>>
>> I like this idea, and would like to piggyback a suggestion of my own here.
>>
>> Sometimes, the reason why the template format is unpopular is because it is
>> overkill. For instance, if you're only going to be formatting a single
>> #ask, creating a full template page for it seems like a bit much. I'd like
>> to see an "inline" result format that works just like the template result
>> format except that it embeds the template directly into the query. For
>> example:
>>
>> {{#ask: [[Category:City]] [[Area::+]] [[Population::+]]
>> | ?Population=Inhabitants
>> | ?Area#km²=Size in km²
>> | format=inline
>> | inline={{{#2}}} people squeeze into the {{{#3}}} of {{{#1}}}.
>> | limit=3
>> }}
>>
>> The hash marks inside the triple-curlies are to distinguish these "inline
>> template" parameters from any regular template parameters that may be in
>> play if the #ask appears on a template page.
>>
>> This is germane to Dan's proposal in that I would recommend inline templates
>> for what he's suggesting rather than regular templates:
>>
>> {{#ask: [[My Cat]]
>> |? My prop 1 # format string for p1
>> |? My prop 2 # format string for p2
>> |? My prop 3
>> |? My prop 4 = P4
>> }}
>>
>> As with my "inline result format" suggestion above, the value for each
>> cell's format would be specified as {{{#1}}}. So:
>>
>> {{#ask: [[Category:City]] [[Area::+]] [[Population::+]]
>> | ?Population=Inhabitants # {{{#1}}} people
>> | ?Area#km²=Size in km²
>> | limit=3
>> }}
>>
>> would produce something like:
>>
>> {|
>> ! Inhabitants !! Size in km²
>> |-
>> | Berlin || 3,391,409 people || 891.85 km²
>> |-
>> | Frankfurt || 679,664 people || 248.31 km²
>> |-
>> | Karlsruhe || 285,812 people || 173.46 km²
>> |}
>>
>> If you wish to utilize an actual template page, you can do so using the
>> regular wiki syntax for including a template; the only catch is that I think
>> that you'd have to explicitly pass the value into the template:
>>
>> {{#ask: [[My Cat]]
>> |? My prop 1 # {{template for p1|{{{#1}
>> |? My prop 2 # {{template for p2|{{{#1}
>> |? My prop 3
>> |? My prop 4 = P4
>> }}
>>
>> --
>> Jonathan "Dataweaver" Lang
>>
>
> --
> Get your Android app more play: Bring it to the BlackBerry PlayBook
> in minute
Re: [SMW-devel] One week RDFIO sprint from now
On 10/30/2011 12:16 PM, Markus Krötzsch wrote: > 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 -- Thanks! Yeah, many big plans there ... remains to see what actually gets done :) > 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). Thanks! Hopefully the extra explanations earlier here on SMW-devel, as well as our discussion on SMWCon, will go a long way, but I'll be happy to ping you for any further questions! Also, if you have time, it would be very nice to have some code review when the new structure of the extension starts to crystallize a bit later this week (hopefully). (I guess that is also a suitable time to commit the stuff back to MW repos, so I'll come back when that happens). // 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] RFC Subobjects (aka "internal objects") in SMW
On 30/10/11 21:43, Stephan Gambke wrote:
> Hi Markus,
>
> Am 30.10.2011 12:12, schrieb Markus Krötzsch:
>> Thanks. What I now implemented requires naming for all subobjects, so it
>> is not optional. One could have another parser function that does not
>> require a name; overloading #subobject to do both (named subobjects
>> without any return value and anonymous subobjects returning their
>> generated name) seems to have a great potential for confusion. Maybe we
>> don't need unnamed subobjects after all.
>
> I think unnamed subobjects would be very useful. E.g. suppose you have a
> multiple-instance template in a Semantic Form. Currently there is no way
> to ensure unique names for the subobjects.
> (Ok, you could use the extensions Variables and Parser Functions).
Fair point. I could provide another parser function for this (behaviour:
it gets only a list of property=value pairs and returns the name of the
generated subobject).
So we need a second new name :-o. But I think overloading #subobject is
possibly confusing ("if the first parameter does not contain a '=' then
make a subobject name and return it; otherwise use the first parameter
as a name and do not return anything").
Regards,
Markus
--
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World™ 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
