On 27 August 2011 03:22, badon <fastgoldfish@...> wrote:
>
> OK, I think you just told me something that's going to lead to an epiphany on
> my end, but I need some contextual definitions first:
>
> * class
> * sub-class
> * instance
Sorry, these are terms from data modelling (or abuses of them). Here
is a doc I forgot I wrote on the topic of modelling in SMW from the
perspective of a relational database (or excel spreadsheet... (why
not)):
http://seqanswers.com/wiki/Semantic_MediaWiki/Overview
I extended this document here:
http://smw.referata.com/wiki/Overview_of_Semantic_MediaWiki_and_Semantic_Forms
Saruman also wrote a nice doc about 'Classes and Properties in SMW':
http://semantic-mediawiki.org/wiki/Semantic_MediaWiki_concepts
I'd like to write this all up coherently, but I haven't found the time
or the place to do it.
> * floating forms
Check this mailing list.
> I think you're saying that I should be OK with breaking things up sort of
> into modules that perform various functions in order to produce a navigable
> set of data. I'm already doing that to a degree, but I'm trying to bring all
> that data into one place for viewing.
>
> Plus, since SMW does not traverse property chains very well beyond the most
> immediate neighbors, especially in the backwards direction, I'm
> uncomfortable with getting to crazy with putting data too far away from
> where it is most useful.
Well, it can be good to focus on more fundamental design flaws rather
than jumping through hoops to circumvent them.
> Right now, the best example I have of what I'm doing is with images. On any
> wiki entry for an object, a person can upload a file using semantic forms.
> Clicking the link I have made for this will allow someone to just upload and
> name the file, without knowing much about what's going on behind the scenes.
> Behind the scenes, I'm assigning a "Belongs to" property to the image so
> that the main object page knows who its child images are, and can display
> those images automatically. The user does not even need to know how to make
> a wiki image link, though that can do that too if they choose.
Sounds good.
> I suppose I could do the same thing with the object serial number, but that
> has issues stemming from the order in which data is to be entered.
>
> In the example above, images are the last thing that gets entered, so I can
> easily prefill all the needed information to make it brain-dead simple for
> anyone with no wiki familiarity to do in just a few quick steps.
>
> I've done a similar thing with creating new object entries in the wiki. You
> just go to an object like the one you want to enter, and click a link that
> says something to the effect of "Add an object like this". Then, the user is
> shown a form where all the non-unique information is prefilled for them. The
> don't need to have any understanding of what info goes with what types of
> objects, etc.
>
> That only works as long as there are no intervening steps. You have to go
> directly from an object page to a prefilled form for a new, similar object,
> in order to get the data that's going to be prefilled. There's a fair bit of
> info that needs to be entered in, and even I am finding it most convenient
> to do it this way, despite having the ability to do it the hard way if
> needed. Unexperienced users can add hundreds of new entries per hour if they
> choose to do so, which allows the wiki to be a very comprehensive source of
> info.
>
> Since the serial number must be checked before anything else is done, I
> can't prefill the form with info from a similar object that referred the
> user to enter in a new object. At least not easily. If I created a page only
> for the serial number to be used for dupe checking, and then duplicated all
> the properties that's supposed to be prefilled, I could grab that info to be
> used in the next step of actually entering in the new data.
>
> It's doable, I guess, but it sure seems like the hard way. Still, is this
> close to the approach that you seem to be suggesting?
I get the idea of 'create a similar object', but I have no idea why
this involves serial numbers or entering in lots of info.
> By breaking out the serial number into its own page, similar to the way
> images are already (necessarily) handled on their own pages, I could use
> that serial number page to check for uniqueness, and to perform the task of
> sending the user to the next step of actually entering new data, if it does
> not already exist.
>
> Is any of this making sense? I hope I'm describing this well, and not
> completely off base with what you were trying to tell me.
I don't really follow without concrete examples.
> I have very little familiarity with SIO, and I'm not sure if it can help me,
> or how I would work that into my system.
RTFM ;-)
> Thanks for your help, I really appreciate it.
No problem! This is a mailing list set up so people can help people.
It would be weird if I didn't try to help!
Cheers,
Dan.
> Dan Bolser-3 wrote:
>>
>> On 24 August 2011 19:32, badon <fastgoldfish@...> wrote:
>>>
>>> As far as I know, there is not currently a way to check to see if form
>>> information has already been entered into a wiki, when using Semantic
>>> Forms.
>>> I filed a bug report feature request here, to address that:
>>>
>>> https://bugzilla.wikimedia.org/show_bug.cgi?id=30537
>>>
>>> In the meantime, I need to find a workaround.
>>>
>>> I have a case where forms are being used to enter information about
>>> objects
>>> that have a unique serial number property. When users enter in a new
>>> object,
>>> I'd like to have a form to check whether there is already an existing
>>> object
>>> that has the same serial number as the one that a user would like to
>>> enter
>>> in. The serial number property should always be unique, with only one
>>> existing on the wiki.
>>>
>>> I'm hoping there's a workaround possible where form 1 can take the serial
>>> number, and then branch either to the existing page containing that
>>> property, or to a new form 2 where the rest of the information can be
>>> entered in, and the serial number is already prefilled from the previous
>>> form.
>>>
>>> I'm not sure how to do that.
>>>
>>> It seems that I would need some way to check for the existence of a
>>> serial
>>> number property with a specific value. That could be done if the serial
>>> number property were a page with a redirect to the object's page that has
>>> that serial number. But, if that page does not exist, how do I get to
>>> form
>>> 2?
>>>
>>> Then, once at form 2, it would have to create both the object page, and
>>> the
>>> redirected serial number page. Is that possible?
>>>
>>> I know about the #ifexist parser function, and the ability for Semantic
>>> Forms to check for the existence of a page title (but not properties), to
>>> be
>>> created with the form if it does not already exist. Right now, the only
>>> workaround I can think of would be to have the user go to a Semantic Form
>>> to
>>> enter in the serial number first. The form would then either make a page
>>> with a title that matches the value for the serial number property, or
>>> take
>>> the user to the existing page.
>>>
>>> Yaron suggested that the page itself could contain a form, which could be
>>> the form for completing the data-entry process for that serial number:
>>>
>>> http://old.nabble.com/Nested-Forms-to32052038.html
>>>
>>> But, that would result in a doubling of the number of pages on a wiki,
>>> which
>>> is a messy way to work around this problem. And, I don't think it's
>>> possible
>>
>> I remember having this concern when I first started using SMW after
>> using MW for a long time. You need to create pages in the wiki when
>> you need to create pages in the wiki. Don't think of more pages as
>> messy and less pages as neat.
>>
>> It comes down to how you model your data in your wiki, and, sorry to
>> say, the problem that you're describing seems to come back down to a
>> bad model.
>>
>> Try to stick to thinking about one form = one class, one page = one
>> instance. Use queries and links let users navigate the data-structure.
>> As soon as you start trying to overload forms with multiple classes or
>> multiple pages, it gets complex, and frankly, beyond the scope of SMW.
>>
>> The only exception to the above is the ability to add SIO
>> 'sub-classes' to a page. This way you have your user fill in one
>> 'master' form, then, on the resulting page, present links to add
>> sub-classes (sorry if I'm abusing the term 'sub-classes', what I mean
>> is, a class that strictly has a 1 to 1 relationship with the 'parent'
>> class, see SIO [1] for examples).
>>
>> There is no problem setting up 'relations' between the class and it's
>> sub-classes to display the data in any way you like, and using
>> floating forms to populate the SIO objects, the user experience isn't
>> bad either.
>>
>>
>> HTH,
>> Dan.
>>
>> [1] http://www.mediawiki.org/wiki/Extension:Semantic_Internal_Objects
>>
>> ------------------------------------------------------------------------------
>> EMC VNX: the world's simplest storage, starting under $10K
>> The only unified storage solution that offers unified management
>> Up to 160% more powerful than alternatives and 25% more efficient.
>> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
>> _______________________________________________
>> Semediawiki-user mailing list
>> Semediawiki-user@...
>> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
>>
>>
>
> --
> View this message in context: http://old.nabble.com/-SF--How-to-check-for-a-previously-existing-property--tp32328729p32345960.html
> Sent from the Semantic Mediawiki - User mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management
> Up to 160% more powerful than alternatives and 25% more efficient.
> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> _______________________________________________
> Semediawiki-user mailing list
> Semediawiki-user@...
> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
>
|