Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(9) |
Nov
(2) |
Dec
(19) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(9) |
Feb
(9) |
Mar
(14) |
Apr
(23) |
May
(76) |
Jun
(20) |
Jul
(25) |
Aug
(22) |
Sep
(15) |
Oct
(24) |
Nov
(12) |
Dec
(15) |
2007 |
Jan
(2) |
Feb
(17) |
Mar
(32) |
Apr
(39) |
May
(38) |
Jun
(11) |
Jul
(19) |
Aug
(39) |
Sep
(33) |
Oct
(61) |
Nov
(67) |
Dec
(90) |
2008 |
Jan
(47) |
Feb
(67) |
Mar
(112) |
Apr
(39) |
May
(22) |
Jun
(107) |
Jul
(85) |
Aug
(103) |
Sep
(63) |
Oct
(58) |
Nov
(28) |
Dec
(15) |
2009 |
Jan
(103) |
Feb
(35) |
Mar
(66) |
Apr
(38) |
May
(26) |
Jun
(16) |
Jul
(128) |
Aug
(97) |
Sep
(39) |
Oct
(16) |
Nov
(33) |
Dec
(26) |
2010 |
Jan
(50) |
Feb
(73) |
Mar
(95) |
Apr
(28) |
May
(60) |
Jun
(76) |
Jul
(78) |
Aug
(54) |
Sep
(55) |
Oct
(25) |
Nov
(74) |
Dec
(36) |
2011 |
Jan
(25) |
Feb
(57) |
Mar
(109) |
Apr
(68) |
May
(51) |
Jun
(41) |
Jul
(47) |
Aug
(50) |
Sep
(50) |
Oct
(89) |
Nov
(85) |
Dec
(31) |
2012 |
Jan
(30) |
Feb
(42) |
Mar
(29) |
Apr
(27) |
May
(92) |
Jun
(57) |
Jul
(113) |
Aug
(33) |
Sep
(45) |
Oct
(100) |
Nov
(74) |
Dec
(45) |
2013 |
Jan
(24) |
Feb
(93) |
Mar
(65) |
Apr
(62) |
May
(100) |
Jun
(64) |
Jul
(25) |
Aug
(44) |
Sep
(24) |
Oct
(50) |
Nov
(173) |
Dec
(32) |
2014 |
Jan
(42) |
Feb
(13) |
Mar
(26) |
Apr
(3) |
May
(35) |
Jun
(16) |
Jul
(54) |
Aug
(23) |
Sep
(25) |
Oct
(35) |
Nov
(31) |
Dec
(7) |
2015 |
Jan
(11) |
Feb
(6) |
Mar
(28) |
Apr
(16) |
May
(10) |
Jun
(15) |
Jul
(20) |
Aug
(3) |
Sep
(8) |
Oct
(19) |
Nov
(17) |
Dec
(5) |
2016 |
Jan
(14) |
Feb
(4) |
Mar
|
Apr
(7) |
May
(3) |
Jun
(5) |
Jul
(5) |
Aug
(6) |
Sep
(9) |
Oct
(10) |
Nov
(3) |
Dec
(12) |
2017 |
Jan
(7) |
Feb
(3) |
Mar
(12) |
Apr
(2) |
May
(1) |
Jun
(8) |
Jul
(27) |
Aug
(19) |
Sep
(8) |
Oct
(2) |
Nov
(3) |
Dec
(3) |
2018 |
Jan
(5) |
Feb
(3) |
Mar
(1) |
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(1) |
2
(2) |
3
(5) |
4
(2) |
5
(1) |
6
|
7
|
8
(2) |
9
(4) |
10
|
11
(2) |
12
(2) |
13
|
14
(1) |
15
|
16
|
17
|
18
(1) |
19
|
20
(9) |
21
(6) |
22
|
23
|
24
|
25
|
26
(10) |
27
(12) |
28
(3) |
29
(1) |
30
|
|
|
|
|
|
|
From: Yaron Koren <yaron@wi...> - 2013-06-20 18:32:28
|
Hi Stephan, For the duplicate data thing: you're right that duplicate data is never a good idea; I was wrong about that. Still, in practical terms I really don't think it matters whether the duplicate data gets stored or not. Duplicate data just doesn't happen very much, if at all; and even when it happens, that's an error in data entry: SMW doesn't have any obligation to fix such errors. (I think all of this is somewhat incidental, actually, because however the index gets stored, there should always be a way to prevent duplicates using the hash.) As for whether storing the index, whether it's part of the subobject name or in a "Has index" property, changes the data model - I don't think it does. You can simply ignore the index value; I would just think of it as additional data that can either be used or not. If you didn't like my "Modification date" example, how about this: the subobject hash itself is some additional, SMW-only data that gets added to each row, but that doesn't affect the data model either. -Yaron On Thu, Jun 20, 2013 at 2:04 PM, Stephan Gambke <s7eph4n@...> wrote: > Hi Yaron, > > I did not propose a general 'has index' property. In fact, I would > strongly advise against it. Your recipe example is a good one for a case > where an index does not make sense and implying one would be wrong. > > For the students example: If your data model identifies students by their > name alone, then again the data model is insufficient, not SMW. Basically > your statement is 'John has a score of 2'. If you repeat that statement, > then a natural person will tell you that you already said that. SMW will > drop the second statement. If you actually want both of these statements > stored you better think of a way to disambiguate. > > On the point of the index number being or not being a part of the data > model: > That has nothing to do at all with wether it comes from a user input or > not. You should first build you data model. I do not say that it should not > contain index numbers. If you need them, by all means include them. But do > so explicitly. Don't just include them in all data model just because they > are useful in some cases. Then, when you have your data model, think about > how to use it. E.g. how to assign those index numbers. They can for sure > come from a user input. They might as well be assigned somehow > automatically. I don't care. > > The order of the elements may be controllable by the user. But deriving > the order of the elements from that in the model is wrong. When the user > says he needs eggs, milk and flour then you should not translate that into > 'first eggs, second milk and finally flour'. The correct translation would > be 'eggs, milk and sugar and by the way he ordered eggs first, milk second > and sugar third'. This means you will end up with six statements - three on > the ingredients and three on the statements on the ingredients. Do not mix > them. > > Regarding Modification date: There is quite a difference. The modification > date is a statement on a subject (the wiki page) that is stored with the > subject, but without modifying it. Storing the index number of a statement > the way you propose, _would_ modify the statement. So, nothing broken with > the Modification date, with that index, though... > > Cheers, > Stephan > > On Jun 20, 2013 7:02 PM, "Yaron Koren" <yaron@...> wrote: > > > Stephan - you make some good points. As far as displaying the > number/index in queries - that sounds interesting, though even a separate > "Has index" property might not necessarily be ideal for that. If you have > two or more different kinds of #subobject calls on a page, it might not > work out nicely. For instance, a recipe page might have subobjects for > ingredients, and then subobjects for instructions. In that case, the > ingredients might have "Has index" values of 1-10, and then the > instructions might have "Has index" values of 11-15. (That's how numbering > used to work in SIO.) So displaying this property might just look weird. > > > > Your second point is that the hash system lets SMW only display unique > subobjects. Which is true, but (a) in my experience that's not a major > issue, and (b) actually, sometimes you really do want to store duplicate > data. What if you have a page of test scores, and you use #subobject to > store each student's name and their score, and two students happen to have > the same name and the same score? (Let's say that there aren't wiki pages > for each student, which would force you to disambiguate.) Duplicate data > might not be an error - it might be valid data. > > > > You seem to also make the point that, because it hasn't been entered by > a user, the index/number isn't truly a part of the data model, and > shouldn't be stored at all. Assuming you are in fact making that point, > it's a reasonable opinion, but I disagree, for two reasons: (1) the order > of elements is something that users can control, and thus, it is actually > implicitly part of the data model, and (2) SMW already stores a bunch of > stuff that's even less a part of the data model: the "Modification date" > property, etc. You could say that two wrongs don't make a right (to use an > expression), but at the very least, this wouldn't be breaking anything > that's not already broken. Again, though, I'm not sure if that's what you > were getting at. > > > > -Yaron > > > > On Thu, Jun 20, 2013 at 12:37 PM, Stephan Gambke <s7eph4n@...> > wrote: > >> > >> Hi Yaron, > >> > >> I do not think that your approach will work. > >> > >> At a first glance it seems to be an easy way out to provide sorting. > >> > >> But from a software engineering point of view it loads the identifier > with information that just does not belong there. From a practical point of > view it falls short if anybody wants to query that number. And finally from > a semantic point of view it inseparably mixes two statements (the original > one and the one about the sequence number) that the originator usually does > not want to be mixed. > >> > >> This last problem btw is also the key to your question about the > determination of the hash key. To state the same thing twice is just that: > A duplicate statement. As opposed to two statements. To my best knowledge > SMW will not store such a statement twice. Instead it will generate the > hash key based on the property and value and if that hash already exists, > then the statement it represents is considered already known and the second > occurrence will be dropped and not appear in any query results. I am not > sure if this is also true for subjects, but it really should be. > >> > >> So, long story short: If your data model for project management does > not explicitly contain the sequence number for the activities, then your > model is incomplete, not SMW. In fact, should two activities be exactly the > same, you will probably lose one of them. > >> > >> Cheers, > >> Stephan > >> > >> On Jun 20, 2013 5:30 PM, "Yaron Koren" <yaron@...> wrote: > >>> > >>> Hi Alexey, > >>> > >>> Yes, that's a good point - I actually thought about an approach like > that, but forgot to include it in the email. A property called "Sort" (a > name like "Has index" might be a little clearer) would solve this problem - > and it would be a more "semantic" solution. On the other hand, it would add > to the proliferation of special properties (for what that's worth), and it > would mean a little more work for administrators to get queries of > subobjects ordered correctly. > >>> > >>> I still think my original proposed solution would work fine, though I > confess I don't quite understand how the subobject hashing works. Are > people supposed to be able to directly link to or reference a subobject, > using the hash? I don't see how that could work, given that everything > about a subobject could change from one page save to the next - its order, > its properties, etc. I don't see how the system could keep consistency of > subobject naming. > >>> > >>> -Yaron > >>> > >>> On Thu, Jun 20, 2013 at 10:54 AM, Alexey Klimovich < > god.vedmaka@...> wrote: > >>>> > >>>> Hi, Yaron! > >>>> > >>>> I think subobjects sorting is good task, but i suggest not to use > subobjects > >>>> name for this because of big problem with that: > >>>> > >>>> imagine we have 3 subobjects on page: > >>>> > >>>> Page name#001_4bd1f1b74a76de5322dd74956a71f089 > >>>> Page name#002_03163dfd1d2502668b00c1f521688984 > >>>> Page name#003_02dwa3j349j8d3jds3843234jd8349490 > >>>> > >>>> now, we edit page, delete subobject 002. What should happen? > >>>> Should other subobjects be renamed to keep sorting? What if they > already > >>>> linked from other pages/queries? > >>>> > >>>> I think better way is to automaticaly attach some semantic property > ("Sort" > >>>> for example) > >>>> to every subobject on page. This property should contain subobjects > number > >>>> on page. > >>>> > >>>> > >>>> > >>>> -- > >>>> View this message in context: > http://wikimedia.7.x6.nabble.com/Making-subobjects-correctly-ordered-tp5007553p5007558.html > >>>> Sent from the Semantic Mediawiki - Development mailing list archive > at Nabble.com. > >>>> > >>>> > ------------------------------------------------------------------------------ > >>>> This SF.net email is sponsored by Windows: > >>>> > >>>> Build for Windows Store. > >>>> > >>>> http://p.sf.net/sfu/windows-dev2dev > >>>> _______________________________________________ > >>>> Semediawiki-devel mailing list > >>>> Semediawiki-devel@... > >>>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > >>> > >>> > >>> > >>> > >>> -- > >>> WikiWorks · MediaWiki Consulting · http://wikiworks.com > >>> > >>> > ------------------------------------------------------------------------------ > >>> This SF.net email is sponsored by Windows: > >>> > >>> Build for Windows Store. > >>> > >>> http://p.sf.net/sfu/windows-dev2dev > >>> _______________________________________________ > >>> Semediawiki-devel mailing list > >>> Semediawiki-devel@... > >>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > >>> > > > > > > > > -- > > WikiWorks · MediaWiki Consulting · http://wikiworks.com > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Stephan Gambke <s7eph4n@gm...> - 2013-06-20 18:04:46
|
Hi Yaron, I did not propose a general 'has index' property. In fact, I would strongly advise against it. Your recipe example is a good one for a case where an index does not make sense and implying one would be wrong. For the students example: If your data model identifies students by their name alone, then again the data model is insufficient, not SMW. Basically your statement is 'John has a score of 2'. If you repeat that statement, then a natural person will tell you that you already said that. SMW will drop the second statement. If you actually want both of these statements stored you better think of a way to disambiguate. On the point of the index number being or not being a part of the data model: That has nothing to do at all with wether it comes from a user input or not. You should first build you data model. I do not say that it should not contain index numbers. If you need them, by all means include them. But do so explicitly. Don't just include them in all data model just because they are useful in some cases. Then, when you have your data model, think about how to use it. E.g. how to assign those index numbers. They can for sure come from a user input. They might as well be assigned somehow automatically. I don't care. The order of the elements may be controllable by the user. But deriving the order of the elements from that in the model is wrong. When the user says he needs eggs, milk and flour then you should not translate that into 'first eggs, second milk and finally flour'. The correct translation would be 'eggs, milk and sugar and by the way he ordered eggs first, milk second and sugar third'. This means you will end up with six statements - three on the ingredients and three on the statements on the ingredients. Do not mix them. Regarding Modification date: There is quite a difference. The modification date is a statement on a subject (the wiki page) that is stored with the subject, but without modifying it. Storing the index number of a statement the way you propose, _would_ modify the statement. So, nothing broken with the Modification date, with that index, though... Cheers, Stephan On Jun 20, 2013 7:02 PM, "Yaron Koren" <yaron@...> wrote: > Stephan - you make some good points. As far as displaying the number/index in queries - that sounds interesting, though even a separate "Has index" property might not necessarily be ideal for that. If you have two or more different kinds of #subobject calls on a page, it might not work out nicely. For instance, a recipe page might have subobjects for ingredients, and then subobjects for instructions. In that case, the ingredients might have "Has index" values of 1-10, and then the instructions might have "Has index" values of 11-15. (That's how numbering used to work in SIO.) So displaying this property might just look weird. > > Your second point is that the hash system lets SMW only display unique subobjects. Which is true, but (a) in my experience that's not a major issue, and (b) actually, sometimes you really do want to store duplicate data. What if you have a page of test scores, and you use #subobject to store each student's name and their score, and two students happen to have the same name and the same score? (Let's say that there aren't wiki pages for each student, which would force you to disambiguate.) Duplicate data might not be an error - it might be valid data. > > You seem to also make the point that, because it hasn't been entered by a user, the index/number isn't truly a part of the data model, and shouldn't be stored at all. Assuming you are in fact making that point, it's a reasonable opinion, but I disagree, for two reasons: (1) the order of elements is something that users can control, and thus, it is actually implicitly part of the data model, and (2) SMW already stores a bunch of stuff that's even less a part of the data model: the "Modification date" property, etc. You could say that two wrongs don't make a right (to use an expression), but at the very least, this wouldn't be breaking anything that's not already broken. Again, though, I'm not sure if that's what you were getting at. > > -Yaron > > On Thu, Jun 20, 2013 at 12:37 PM, Stephan Gambke <s7eph4n@...> wrote: >> >> Hi Yaron, >> >> I do not think that your approach will work. >> >> At a first glance it seems to be an easy way out to provide sorting. >> >> But from a software engineering point of view it loads the identifier with information that just does not belong there. From a practical point of view it falls short if anybody wants to query that number. And finally from a semantic point of view it inseparably mixes two statements (the original one and the one about the sequence number) that the originator usually does not want to be mixed. >> >> This last problem btw is also the key to your question about the determination of the hash key. To state the same thing twice is just that: A duplicate statement. As opposed to two statements. To my best knowledge SMW will not store such a statement twice. Instead it will generate the hash key based on the property and value and if that hash already exists, then the statement it represents is considered already known and the second occurrence will be dropped and not appear in any query results. I am not sure if this is also true for subjects, but it really should be. >> >> So, long story short: If your data model for project management does not explicitly contain the sequence number for the activities, then your model is incomplete, not SMW. In fact, should two activities be exactly the same, you will probably lose one of them. >> >> Cheers, >> Stephan >> >> On Jun 20, 2013 5:30 PM, "Yaron Koren" <yaron@...> wrote: >>> >>> Hi Alexey, >>> >>> Yes, that's a good point - I actually thought about an approach like that, but forgot to include it in the email. A property called "Sort" (a name like "Has index" might be a little clearer) would solve this problem - and it would be a more "semantic" solution. On the other hand, it would add to the proliferation of special properties (for what that's worth), and it would mean a little more work for administrators to get queries of subobjects ordered correctly. >>> >>> I still think my original proposed solution would work fine, though I confess I don't quite understand how the subobject hashing works. Are people supposed to be able to directly link to or reference a subobject, using the hash? I don't see how that could work, given that everything about a subobject could change from one page save to the next - its order, its properties, etc. I don't see how the system could keep consistency of subobject naming. >>> >>> -Yaron >>> >>> On Thu, Jun 20, 2013 at 10:54 AM, Alexey Klimovich < god.vedmaka@...> wrote: >>>> >>>> Hi, Yaron! >>>> >>>> I think subobjects sorting is good task, but i suggest not to use subobjects >>>> name for this because of big problem with that: >>>> >>>> imagine we have 3 subobjects on page: >>>> >>>> Page name#001_4bd1f1b74a76de5322dd74956a71f089 >>>> Page name#002_03163dfd1d2502668b00c1f521688984 >>>> Page name#003_02dwa3j349j8d3jds3843234jd8349490 >>>> >>>> now, we edit page, delete subobject 002. What should happen? >>>> Should other subobjects be renamed to keep sorting? What if they already >>>> linked from other pages/queries? >>>> >>>> I think better way is to automaticaly attach some semantic property ("Sort" >>>> for example) >>>> to every subobject on page. This property should contain subobjects number >>>> on page. >>>> >>>> >>>> >>>> -- >>>> View this message in context: http://wikimedia.7.x6.nabble.com/Making-subobjects-correctly-ordered-tp5007553p5007558.html >>>> Sent from the Semantic Mediawiki - Development mailing list archive at Nabble.com. >>>> >>>> ------------------------------------------------------------------------------ >>>> This SF.net email is sponsored by Windows: >>>> >>>> Build for Windows Store. >>>> >>>> http://p.sf.net/sfu/windows-dev2dev >>>> _______________________________________________ >>>> Semediawiki-devel mailing list >>>> Semediawiki-devel@... >>>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >>> >>> >>> >>> >>> -- >>> WikiWorks · MediaWiki Consulting · http://wikiworks.com >>> >>> ------------------------------------------------------------------------------ >>> This SF.net email is sponsored by Windows: >>> >>> Build for Windows Store. >>> >>> http://p.sf.net/sfu/windows-dev2dev >>> _______________________________________________ >>> Semediawiki-devel mailing list >>> Semediawiki-devel@... >>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >>> > > > > -- > WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Yaron Koren <yaron@wi...> - 2013-06-20 17:03:06
|
Hi, Alexey - as Stephan notes, the hash is based on the set of parameters to #subobject, which means that if you even change one value the hash will (I think) change. Which means that linking/referencing a specific subobject based on its hash is not that good of a long-term strategy, I don't think. Though I find it strange to do that kind of thing in the first place, anyway - if something is going to be linked to/discussed directly, as opposed to just aggregated, I would think it should have a true name. But I don't know what the data you're talking about is. Jamie - your usage sounds interesting, but I think not relevant to this discussion, since you don't need to sort based on entry order. Stephan - you make some good points. As far as displaying the number/index in queries - that sounds interesting, though even a separate "Has index" property might not necessarily be ideal for that. If you have two or more different kinds of #subobject calls on a page, it might not work out nicely. For instance, a recipe page might have subobjects for ingredients, and then subobjects for instructions. In that case, the ingredients might have "Has index" values of 1-10, and then the instructions might have "Has index" values of 11-15. (That's how numbering used to work in SIO.) So displaying this property might just look weird. Your second point is that the hash system lets SMW only display unique subobjects. Which is true, but (a) in my experience that's not a major issue, and (b) actually, sometimes you really do want to store duplicate data. What if you have a page of test scores, and you use #subobject to store each student's name and their score, and two students happen to have the same name and the same score? (Let's say that there aren't wiki pages for each student, which would force you to disambiguate.) Duplicate data might not be an error - it might be valid data. You seem to also make the point that, because it hasn't been entered by a user, the index/number isn't truly a part of the data model, and shouldn't be stored at all. Assuming you are in fact making that point, it's a reasonable opinion, but I disagree, for two reasons: (1) the order of elements is something that users can control, and thus, it is actually implicitly part of the data model, and (2) SMW already stores a bunch of stuff that's even less a part of the data model: the "Modification date" property, etc. You could say that two wrongs don't make a right (to use an expression), but at the very least, this wouldn't be breaking anything that's not already broken. Again, though, I'm not sure if that's what you were getting at. -Yaron On Thu, Jun 20, 2013 at 12:37 PM, Stephan Gambke <s7eph4n@...> wrote: > Hi Yaron, > > I do not think that your approach will work. > > At a first glance it seems to be an easy way out to provide sorting. > > But from a software engineering point of view it loads the identifier with > information that just does not belong there. From a practical point of view > it falls short if anybody wants to query that number. And finally from a > semantic point of view it inseparably mixes two statements (the original > one and the one about the sequence number) that the originator usually does > not want to be mixed. > > This last problem btw is also the key to your question about the > determination of the hash key. To state the same thing twice is just that: > A duplicate statement. As opposed to two statements. To my best knowledge > SMW will not store such a statement twice. Instead it will generate the > hash key based on the property and value and if that hash already exists, > then the statement it represents is considered already known and the second > occurrence will be dropped and not appear in any query results. I am not > sure if this is also true for subjects, but it really should be. > > So, long story short: If your data model for project management does not > explicitly contain the sequence number for the activities, then your model > is incomplete, not SMW. In fact, should two activities be exactly the same, > you will probably lose one of them. > > Cheers, > Stephan > On Jun 20, 2013 5:30 PM, "Yaron Koren" <yaron@...> wrote: > >> Hi Alexey, >> >> Yes, that's a good point - I actually thought about an approach like >> that, but forgot to include it in the email. A property called "Sort" (a >> name like "Has index" might be a little clearer) would solve this problem - >> and it would be a more "semantic" solution. On the other hand, it would add >> to the proliferation of special properties (for what that's worth), and it >> would mean a little more work for administrators to get queries of >> subobjects ordered correctly. >> >> I still think my original proposed solution would work fine, though I >> confess I don't quite understand how the subobject hashing works. Are >> people supposed to be able to directly link to or reference a subobject, >> using the hash? I don't see how that could work, given that everything >> about a subobject could change from one page save to the next - its order, >> its properties, etc. I don't see how the system could keep consistency of >> subobject naming. >> >> -Yaron >> >> On Thu, Jun 20, 2013 at 10:54 AM, Alexey Klimovich <god.vedmaka@... >> > wrote: >> >>> Hi, Yaron! >>> >>> I think subobjects sorting is good task, but i suggest not to use >>> subobjects >>> name for this because of big problem with that: >>> >>> imagine we have 3 subobjects on page: >>> >>> Page name#001_4bd1f1b74a76de5322dd74956a71f089 >>> Page name#002_03163dfd1d2502668b00c1f521688984 >>> Page name#003_02dwa3j349j8d3jds3843234jd8349490 >>> >>> now, we edit page, delete subobject 002. What should happen? >>> Should other subobjects be renamed to keep sorting? What if they already >>> linked from other pages/queries? >>> >>> I think better way is to automaticaly attach some semantic property >>> ("Sort" >>> for example) >>> to every subobject on page. This property should contain subobjects >>> number >>> on page. >>> >>> >>> >>> -- >>> View this message in context: >>> http://wikimedia.7.x6.nabble.com/Making-subobjects-correctly-ordered-tp5007553p5007558.html >>> Sent from the Semantic Mediawiki - Development mailing list archive at >>> Nabble.com. >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.net email is sponsored by Windows: >>> >>> Build for Windows Store. >>> >>> http://p.sf.net/sfu/windows-dev2dev >>> _______________________________________________ >>> Semediawiki-devel mailing list >>> Semediawiki-devel@... >>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >>> >> >> >> >> -- >> WikiWorks · MediaWiki Consulting · http://wikiworks.com >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by Windows: >> >> Build for Windows Store. >> >> http://p.sf.net/sfu/windows-dev2dev >> _______________________________________________ >> Semediawiki-devel mailing list >> Semediawiki-devel@... >> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >> >> -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Stephan Gambke <s7eph4n@gm...> - 2013-06-20 16:37:28
|
Hi Yaron, I do not think that your approach will work. At a first glance it seems to be an easy way out to provide sorting. But from a software engineering point of view it loads the identifier with information that just does not belong there. From a practical point of view it falls short if anybody wants to query that number. And finally from a semantic point of view it inseparably mixes two statements (the original one and the one about the sequence number) that the originator usually does not want to be mixed. This last problem btw is also the key to your question about the determination of the hash key. To state the same thing twice is just that: A duplicate statement. As opposed to two statements. To my best knowledge SMW will not store such a statement twice. Instead it will generate the hash key based on the property and value and if that hash already exists, then the statement it represents is considered already known and the second occurrence will be dropped and not appear in any query results. I am not sure if this is also true for subjects, but it really should be. So, long story short: If your data model for project management does not explicitly contain the sequence number for the activities, then your model is incomplete, not SMW. In fact, should two activities be exactly the same, you will probably lose one of them. Cheers, Stephan On Jun 20, 2013 5:30 PM, "Yaron Koren" <yaron@...> wrote: > Hi Alexey, > > Yes, that's a good point - I actually thought about an approach like that, > but forgot to include it in the email. A property called "Sort" (a name > like "Has index" might be a little clearer) would solve this problem - and > it would be a more "semantic" solution. On the other hand, it would add to > the proliferation of special properties (for what that's worth), and it > would mean a little more work for administrators to get queries of > subobjects ordered correctly. > > I still think my original proposed solution would work fine, though I > confess I don't quite understand how the subobject hashing works. Are > people supposed to be able to directly link to or reference a subobject, > using the hash? I don't see how that could work, given that everything > about a subobject could change from one page save to the next - its order, > its properties, etc. I don't see how the system could keep consistency of > subobject naming. > > -Yaron > > On Thu, Jun 20, 2013 at 10:54 AM, Alexey Klimovich <god.vedmaka@...>wrote: > >> Hi, Yaron! >> >> I think subobjects sorting is good task, but i suggest not to use >> subobjects >> name for this because of big problem with that: >> >> imagine we have 3 subobjects on page: >> >> Page name#001_4bd1f1b74a76de5322dd74956a71f089 >> Page name#002_03163dfd1d2502668b00c1f521688984 >> Page name#003_02dwa3j349j8d3jds3843234jd8349490 >> >> now, we edit page, delete subobject 002. What should happen? >> Should other subobjects be renamed to keep sorting? What if they already >> linked from other pages/queries? >> >> I think better way is to automaticaly attach some semantic property >> ("Sort" >> for example) >> to every subobject on page. This property should contain subobjects number >> on page. >> >> >> >> -- >> View this message in context: >> http://wikimedia.7.x6.nabble.com/Making-subobjects-correctly-ordered-tp5007553p5007558.html >> Sent from the Semantic Mediawiki - Development mailing list archive at >> Nabble.com. >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by Windows: >> >> Build for Windows Store. >> >> http://p.sf.net/sfu/windows-dev2dev >> _______________________________________________ >> Semediawiki-devel mailing list >> Semediawiki-devel@... >> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >> > > > > -- > WikiWorks · MediaWiki Consulting · http://wikiworks.com > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Semediawiki-devel mailing list > Semediawiki-devel@... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > |
From: Jamie Thingelstad <jamie@th...> - 2013-06-20 16:20:38
|
I often will put "Has label" or "Has name" as well as a "Has subobject type" properties on my subobjects along with a "Has parent". Pretty common to then filter on "Has subobject type" and "Has parent" and sort by "Has name". As far as the visual clutter in browse, I usually use something about the subobject to give it a name that is meaningful. I almost never let it just use the hashes since I can't find anything when debugging/testing. Jamie Thingelstad jamie@... mobile: 612-810-3699 find me on AIM Twitter Facebook LinkedIn On Jun 20, 2013, at 10:29 AM, Yaron Koren <yaron@...> wrote: > Hi Alexey, > > Yes, that's a good point - I actually thought about an approach like that, but forgot to include it in the email. A property called "Sort" (a name like "Has index" might be a little clearer) would solve this problem - and it would be a more "semantic" solution. On the other hand, it would add to the proliferation of special properties (for what that's worth), and it would mean a little more work for administrators to get queries of subobjects ordered correctly. > > I still think my original proposed solution would work fine, though I confess I don't quite understand how the subobject hashing works. Are people supposed to be able to directly link to or reference a subobject, using the hash? I don't see how that could work, given that everything about a subobject could change from one page save to the next - its order, its properties, etc. I don't see how the system could keep consistency of subobject naming. > > -Yaron > > On Thu, Jun 20, 2013 at 10:54 AM, Alexey Klimovich <god.vedmaka@...> wrote: > Hi, Yaron! > > I think subobjects sorting is good task, but i suggest not to use subobjects > name for this because of big problem with that: > > imagine we have 3 subobjects on page: > > Page name#001_4bd1f1b74a76de5322dd74956a71f089 > Page name#002_03163dfd1d2502668b00c1f521688984 > Page name#003_02dwa3j349j8d3jds3843234jd8349490 > > now, we edit page, delete subobject 002. What should happen? > Should other subobjects be renamed to keep sorting? What if they already > linked from other pages/queries? > > I think better way is to automaticaly attach some semantic property ("Sort" > for example) > to every subobject on page. This property should contain subobjects number > on page. > > > > -- > View this message in context: http://wikimedia.7.x6.nabble.com/Making-subobjects-correctly-ordered-tp5007553p5007558.html > Sent from the Semantic Mediawiki - Development mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Semediawiki-devel mailing list > Semediawiki-devel@... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > -- > WikiWorks · MediaWiki Consulting · http://wikiworks.com > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev_______________________________________________ > Semediawiki-devel mailing list > Semediawiki-devel@... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel |
From: Alexey Klimovich <god.vedmaka@gm...> - 2013-06-20 16:04:18
|
We are using anonymous (name=hash) subobjects in our system. In semantic queries and from code, we linking them using their hash. Subobjects not changing from every page save or edit. Only one way we discovered they change their hash - when page has renamed/moved. So, subobjects have a good consistency for now. -- View this message in context: http://wikimedia.7.x6.nabble.com/Making-subobjects-correctly-ordered-tp5007553p5007566.html Sent from the Semantic Mediawiki - Development mailing list archive at Nabble.com. |
From: Yaron Koren <yaron@wi...> - 2013-06-20 15:29:49
|
Hi Alexey, Yes, that's a good point - I actually thought about an approach like that, but forgot to include it in the email. A property called "Sort" (a name like "Has index" might be a little clearer) would solve this problem - and it would be a more "semantic" solution. On the other hand, it would add to the proliferation of special properties (for what that's worth), and it would mean a little more work for administrators to get queries of subobjects ordered correctly. I still think my original proposed solution would work fine, though I confess I don't quite understand how the subobject hashing works. Are people supposed to be able to directly link to or reference a subobject, using the hash? I don't see how that could work, given that everything about a subobject could change from one page save to the next - its order, its properties, etc. I don't see how the system could keep consistency of subobject naming. -Yaron On Thu, Jun 20, 2013 at 10:54 AM, Alexey Klimovich <god.vedmaka@...>wrote: > Hi, Yaron! > > I think subobjects sorting is good task, but i suggest not to use > subobjects > name for this because of big problem with that: > > imagine we have 3 subobjects on page: > > Page name#001_4bd1f1b74a76de5322dd74956a71f089 > Page name#002_03163dfd1d2502668b00c1f521688984 > Page name#003_02dwa3j349j8d3jds3843234jd8349490 > > now, we edit page, delete subobject 002. What should happen? > Should other subobjects be renamed to keep sorting? What if they already > linked from other pages/queries? > > I think better way is to automaticaly attach some semantic property ("Sort" > for example) > to every subobject on page. This property should contain subobjects number > on page. > > > > -- > View this message in context: > http://wikimedia.7.x6.nabble.com/Making-subobjects-correctly-ordered-tp5007553p5007558.html > Sent from the Semantic Mediawiki - Development mailing list archive at > Nabble.com. > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Semediawiki-devel mailing list > Semediawiki-devel@... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Alexey Klimovich <god.vedmaka@gm...> - 2013-06-20 14:54:53
|
Hi, Yaron! I think subobjects sorting is good task, but i suggest not to use subobjects name for this because of big problem with that: imagine we have 3 subobjects on page: Page name#001_4bd1f1b74a76de5322dd74956a71f089 Page name#002_03163dfd1d2502668b00c1f521688984 Page name#003_02dwa3j349j8d3jds3843234jd8349490 now, we edit page, delete subobject 002. What should happen? Should other subobjects be renamed to keep sorting? What if they already linked from other pages/queries? I think better way is to automaticaly attach some semantic property ("Sort" for example) to every subobject on page. This property should contain subobjects number on page. -- View this message in context: http://wikimedia.7.x6.nabble.com/Making-subobjects-correctly-ordered-tp5007553p5007558.html Sent from the Semantic Mediawiki - Development mailing list archive at Nabble.com. |
From: Yaron Koren <yaron@wi...> - 2013-06-20 13:30:57
|
Hi, The other thread about #subobject and #set_internal reminded me that I've been meaning to ask about this: Currently #subobject names all the subobjects it creates in the form "Page name#hash" (I referred to the hash previously, incorrectly, as a "random string"). There's a problem with this approach, though, which is that the subobject names don't preserve the order in which they were created. Let's say you have a bunch of #subobject calls in a page (ideally within multiple-instance templates, though it could be done in any way), representing something that has a natural order, like a set of sub-tasks in a project, and you want to display all those sub-tasks in some table on another page. An #ask query on another page won't display them in the same order in which they were entered - by default, it'll go by the subobject name, which will display them in a random (or random-seeming) order. You could of course require users to enter a number for each entry, and then sort on that in the queries; or you could use an extension like NumerAlpha [1] (I haven't used it, so I don't know how well it actually works), but I think it would be nice for this to just work out of the box - that, without any additional work, subobjects get displayed in queries in the same order in which they were entered. If having the unique hash element is important, I can think of a solution that would preserve that, while also making the ordering correct. Right now subobject names look like: Page name#_4bd1f1b74a76de5322dd74956a71f089 Page name#_03163dfd1d2502668b00c1f521688984 You could just prepend an index number at the beginning, so they would instead look like: Page name#001_4bd1f1b74a76de5322dd74956a71f089 Page name#002_03163dfd1d2502668b00c1f521688984 Without getting into the details of technical implementation - does that sound like a reasonable change? [1] https://www.mediawiki.org/wiki/Extension:NumerAlpha -Yaron -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |