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