Sent via BlackBerry by AT&T
-----Original Message-----
From: semediawiki-devel-requ...@lists.sourceforge.net
Date: Wed, 23 May 2012 10:49:44
To: <semediawiki-devel@lists.sourceforge.net>
Reply-To: semediawiki-devel@lists.sourceforge.net
Subject: Semediawiki-devel Digest, Vol 71, Issue 16
Send Semediawiki-devel mailing list submissions to
semediawiki-devel@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
or, via email, send a message with subject or body 'help' to
semediawiki-devel-requ...@lists.sourceforge.net
You can reach the person managing the list at
semediawiki-devel-ow...@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Semediawiki-devel digest..."
Today's Topics:
1. Re: installing WYSIWYG extension does nothing? (David M. Cotter)
2. Re: Semantic mediawiki and map data (Kim Eik)
3. Re: Semantic mediawiki and map data (Markus Kr?tzsch)
4. Re: Semantic mediawiki and map data (Kim Eik)
----------------------------------------------------------------------
Message: 1
Date: Tue, 22 May 2012 20:34:14 -0700
From: "David M. Cotter" <m...@davecotter.com>
Subject: Re: [SMW-devel] installing WYSIWYG extension does nothing?
To: semediawiki-devel@lists.sourceforge.net
Message-ID: <c6df5c60-bd00-48f3-a310-82e0edc53...@davecotter.com>
Content-Type: text/plain; charset=us-ascii
are the devs for this just gone? does nobody maintain this extension?
On May 17, 2012, at 9:35 PM, David M. Cotter wrote:
> I followed the instructions as above (i've installed many extensions, so i
> know what i'm doing), yet i still do not get the WYSIWYG editor.
>
> I see that it *does* say "&mode=wysiwyg" in the URL bar when i go to edit,
> yet i get no editor. you can see this in action here:
> https://karaoke.kjams.com/wiki/Sandbox
>
> note: you'll have to join create an account by joining the forum to edit
>
> here's the install instructions i followed:
> http://www.smwplus.com/index.php/Help:Installing_the_WYSIWYG_extension_manually_on_top_of_MediaWiki_%28v_1.16.x%29_1.7.0
------------------------------
Message: 2
Date: Wed, 23 May 2012 10:02:42 +0200
From: Kim Eik <k...@heldig.org>
Subject: Re: [SMW-devel] Semantic mediawiki and map data
To: semediawiki-devel@lists.sourceforge.net
Message-ID:
<CAC7+dqjZ=udsEV1WVaE=rgaSVnLK=y_vrzzr4+vzxzohz2a...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
>From your descritpion, a container data item looks like the way to go for
storing my structures. Do you have a practical example on how container
data item is used?
>From the code documentation i can see that:
* Being a mere placeholder/template for other data, an SMWDIContainer is
not
* immutable as the other basic data items. New property-value pairs can
always
* be added to the internal SMWContainerSemanticData.
so is it correct to assume that in a practical example, in order to create
a container data item, you actually create a template which holds all your
other properties (like a set of [[Polygon::...]] properties)?
As i said, i'm quite new to this semantic way of structuring data, so
please forgive me for not having a better understanding of how all this is
connected.
And another thing, in which end would you say i should start trying to
implement my data structure, should i start with the individual
dataitems/datavalues and then look at creating a container? do i even need
to create/subclass my own container? or can i use the one already defined?
Best regards from mr. slightly confused
On Tue, May 22, 2012 at 9:48 PM, Markus Kr?tzsch <
mar...@semantic-mediawiki.org> wrote:
> Hi Kim,
>
> that is a very exciting project. Here are some general hints/comments:
>
> * Jeroen is right, but I would suggest a slightly different approach :-)
>
> * To get started, you can store your data in a Container data item
> (similar to subobjects and records). In essence, this means that each value
> can be an arbitrary collection of property-value pairs. This gives you most
> flexibility and might even be needed for things like polygons where you
> have no limit on the amount of data.
>
> * This does not affect your surface syntax. You can create a datavalue
> (DV) implementation for your datatypes, and the parsing and general I/O
> will be the same in any case. So it will allow you to do many things.
>
> * Once this works and you have a clearer idea what the data looks like, it
> might be useful to have special DIs for it. The advantage of that is that
> the database can handle them more efficiently than general purpose
> container objects. The disadvantage is that the database would need to
> handle them in special ways instead of treating them as general purpose
> container objects. So there is some code needed to get update, retrieval,
> and query answering implemented.
>
> * The special DIs can still support the interface of Container, they can
> even be a special form of containers, and thus create subobjects to which
> further properties could be attached. This does not prevent the database
> from having a special handling for these containers if it is known that
> their structure is of a special form that could be stored in a more
> efficient way. So it is not necessary that your code avoids the use of
> Container-specific code just because of the possible later change to a
> custom DI. In fact, you will certainly need to use the interface of
> Container to get at the data.
>
> * Nischay is currently working on a general overhaul of the SQL database
> backend as part of his Google Summer of Code project. This might simplify
> such extensions in the future by making the code better structured and more
> accessible. So there are good reasons to wait with DI extensions now. We
> will keep this use case in mind -- maybe the code that is specific to each
> DI can be cleanly separated from the rest.
>
> Cheers,
>
> Markus
>
>
>
> On 22/05/12 16:08, Jeroen De Dauw wrote:
>
>> Hey,
>>
>> > a map can have several polygons
>>
>> Sure. Which polygons a map shows is determined by the query it
>> visualizes the results for. When creating the definitions of the
>> polygons you should not have to care to much of which polygon will end
>> up on what map. You just create a data structure that makes sense and
>> ensure that you can actually do the kind of queries you want to do.
>>
>> > Would this structure be a fair assumption?
>> >
>> [[Polygons::[[Polygon::<**coords>,<coords>,<coords>...]]**
>> ,[[Polygon::<coords>,<coords>,**<coords>...]],[[Polygon::<**
>> coords>,<coords>,<coords>...]]**]]
>>
>> No. Imagine you have a pile of articles of cities, then you could have a
>> property such as "Has location" (which is of type polygon) which would
>> look like:
>>
>> [[Has location::<coords>,<coords>,<**coords>...]]
>>
>> If you have an article describing an object that has multiple polygons,
>> for example a group of islands where each island needs a polygon, then
>> you simply have multiple such properties on the page.
>>
>> > So say i have a [[Polygon::<coords>,<coords>,<**coords>]] property
>> defined exactly how can i point additional metadata to this object?
>>
>> In order to be able to point to an object, it needs to be of type page.
>> So you cannot out of the box specify a property such as "Has stroke
>> color". One option is to specify the polygons as part of subobjects [0],
>> which can then also hold any extra extra info on the polygon.
>>
>> In a way it would be nicer to not have it as part of the subobject, but
>> it actually behave like one, in which case you could have a list of "Has
>> point" properties. This way you could do stuff like querying all the
>> points in a polygon that have a latitude more then x. This requires some
>> more thought I think - anyone more thoughts on this?
>>
>> [0]
>> http://semantic-mediawiki.org/**wiki/Subobject<http://semantic-mediawiki.org/wiki/Subobject>
>>
>> Cheers
>>
>> --
>> Jeroen De Dauw
>> http://www.bn2vs.com
>> Don't panic. Don't be evil.
>> --
>>
>>
>> ------------------------------**------------------------------**
>> ------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats.
>> http://www.accelacomm.com/jaw/**sfrnl04242012/114/50122263/<http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/>
>>
>>
>>
>> ______________________________**_________________
>> Semediawiki-devel mailing list
>> Semediawiki-devel@lists.**sourceforge.net<Semediawiki-devel@lists.sourceforge.net>
>> https://lists.sourceforge.net/**lists/listinfo/semediawiki-**devel<https://lists.sourceforge.net/lists/listinfo/semediawiki-devel>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 3
Date: Wed, 23 May 2012 10:11:10 +0100
From: Markus Kr?tzsch <mar...@semantic-mediawiki.org>
Subject: Re: [SMW-devel] Semantic mediawiki and map data
To: Kim Eik <k...@heldig.org>
Cc: semediawiki-devel@lists.sourceforge.net
Message-ID: <4fbca9ae.6080...@semantic-mediawiki.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 23/05/12 09:02, Kim Eik wrote:
> >From your descritpion, a container data item looks like the way to go
> for storing my structures. Do you have a practical example on how
> container data item is used?
>
> From the code documentation i can see that:
>
> * Being a mere placeholder/template for other data, an SMWDIContainer
> is not
> * immutable as the other basic data items. New property-value pairs
> can always
> * be added to the internal SMWContainerSemanticData.
>
> so is it correct to assume that in a practical example, in order to
> create a container data item, you actually create a template which holds
> all your other properties (like a set of [[Polygon::...]] properties)?
The word "template" is not well chosen in this documentation. It has
nothing to do with a MW template. When using containers to store data,
they are simply like an "internal wiki page" together with
property-value assignments. Instead of using containers, one could also
create a new wiki page, assign all the data to that wiki page, and then
use the wiki page instead of the Container DI as a property value. But
this would not fit into one property assignment and would require
multiple operations instead. Containers are mainly a convenience
structure so that data for multiple (sub)wikipages can be processed in
one go.
The word "template" comes in when you use a container value as a search
pattern (in queries or in special pages). Then a container can be used
without a subject ("anonymous" subject): in this case the subject's name
does not matter in the search and only the property values of the
container are used to find matches. This is what is meant by "template"
in this sentence.
You can see a short code example on how to create arbitrary container
DIs in the file SMW_Subobject.php (the implementation of the subobject
parser function). This code uses a user-provided name for the subobject.
There is also code in SMW_DV_Record.php that generates an internal name
on the fly by hashing the data (around line 42). Generated names should
start with "_". This allows SMW to decide if a subobject name should be
displayed to users or not.
>
> As i said, i'm quite new to this semantic way of structuring data, so
> please forgive me for not having a better understanding of how all this
> is connected.
>
> And another thing, in which end would you say i should start trying to
> implement my data structure, should i start with the individual
> dataitems/datavalues and then look at creating a container? do i even
> need to create/subclass my own container? or can i use the one already
> defined?
You can use the one that is already defined. In order to store data in a
container, you need properties. You need to register these properties so
that they are available (and have the correct type) without the user
having to create pages for them. Every property has an internal string
ID that you use in the code to address it. It can also have a user-label
that users can write to address it (if no label is given, then users
will never see it and cannot search for it).
Property registration is done in a hook, for example:
$wgHooks['smwInitProperties'][] = 'myinitProperties';
function myinitProperties() {
// Register a user-visible property with ID '___myp':
SMWDIProperty::registerProperty('___myp', '_num', 'Myproperty', true);
// Register an alternative user label for this property:
SMWDIProperty::registerPropertyAlias('___myp', 'My property');
return true;
}
See the documentation for registerProperty() for details. Always call
your own property IDs with three initial underscores to avoid name clashes.
After you registeed properties in this way, you can use them for storing
and retrieving values in the container (if they have a user label, you
can also use them in the wiki; a good way to try if it worked). In PHP,
you can create a property object like this:
$myProperty = new SMWDIProperty('___myp');
Do not use your label but the property ID here. To create a property
from its label, you could use the method
SMWDIProperty::newFromUserLabel(), but this should not be needed. If the
property is registered, SMW will use the right datatype for storing and
retrieving it. If the datatype is changed later on, SMW will not find
old stored values any more (as expected; if you store values as a
string, you don't get them when looking for numbers later on). However,
the problem repairs itself over time (old values get deleted when pages
are stored again).
Moreover, you can add any value for any property in a Container -- it is
not checked if the types are the same (e.g., you can assign a DIString
object to a property that is declared to hold a number). If types are
not the same, the data might simply not be stored, or might be stored in
the wrong place and not be found again. Again, this will repair itself
when correcting the code and not cause permanent problems.
One way to inspect the current database contents is Special:Browse (if
your properties have user labels). To view properties that have no user
label, you can try Special:RDFExport (but this does not have good
support for showing data of subobjects).
That's all! It is a lot of material in the beginning, but it is not that
complicated in the end ... I hope ;-).
Markus
------------------------------
Message: 4
Date: Wed, 23 May 2012 12:49:31 +0200
From: Kim Eik <k...@heldig.org>
Subject: Re: [SMW-devel] Semantic mediawiki and map data
To: semediawiki-devel@lists.sourceforge.net
Message-ID:
<CAC7+dqjeZgAt=j3dpqsqt5m2jrobofc0weexx_avd8y7s2z...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Ok, so i have run into an issue.
A database query syntax error has occurred. This may indicate a bug in the
software. The last attempted database query was:
(SQL query hidden)
from within function "SMW::getPropertySubjects". Database returned error "1103:
Incorrect table name '' (localhost)".
What i have done so far is defined a new property Geographic polygon. and
in my test wiki i tried setting the property [[Has type::Geographical
polygon]]
By doing that i'm now getting this database issue. From what i can gather
i'm missing a database table to store my structure.
In the existing code i can see tht TYPE_GEO is defined as smw_coords which
im guessing is the table name that stores Geographic coordinates.
SMWDataItem::TYPE_GEO => 'smw_coords', // currently created only if
Semantic Maps are installed
Now, how should i proceed to add a table for a polygon?
a polygon is just a collection of coords, so i guess i could use smw_coords
as my main table for storing the coordinates of polygons, and then another
table that refers to smw_coords with a one to many mapping.
And where in the semantic maps extension can i actually find som sql code
that creates the given table?
Oh, and btw, i could use some code review as im piecing this together.
would it be ok if i added the code ive written so far to gerrit? so you
guys can follow my progress line by line? that way you could probably help
me better if other issues arise. So far i have written code for
SemanticMediaWiki and SemanticMaps.
Cheers
On Wed, May 23, 2012 at 11:11 AM, Markus Kr?tzsch <
mar...@semantic-mediawiki.org> wrote:
> On 23/05/12 09:02, Kim Eik wrote:
>
>> >From your descritpion, a container data item looks like the way to go
>> for storing my structures. Do you have a practical example on how
>> container data item is used?
>>
>> From the code documentation i can see that:
>>
>> * Being a mere placeholder/template for other data, an SMWDIContainer
>> is not
>> * immutable as the other basic data items. New property-value pairs
>> can always
>> * be added to the internal SMWContainerSemanticData.
>>
>> so is it correct to assume that in a practical example, in order to
>> create a container data item, you actually create a template which holds
>> all your other properties (like a set of [[Polygon::...]] properties)?
>>
>
> The word "template" is not well chosen in this documentation. It has
> nothing to do with a MW template. When using containers to store data, they
> are simply like an "internal wiki page" together with property-value
> assignments. Instead of using containers, one could also create a new wiki
> page, assign all the data to that wiki page, and then use the wiki page
> instead of the Container DI as a property value. But this would not fit
> into one property assignment and would require multiple operations instead.
> Containers are mainly a convenience structure so that data for multiple
> (sub)wikipages can be processed in one go.
>
> The word "template" comes in when you use a container value as a search
> pattern (in queries or in special pages). Then a container can be used
> without a subject ("anonymous" subject): in this case the subject's name
> does not matter in the search and only the property values of the container
> are used to find matches. This is what is meant by "template" in this
> sentence.
>
> You can see a short code example on how to create arbitrary container DIs
> in the file SMW_Subobject.php (the implementation of the subobject parser
> function). This code uses a user-provided name for the subobject. There is
> also code in SMW_DV_Record.php that generates an internal name on the fly
> by hashing the data (around line 42). Generated names should start with
> "_". This allows SMW to decide if a subobject name should be displayed to
> users or not.
>
>
>
>> As i said, i'm quite new to this semantic way of structuring data, so
>> please forgive me for not having a better understanding of how all this
>> is connected.
>>
>> And another thing, in which end would you say i should start trying to
>> implement my data structure, should i start with the individual
>> dataitems/datavalues and then look at creating a container? do i even
>> need to create/subclass my own container? or can i use the one already
>> defined?
>>
>
> You can use the one that is already defined. In order to store data in a
> container, you need properties. You need to register these properties so
> that they are available (and have the correct type) without the user having
> to create pages for them. Every property has an internal string ID that you
> use in the code to address it. It can also have a user-label that users can
> write to address it (if no label is given, then users will never see it and
> cannot search for it).
>
> Property registration is done in a hook, for example:
>
> $wgHooks['smwInitProperties'][**] = 'myinitProperties';
>
> function myinitProperties() {
> // Register a user-visible property with ID '___myp':
> SMWDIProperty::**registerProperty('___myp', '_num', 'Myproperty', true);
> // Register an alternative user label for this property:
> SMWDIProperty::**registerPropertyAlias('___myp'**, 'My property');
>
> return true;
> }
>
> See the documentation for registerProperty() for details. Always call your
> own property IDs with three initial underscores to avoid name clashes.
>
>
> After you registeed properties in this way, you can use them for storing
> and retrieving values in the container (if they have a user label, you can
> also use them in the wiki; a good way to try if it worked). In PHP, you can
> create a property object like this:
>
> $myProperty = new SMWDIProperty('___myp');
>
> Do not use your label but the property ID here. To create a property from
> its label, you could use the method SMWDIProperty::**newFromUserLabel(),
> but this should not be needed. If the property is registered, SMW will use
> the right datatype for storing and retrieving it. If the datatype is
> changed later on, SMW will not find old stored values any more (as
> expected; if you store values as a string, you don't get them when looking
> for numbers later on). However, the problem repairs itself over time (old
> values get deleted when pages are stored again).
>
> Moreover, you can add any value for any property in a Container -- it is
> not checked if the types are the same (e.g., you can assign a DIString
> object to a property that is declared to hold a number). If types are not
> the same, the data might simply not be stored, or might be stored in the
> wrong place and not be found again. Again, this will repair itself when
> correcting the code and not cause permanent problems.
>
> One way to inspect the current database contents is Special:Browse (if
> your properties have user labels). To view properties that have no user
> label, you can try Special:RDFExport (but this does not have good support
> for showing data of subobjects).
>
> That's all! It is a lot of material in the beginning, but it is not that
> complicated in the end ... I hope ;-).
>
> Markus
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
------------------------------
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
End of Semediawiki-devel Digest, Vol 71, Issue 16
*************************************************
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
