I assume by "Fiction" you mean something like "Possible scenario". My response would be that, if the only thing a Semantic Internal Objects extension did was implement an #internal_set parser function, it would be easy to move that code into Semantic MediaWiki if it turned out to be a useful feature. I'd still like to hear what Markus has to say, though.
-Yaron On Mon, Mar 9, 2009 at 6:18 PM, Patrick Nagel <m...@patrick-nagel.net>wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > (re-arranging the cited mail a bit, so that it can be read from top to > bottom...) > > > On Mon, Feb 2, 2009 at 2:02 PM, Markus Krötzsch < > mar...@semantic-mediawiki.org> wrote: > > > >> Some brief comments from my side: > >> > >> * What Yaron proposes is possible and makes sense. > >> > >> * The reason that this was not implemented already was that we initially > >> went for multi-valued properties as one way of allowing "complex > >> subobjects". I acknowledge that the use-cases for both approaches are > >> slightly different. > >> > >> * There is no major technical challenge in implementing the idea Yaron > >> proposes. In particular, multi-valued properties are already implemented > >> in a way that is very similar to what you would do for the proposed > >> "internal objects". > >> > >> * The reason why multi-valued properties are not used a lot is, I think, > >> the restricted way in which they can be used in queries, especially in > >> printouts: you cannot display their components individually. The > internal > >> object proposal addresses this by allowing queries to return internal > >> objects. I note that the same could be done for the values of > >> multi-valued properties. > >> > >> * The previous change has many consequences on the API-level, and might > >> affect a great amount of code in SMW and in extension. Currently, any > >> property has one datatype, where "Relations" point to wiki pages. The > new > >> proposal would allow some properties to point to either a wiki page or > to > >> an internal object. So one would need a unified API and processing for > >> both. This is the main work. > >> > >> * I have another input syntax proposal: one could have a parser function > >> #smwsection (the name is immaterial) that simply encloses normal wiki > >> text, but that associates all annotations that are contained therein > with > >> an internal sub-object instead of with the page. The advantage is: > >> minimal syntax to memorize, usage of displayable or hidden properties > >> just like anywhere else. The disadvantage is: I have no idea how to > >> achieve this behaviour. > >> > >> * Maybe most importantly: the proposal requires changes in the very core > >> of SMW, with good coordination with some extensions. I cannot take up > >> such a large extension project at the moment, since SMW needs to reduce > >> the size and complexity of its code (to support code review by > >> WikiMedia). > >> > >> * Regarding Blank Nodes: No, this has nothing to do with blank nodes > >> (bnodes). A bnode in RDF is syntactic object that is not referred to > with > >> a URI. This is independent of the particular usage of that object in > >> modelling: as long as you have only a single document, you may exchange > >> URI-referenced objects with blank nodes without changing the semantics > of > >> the document a lot (at least as long as the document is used as a > >> knowledge base that is "asserted", as opposed to "queried for"). The > >> advantage of using bnodes to represent "internal objects" is that is > >> saves the cost of coining new URIs. The disadvantage is that internal > >> objects then could not be identified across documents (e.g. when > >> comparing partial ontology exports) and that it reduces compatibility > >> with OWL DL. I think if we manage to come up with a name for displaing > >> the internal objects to the user, it won't be too hard to get them some > >> proper URIs, too. > > On 2009-03-10 01:59, Yaron Koren wrote: > > I've thought more about this implementation. Given that (a) I still think > a > > parser function like "#internal_set" is the best approach to take, (b) > no > > one has brought up any major problems with the scheme, and (c) there's > > still an effort to keep SMW to a minimum size, I'm considering creating a > > separate extension, possibly called "Semantic Internal Objects", that > would > > just handle an "#internal_set" function and, possibly, any special > querying > > (hopefully none) needed to display the data it would store. Are there > any > > objections to that idea? > > Fiction: > Yaron implements this (what I consider core-)funtionality and SMW gets > code-reviewed by WikiMedia, and it gets into Wikipedia (which seems the > reason > for this and other important improvements not being implemented in SMW > itself, > kind of hindering the development): > People would then start to use SMW on a big scale. Thousands of annotations > and queries would be written within weeks. Very quickly the need for > multi-valued properties would arise and people would realise that they > can't > get the data out again in a useful way, which would maybe lead to Yaron's > Semantic Internal Objects extension getting into Wikipedia as well. > How would this functionality ever get into SMW then? > > What I'm trying to say: Once SMW gets widely used, such a change would be > even > harder - and putting every new feature in yet another extension won't make > the > system easier to understand and use, let alone deploy and maintain (on the > administration AND development side). > > Markus, is there a roadmap for SMW? > > Is SMW considered "ready for the masses" which would imply no "API changes" > (as in users would have to change their annotations / queries) are going to > come anymore? > > Patrick. > > - -- > Key ID: 0x86E346D4 http://patrick-nagel.net/key.asc > Fingerprint: 7745 E1BE FA8B FBAD 76AB 2BFC C981 E686 86E3 46D4 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkm1laYACgkQyYHmhobjRtT0mQCggRd9lqIKwt5JojmbJSWE6mEc > wWMAnRb22JAhWLIKKsBEFvMuQm7XvzeC > =kwe3 > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, > CA > -OSBC tackles the biggest issue in open source: Open Sourcing the > Enterprise > -Strategies to boost innovation and cut costs with open source > participation > -Receive a $600 discount off the registration fee with the source code: > SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Semediawiki-devel mailing list > Semediawiki-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >
------------------------------------------------------------------------------
_______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
