On 23/10/11 10:36, Yury Katkov wrote: > Was I talkling gibberish or was the RDF export question too hard? :)
The latter ;-) I have not had the time yet to answer this yet. Below is my reply. > > On Thu, Oct 13, 2011 at 2:47 AM, Yury Katkov <katkov.ju...@gmail.com > <mailto:katkov.ju...@gmail.com>> wrote: > > Hello Markus, > First of all, your alternative proposal looks much better than the > original one because of more flexibility. And praise you for the great > solution of optional naming - I hope it will be possible to implement > it! Thanks. What I now implemented requires naming for all subobjects, so it is not optional. One could have another parser function that does not require a name; overloading #subobject to do both (named subobjects without any return value and anonymous subobjects returning their generated name) seems to have a great potential for confusion. Maybe we don't need unnamed subobjects after all. > > What about RDF export and Import vocabulary features? I have really > two questions concerning both those features: > > == RDFExport+RDF store question== > > As far I as I can see subobjects should be turned to the blank nodes, > shouldn't they? Not really. They are named and they can be addressed by that name from all over the wiki. This includes RDF export functions: you can export the data for one subobject using its name. With blank nodes, this would not work. Even the anonymous subobjects (currently used for Type:Record) are simply subobjects with auto-generated names, not really unnamed ones. > > == Import vocabulary question == > > Is it possible to map the subobject to RDF class? That can be > extremely useful even in simple vocabularies like FOAF. > Here is an example: we have the wiki-page of Yury who has an online > account in two social networks: Facebook and Vkontakte. > > ===Example=== > It's pretty easy to describe this fact with subobjects: > ##### PAGE STARTS######### > Yury has [[has account::{{#subobject: > service=http://facebook.com > accountname=ganqqwerty}} > |facebook account]], > [[has account:: {{#subobject: > service=vkontakte.ru > <http://vkontakte.ru> > accountname=katkov}} > |Vkontakte.ru account]] > #####PAGE ENDS######### > ===RDF Export=== > If I map has account to foaf:account, map service to uring rdf export > we will get the following (simplified) > :Yury_id_in_wiki foaf:account > :Yury_id_in_wiki#tmpnum1 . > :Yury_id_in_wiki#tmpnum1 foaf:accountServiceHomepage > <http://facebook.com> > :Yury_id_in_wiki#tmpnum1 foaf:accountName "ganqqwerty" > === Problem === > The problem is that the property foaf:account has range > foaf:OnlineAccount. Our RDF export now is a little bit incomplete. > > ===Proposal=== > > Make it possible to assign some kind of type to the subobject and map > those types to RDFS or OWL classes. I honestly don't know how this can > be done - probably with the special attribute "type" or "category". > > The typing can be needed now only in case of RDF export. If I have a > wiki with thousands of subobjects it would always be nice to see what > kind of subobjects are there. If I understand correctly, you suggest to have a mechanism to associate a class (category) with subobjects. This is indeed not possible now since Categories are a MediaWiki feature that cannot be used with subobjects. The issue here is not even in doing this automatically for certain cases, but in doing it at all. In your example, this is not really necessary. As you rightly say, there already is a range declaration on foaf:account. The meaning of range in RDFS is: even if you do not specify a class, it will be inferred that the object is in the range class if it is used as a value to the property. So your example actually illustrates a case where an additional class assignment would not add any information to the data (in the view of an RDFS processor that is aware of the FOAF ontology; of course an RDF processor that does not know what rdfs:range means would not be able to use this information). It would still be nice to allow categorization of subobjects, but I don't see now how to make this work properly with the current category=class approach in SMW without introducing discrepancies between SMW category/class information and MediaWiki category information. Markus ------------------------------------------------------------------------------ Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev _______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
