On Donnerstag, 4. März 2010, CNIT wrote: > 03.03.2010 20:21, Markus Krötzsch пишет: > > Oh, and I also forgot about this question ... > > > > On Donnerstag, 7. Januar 2010, Solbrig, Harold R. wrote: > >> Markus, > >> > >> I am trying to visualize how this information would be represented in > >> RDF. If we are defining predicate "X", it would seem that the "has type" > >> predicate would translate to "range", and "Value List" would translate > >> to a class named something like "X_Value_List" (since it isn't defined > >> as its own class - it is only defined in the context of "X"). The class > >> "X_value_list", in turn would then be the domain of three predicates - > >> "name" whose range is "String", "count" whose range is "Number" and > >> "source" whose domain is "Page". The response below makes it fairly > >> obvious that we need to be able to make "name", "count" and "source" (or > >> "X_name", "X_count" and "X_source"?) first class properties - otherwise > >> you will find yourself replicating property definitions within this > >> structure. > > > > Since records (I really like having a not-so-ambiguous one-word term > > now!) are just position-encoded value lists of constant length, we can > > encode them in RDF just like containers (using numbered auxiliary > > properties for assigning the individual values of each component to an > > auxiliary element that represents the record). This is in fact what we > > have been doing for the old n-aries in SMW so far. > > > > For internal objects with named fields, one would really use properties > > so as to avoid the replication of their definition. > > > > I plan to develop a "compound types" extension for SMW that will provide > > a number of options for compounds (list, set, record, sub-object), but > > SMW 1.5.0 is first. This will then also address the request of Yaron to > > move records out of SMW core. > > Hi! > I think it will be the best way of announcement is to provide a link to > updated documentation, Because lots of the users are not subscribed to > the list at all. > I hope the site documentation will be in sync with development (funny > thing, I've fogured out that writing documentation even helps to > understand and to code better). > If you are too busy, perhaps someone else can do that. > Such important information shouldn't lost somewhere in the piles of > email messages, it should be "tagged" some way..
Right, I agree. I always try to update the documentation completely with each release. The email discussions are important to discuss things before the release. I provide some documentation-like details in emails so as to make sure that it is clear what we are about to do in SMW. Regarding the naming and use of records, there will be detailed documentation on the release page and in the handbook soon (upgrade notes are already at http://semantic-mediawiki.org/wiki/Semantic_MediaWiki_1.5.0). For the "compound extension" there will be proper documentation when it is in sight (right now, this is just a vague plan of mine). But help with the documentation is always welcome. Currently the datatype Record and the datatype Telephone_number need to be documented. -- Markus -- Markus Krötzsch <mar...@semantic-mediawiki.org> * Personal page: http://korrekt.org * Semantic MediaWiki: http://semantic-mediawiki.org * Semantic Web textbook: http://semantic-web-book.org --
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev
_______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
