From: S P. <ski...@ea...> - 2006-03-17 05:49:29
|
http://wiki.ontoworld.org/index.php/Relation:Is_a says "Note that instead of using this relation, the final version will probably just incorporate the Category links MediaWiki already supports." For what it's worth, I prefer reusing Category over Is_a. Currently all the Is_a relations link one encyclopedia page to another. If you're going to replace them with categories, I think Is_a should only link to pages in the Category: namespace like "Category:City". But if you look at the way people are using Is_a relations in the ontoworlk wiki, it's far broader than the way the English Wikipedia currently uses categories. Also, it's interesting that English Wikipedia categories are usually plural, e.g. http://en.wikipedia.org/wiki/Category:Cities , where all the Is_a "class" pages are singular, like "City". Categorically yours, -- =S |
From: Markus <ma...@ai...> - 2006-03-17 11:06:12
|
On Friday 17 March 2006 06:45, S Page wrote: > http://wiki.ontoworld.org/index.php/Relation:Is_a says > "Note that instead of using this relation, the final version will > probably just incorporate the Category links MediaWiki already supports." > > For what it's worth, I prefer reusing Category over Is_a. Me too. > > Currently all the Is_a relations link one encyclopedia page to another. > If you're going to replace them with categories, I think Is_a should > only link to pages in the Category: namespace like "Category:City". =20 Exactly. > But=20 > if you look at the way people are using Is_a relations in the ontoworlk > wiki, it's far broader than the way the English Wikipedia currently uses > categories. Yes, and that is a core problem. Because today's RDF/RDFS/OWL-software coul= d=20 nicely deal will WP-categories, but hardly with this whole "is_a" business.= =20 It is also not suitable for integration with external ontologies, since a=20 good deal of them use OWL-classes, and you probably don't want these to be= =20 interpreted in OWL Full. > > Also, it's interesting that English Wikipedia categories are usually > plural, e.g. http://en.wikipedia.org/wiki/Category:Cities , > where all the Is_a "class" pages are singular, like "City". Mmh. We should stay with the WP convention. I recently created a category c= ity=20 and should now probably change it to plural. > > Categorically yours, :-) Regards, Markus > -- > =3DS > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting langua= ge > that extends applications into web and mobile media. Attend the live > webcast and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat= =3D121642 > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user =2D-=20 Markus Kr=F6tzsch Institute AIFB, University of Karlsruhe, D-76128 Karlsruhe ma...@ai... phone +49 (0)721 608 7362 www.aifb.uni-karlsruhe.de/WBS/ fax +49 (0)721 693 717 |
From: Jakob V. <jak...@ni...> - 2006-03-17 12:55:49
|
Markus Krötzsch wrote: >> But if you look at the way people are using Is_a relations in the ontoworlk >> wiki, it's far broader than the way the English Wikipedia currently uses >> categories. > > Yes, and that is a core problem. Because today's RDF/RDFS/OWL-software could > nicely deal will WP-categories, but hardly with this whole "is_a" business. > It is also not suitable for integration with external ontologies, since a > good deal of them use OWL-classes, and you probably don't want these to be > interpreted in OWL Full. Wikipedia categories don't imply is-a-relationships. They don't have any strict semantic but "is sorted under". It's a common misunderstanding to imply semantics beyond this. But you can describe Wikipedia categories with the SKOS Core Vocabulary: http://www.w3.org/2004/02/skos/ http://www.w3.org/TR/swbp-thesaurus-pubguide/ Greetings, Jakob |
From: Jama P. <ja...@de...> - 2006-03-17 14:38:12
|
On Fri, Mar 17, 2006 at 01:54:24PM +0100, Jakob Voss wrote: > Wikipedia categories don't imply is-a-relationships. They don't have any > strict semantic but "is sorted under". It's a common misunderstanding to > imply semantics beyond this. But you can describe Wikipedia categories > with the SKOS Core Vocabulary: On a related note, Wikicompany is moving to a semantic (one-word) tag based system, using the SMW system and some tag-based workflow. The current MW category has several constraints for the project I've been trying to overcome for some time. More background notes here: http://wikicompany.org/wiki/Wikicompany:Semantic_tags (feel free to edit this) http://wikicompany.wordpress.com I can recommend the presentation by Clay Shirky for the Long Now project: http://seminars.moose.cc/salt-0200511-shirky/salt-0200511-shirky-24kbps.mp3 (somewhere at 0:37:00 he starts talking about the issues with the Wikipedia category system). For Wikipedia there are more complex considerations, but I still feel the current category system combined with semantic tags isn't ideal. It feels too maintenance heavy and too structured. This all comes at the cost of more complexity and overhead. Wikipedia may also be the only Wiki that really wants to explicitly describe all relations and attributes. Many Wiki's do not need/want this overhead. If there is interest, I'd like to cooperate with the SWM and Wikipedia project on this, but I'll first create something usable. regards, Jama Poulsen |
From: S P. <ski...@ea...> - 2006-03-18 01:33:45
|
Jama Poulsen wrote: > On a related note, Wikicompany is moving to a semantic (one-word) > tag based system, using the SMW system and some tag-based workflow. > > The current MW category has several constraints for the project I've been > trying to overcome for some time. > > More background notes here: > http://wikicompany.org/wiki/Wikicompany:Semantic_tags (feel free to edit this) > http://wikicompany.wordpress.com > > I can recommend the presentation by Clay Shirky for the Long Now project: > http://seminars.moose.cc/salt-0200511-shirky/salt-0200511-shirky-24kbps.mp3 > (somewhere at 0:37:00 he starts talking about the issues with the Wikipedia > category system). I haven't listened yet, but I already read http://www.shirky.com/writings/ontology_overrated.html Clay and others are down on categories, yet people find them useful. I find tags so free-form as to quickly become useless, and there's no way to manage them because they attempt so little. I suspect the people who are down on categories match the set of people who don't believe Wikipedia could ever work :-). His against bullet points ("Uncoordinated, amateur, naive users with no authority") sounds like Wikipedia users! The selfless Wikipedians who tirelessly standardize pages to use infoboxes and templates will work on categories. > For Wikipedia there are more complex considerations, but I still feel > the current category system combined with semantic tags isn't ideal. > It feels too maintenance heavy and too structured. This all comes at the > cost of more complexity and overhead. For sure, for you. But I assume Wikipedia categories aren't going away and are in existing pages, so if there's a way to capture their (weak) semantics at RDF export time, that's an improvement over relations and attributes alone. > Wikipedia may also be the only Wiki that really wants to explicitly describe > all relations and attributes. Many Wiki's do not need/want this overhead. > > If there is interest, I'd like to cooperate with the SWM and Wikipedia > project on this, but I'll first create something usable. Looks like you did! I tried your system, e.g. http://wikicompany.org/wiki/Apax_Partners tagged "international". It's neat that Semantic MediaWiki's attribute values give us [[tag:=AnyTagName]] "for free"; it makes me wish del.icio.us implemented full attribute values ("rating:=4 stars")! But I think users would expect the tag to be some sort of live thing, and it isn't. You could make tag a relation to a page that describes the tag, [[tag::international]] , but then why not make that page really powerful, like [[tag::Category:international]] at which point you're back to categories :-) What is your "tag-based workflow" beyond searching for the attribute name "tag"? Respectfully yours, -- =S |
From: Jama P. <ja...@de...> - 2006-03-18 13:39:30
|
On Fri, Mar 17, 2006 at 05:29:19PM -0800, S Page wrote: > I haven't listened yet, but I already read > http://www.shirky.com/writings/ontology_overrated.html > > Clay and others are down on categories, yet people find them useful. Not true, it all depends on the information domain (and its scope) and the participants, as he states: "This is all the domain-specific stuff that you would like to be true if you're trying to classify cleanly. The periodic table of the elements has all of these things -- there are only a hundred or so elements; the categories are simple and derivable; protons don't change because of political circumstances; only elements can be classified, not molecules; there are no blended elements; and so on. The more of those characteristics that are true, the better a fit ontology is likely to be." "The amount of 'people infrastructure' that's hidden in a working system like DSM IV is a big part of what makes this sort of categorization work." "This 'people infrastructure' is very expensive, though." And in many cases these 'expensive ontologies' are not even that good for searching and browsing. See eg. the blogosphere discussions about tagging and public libraries. In addition, much of the ontology _software_ isn't that usable and usefull in the context of its users. Its often overengineered wrt the target audience. Amazon beat the libraries mainly because of this (besides the fragmentation of information by public libraries). > I find tags so free-form as to quickly become useless, and there's no > way to manage them because they attempt so little. Semantic tags are something different. And again, don't just focus on the output side, also look at the input side, else you might get an overengineered system. > >For Wikipedia there are more complex considerations, but I still feel > >the current category system combined with semantic tags isn't ideal. > >It feels too maintenance heavy and too structured. This all comes at the > >cost of more complexity and overhead. > > For sure, for you. > But I assume Wikipedia categories aren't going away and are in existing > pages, so if there's a way to capture their (weak) semantics at RDF > export time, that's an improvement over relations and attributes alone. I'm only raising important issues from the field, not trying to reform Wikipedia. Time will tell what will be a good stategy for large-scale public Wiki's. > >If there is interest, I'd like to cooperate with the SWM and Wikipedia > >project on this, but I'll first create something usable. > > Looks like you did! I tried your system, e.g. > http://wikicompany.org/wiki/Apax_Partners tagged "international". Thats only a 'free tag' ('no semantics'). See: http://wikicompany.org/wiki/Wikicompany:Semantic_tags for other tag examples. The real work is the removal of the Category labels, inclusion of tags (on the left-side), and tag-workflows (in web forms, searching, browsing, REST API, etc.). > It's neat that Semantic MediaWiki's attribute values give us > [[tag:=AnyTagName]] "for free"; it makes me wish del.icio.us implemented > full attribute values ("rating:=4 stars")! But I think users would > expect the tag to be some sort of live thing, and it isn't. You could > make tag a relation to a page that describes the tag, > [[tag::international]] , but then why not make that page really > powerful, like [[tag::Category:international]] at which point you're > back to categories :-) I've got that last system right now, and I don't find it good enough. > What is your "tag-based workflow" beyond searching for the attribute > name "tag"? Easier input, dynamic filtering, better webservice integration, and probably more in the future. Anyway, I'm excited by the blossoming of all these web2.0 information concepts. The experimental learning part is half the fun actually. Jama Poulsen |
From: Markus <ma...@ai...> - 2006-03-20 09:38:47
|
On Friday 17 March 2006 13:54, Jakob Voss wrote: > Markus Kr=F6tzsch wrote: > >> But if you look at the way people are using Is_a relations in the > >> ontoworlk wiki, it's far broader than the way the English Wikipedia > >> currently uses categories. > > > > Yes, and that is a core problem. Because today's RDF/RDFS/OWL-software > > could nicely deal will WP-categories, but hardly with this whole "is_a" > > business. It is also not suitable for integration with external > > ontologies, since a good deal of them use OWL-classes, and you probably > > don't want these to be interpreted in OWL Full. > > Wikipedia categories don't imply is-a-relationships. They don't have any > strict semantic but "is sorted under". It's a common misunderstanding to > imply semantics beyond this. But you can describe Wikipedia categories > with the SKOS Core Vocabulary: > > http://www.w3.org/2004/02/skos/ > http://www.w3.org/TR/swbp-thesaurus-pubguide/ Yes, I absolutely agree. My point was not that Categories can be replaced b= y=20 "is a", but that "is a" can be replaced by categories. The advantages are: * people already use categories, so there is data available even in existin= g=20 wikis, * categories can be interpreted by default as RDFS or OWL classes and we ha= ve=20 software support for these. Other than this I don't really care about whether one uses categories or=20 relations. One should, however, have clear guidelines to prevent users from= =20 mixing the two, i.e. from sometimes using [[Category:Cities]] and sometimes= =20 using [[is a::City]]. Alas, "is a" is so unconstrained that it allows you t= o=20 state things like "B is a C" and "C is a B". Note that RDFS supports this,= =20 and that this does not mean that C and B are equal -- try to explain this=20 interpretation to your users ;-) The considerations of what a category actually means in the wiki are very=20 important, but the different interpretations do not strongly impair the=20 RDF-reading. One just changes the informal interpretation of the categories= =20 (Europe is not the class of all europes, but the class of all things that a= re=20 related to Europe etc. -- they are still classes). The subclass-relationshi= p=20 is slightly more tricky. Anyway, I expect that practical features are usabl= e=20 without requiring too much philosophical considerations of the users. =2D- Markus > > Greetings, > Jakob > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting langua= ge > that extends applications into web and mobile media. Attend the live > webcast and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat= =3D121642 > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user =2D-=20 Markus Kr=F6tzsch Institute AIFB, University of Karlsruhe, D-76128 Karlsruhe ma...@ai... phone +49 (0)721 608 7362 www.aifb.uni-karlsruhe.de/WBS/ fax +49 (0)721 693 717 |
From: Markus <ma...@ai...> - 2006-03-20 10:08:02
|
On Friday 17 March 2006 15:37, Jama Poulsen wrote: > On Fri, Mar 17, 2006 at 01:54:24PM +0100, Jakob Voss wrote: > > Wikipedia categories don't imply is-a-relationships. They don't have any > > strict semantic but "is sorted under". It's a common misunderstanding to > > imply semantics beyond this. But you can describe Wikipedia categories > > with the SKOS Core Vocabulary: > > On a related note, Wikicompany is moving to a semantic (one-word) > tag based system, using the SMW system and some tag-based workflow. Glad to see that you are using the system. Be sure to update the system at = the=20 upcoming 0.3 release, since quite some things have been improved recently. Technically, you can of course use attributes to create tags (this correspo= nds=20 to the unstructured flickr-style freeform tags), but you could as well use= =20 dedicated categories if you like. I think this all depends on how tags are= =20 employed. If one has only a few tags with many entries, then categories mig= ht=20 be better since one could also write descriptions on the category pages. If= =20 tags are used very liberal as unstructured keywords that could guide a text= =20 search, then one would not take the effort to create thousands of categorie= s=20 for every tag-phrase that occurs. Attributes certainly are preferable for most data, such as the number of=20 employees or the geo-location of headquarters. String-type attributes are a= =20 special case where you can decide what to use. I would not see the=20 category-vs.-attribute-discussion as a fundamental debate. It really depend= s=20 on your application area. > > The current MW category has several constraints for the project I've been > trying to overcome for some time. > > More background notes here: > http://wikicompany.org/wiki/Wikicompany:Semantic_tags (feel free to edit > this) http://wikicompany.wordpress.com > > I can recommend the presentation by Clay Shirky for the Long Now project: > http://seminars.moose.cc/salt-0200511-shirky/salt-0200511-shirky-24kbps.m= p3 > (somewhere at 0:37:00 he starts talking about the issues with the Wikiped= ia > category system). > > For Wikipedia there are more complex considerations, but I still feel > the current category system combined with semantic tags isn't ideal. > It feels too maintenance heavy and too structured. This all comes at the > cost of more complexity and overhead. > > Wikipedia may also be the only Wiki that really wants to explicitly > describe all relations and attributes. Many Wiki's do not need/want this > overhead. Even in Wikipedia, you can see that some categories have hardly any=20 description. The Category: namespace (and our namespaces Relation: and Type= :)=20 just give you the option to provide such descriptions whenever you feel lik= e=20 it. So the overhead can be controlled in any case. > > If there is interest, I'd like to cooperate with the SWM and Wikipedia > project on this, but I'll first create something usable. Great. I see that your project also creates some specific practical=20 requirements, e.g. to provide a datatype for calendar dates. Or a search=20 function that acts more like a full-text search on tags. We are aware of so= me=20 such requirements, but please let us know when you see concrete issues that= =20 we should address to "create something usable". ;-) Regards, Markus > > regards, > > Jama Poulsen > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting langua= ge > that extends applications into web and mobile media. Attend the live > webcast and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat= =3D121642 > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user =2D-=20 Markus Kr=F6tzsch Institute AIFB, University of Karlsruhe, D-76128 Karlsruhe ma...@ai... phone +49 (0)721 608 7362 www.aifb.uni-karlsruhe.de/WBS/ fax +49 (0)721 693 717 |
From: Jama P. <ja...@de...> - 2006-03-20 21:00:14
|
On Mon, Mar 20, 2006 at 11:05:39AM +0100, Markus Kr?tzsch wrote: > Great. I see that your project also creates some specific practical > requirements, e.g. to provide a datatype for calendar dates. Or a search > function that acts more like a full-text search on tags. We are aware of some > such requirements, but please let us know when you see concrete issues that > we should address to "create something usable". ;-) Let me describe something related to the "semantic datatype" topic. What I've been thinking about, is a concept which I'll call "Triple+". The idea is to simply use a triple [object, link, object] (I don't like those formal terms :-), and optionally add a list of key-value pair to this triple data-structure. So you would get: [object, link, object, ["key1:val1, ... "]] The appended key-value list contains semi-structured data relating to the _whole triple_. The idea here is that, as we get objects from a graph query, we can inspect and extract more information about these objects. The extra object data could be used in various ways. - Describe that companyX is 80% owned by companyY: companyX has-parent companyY [part:80%] - Describe the number of employees of companyX: companyX employees 23 [1988:2,1999:3:2000:9,...] - Describe presentation by companyX at confY: companyX presentation confY [time:'some timestamp format', url:http://foo.bar/confY] I think the layering of the formal semantics in the first search phase combined with the less formal data made available at the second search stage can be very helpful, and reduces the amount of descriptive complexity needed in the first stage. I even think you could take the concept further, and include function semantics for web services in the Triple+ data structure. The could be pointers to SPARQL queries, RESTful actions, or JS functions. I don't claim to have any exceptional insight into the semweb, but I do see the power of simplicity/flexibility over accuracy/control [1], and think thats whats keeping graph-based semantics out of many applications. Or perhaps I'm just too ignorant too see the semweb heaven coming :) I'll put up a page on Wikicompany about Triple+ at some point, and maybe even start experimenting. Comments? Jama Poulsen [1] There is a presentation by Peter F. Patel-Schneider, which also touches on some of the problems of RDF/OWL (in its current form) and heavy editorial requirements to use the various semantic languages: http://video.google.com/videoplay?docid=-661464686397234947 |
From: Markus <ma...@ai...> - 2006-03-22 18:29:25
|
On Monday 20 March 2006 22:00, Jama Poulsen wrote: > On Mon, Mar 20, 2006 at 11:05:39AM +0100, Markus Kr?tzsch wrote: > > Great. I see that your project also creates some specific practical > > requirements, e.g. to provide a datatype for calendar dates. Or a search > > function that acts more like a full-text search on tags. We are aware of > > some such requirements, but please let us know when you see concrete > > issues that we should address to "create something usable". ;-) > > Let me describe something related to the "semantic datatype" topic. > What I've been thinking about, is a concept which I'll call "Triple+". > > The idea is to simply use a triple [object, link, object] (I don't > like those formal terms :-), and optionally add a list of key-value > pair to this triple data-structure. > > So you would get: [object, link, object, ["key1:val1, ... "]] > > The appended key-value list contains semi-structured data relating to > the _whole triple_. > > The idea here is that, as we get objects from a graph query, we can > inspect and extract more information about these objects. > > The extra object data could be used in various ways. > > - Describe that companyX is 80% owned by companyY: > companyX has-parent companyY [part:80%] > > - Describe the number of employees of companyX: > companyX employees 23 [1988:2,1999:3:2000:9,...] > > - Describe presentation by companyX at confY: > companyX presentation confY [time:'some timestamp format', > url:http://foo.bar/confY] > > I think the layering of the formal semantics in the first search > phase combined with the less formal data made available at the second > search stage can be very helpful, and reduces the amount of descriptive > complexity needed in the first stage. > > I even think you could take the concept further, and include function > semantics for web services in the Triple+ data structure. The could be > pointers to SPARQL queries, RESTful actions, or JS functions. > > I don't claim to have any exceptional insight into the semweb, but I do > see the power of simplicity/flexibility over accuracy/control [1], and > think thats whats keeping graph-based semantics out of many applications. > Or perhaps I'm just too ignorant too see the semweb heaven coming :) > > I'll put up a page on Wikicompany about Triple+ at some point, and maybe > even start experimenting. > > Comments? I see the utility of the above statements and it is indeed a limitation of = the=20 current system that it cannot deal with statements that involve more than=20 three components (such as your examples). However, we do not want to make t= he=20 datamodel and syntax more complicated until we have full support (including= =20 search) for our current simple data. The current internal architecture could encompass more complicated statemen= ts,=20 though the export is not yet able to make more complex RDF structures.=20 Basically one could have new datatypes that allow you to make a mini-tree=20 structure instead of a single triple. E.g. one could write [[has parent:=3DCompany2; 80%]] in the article of Company1 to get a datamodel like Company1 has_parent Company2_80% Company2_80% has_company Company2 Company2_80% has_fraction 0.8 where Company_80% is just an auxiliary node needed in the RDF export. One=20 could also represent the data in another way, but RDF can be queried nicely= =20 with SPARQL. Maybe I will at some time write a datatype that does this for= =20 arbitrary n-tuples. In fact, our current Geo-Coordinates will soon be a=20 special example of this, since we will export them as three values instead = of=20 one (1 complete string, 1 latitude float, 1 longitude float). No big proble= m=20 really, but we first want to complete the edit and re-use features for=20 standard triples. =2D- Markus > > Jama Poulsen > > [1] There is a presentation by Peter F. Patel-Schneider, which also > touches on some of the problems of RDF/OWL (in its current form) and > heavy editorial requirements to use the various semantic languages: > http://video.google.com/videoplay?docid=3D-661464686397234947 > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting langua= ge > that extends applications into web and mobile media. Attend the live > webcast and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat= =3D121642 > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user =2D-=20 Markus Kr=F6tzsch Institute AIFB, University of Karlsruhe, D-76128 Karlsruhe ma...@ai... phone +49 (0)721 608 7362 www.aifb.uni-karlsruhe.de/WBS/ fax +49 (0)721 693 717 |