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 <mail@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 <markus@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