From: Markus K. <ma...@se...> - 2009-08-26 18:47:35
|
Using the Codeathon at Wikimania 2009, we have now implemented support for "inverse properties". This email gives an overview of the features (usr perspective) and internals (developer perspectives). Some SMW extensions will need to be adjusted to work with the new feature. == Introduction == The inverse of a property simply is the property that points into the other direction. For example, if "developer of" connects a person to a software tool, then the inverse of "developer of" connects software tools to persons. So far, it was very hard to use properties in other directions. In our example, you could, e.g., have an ask query showing the all persons who develop some open source tool, but you could not have a query that shows all software tools that are developed by people living in Argentina. To do the latter, you would have had to use a property "is developed by" that explicitly connects software tools to their developers, and you would have had to add data for that again. If you need both directions, you would have to maintain both properties individually, which is not very convenient. == Feature Details == SMW (SVN) now allows you to directly refer to the inverse of any property by simply putting a "-" in front of its name. For example, "-developer of" gives you access to what I called "is developed by" above. This can be used in any place where property names occur, including browsing special pages, ask queries, and output directives of queries. So the projects developed by people from Argentina can be obtained with a query {{#ask: [[-developer of:: <q>[[lives in::Argentina]]</q> ]] }} or simply {{#ask: [[-developer of.lives in::Argentina]] }} We are aware that the "-" prefix is not the most readable way of solving the problem. However, the solution we have now avoids a number of complications that other solution would introduce (for example, you cannot have chains of inverses, like Property:A inverse_of Property:B inverse_of Property:C inverse_of ...; also, there is no relevant interplay of "subproperty of" and inverses). If applicable, inverse properties generally are linked to the page of the corresponding property (so "-developer of" links to "Property:developer of"). It is strongly suggested not to create property pages that are called like inverse properties (it won't destroy anything, but it might create unnecessary confusion). Also, you cannot use inverse properties to enter semantic data into the wiki: all annotations must be on the page that is the subject of the non-inverted property. Inverses in queries are currently only supported if they are of Type:Page. == Development Information == If your code uses SMW properties that are generated from user inputs, then you need to be aware of inverse properties to make sure everything works correctly. Internally, an inverse property, like any property, is represented by an SMWPropertyValue object. It will look like the property value object for the non-inverse version of the property. To check if it actually is the inverse, you can use the new method isInverse(). You can pass inverse properties to the SMW store, and it will take care of everything. The main changes that I expect to be required in SMW extensions is in places where you deal with property subjects and silently expect them to be of Type:Page. If users can enter inverse properties, then a query for a subject can also return datavalues of other datatypes, so you need to use the generic datavalue API, or check the type of the datavalue first. Another place where changes might be needed is when passing on parameters as strings. If you use getWikiValue() on an inverse property, then you will obtain the property name with "-" in front, as expected. But if you use "getShortWiikiText()" and other functions, you will get the name of the property without any "-". I hope that SMW already works properly in all cases where inverses can occur. Feedback is welcome. Cheers, Markus -- Markus Krötzsch <ma...@se...> * Personal page: http://korrekt.org * Semantic MediaWiki: http://semantic-mediawiki.org * Semantic Web textbook: http://semantic-web-book.org -- |
From: Jon L. <dat...@gm...> - 2009-08-26 20:34:49
|
Markus Krötzsch wrote: > If applicable, inverse properties generally are linked to the page of the > corresponding property (so "-developer of" links to "Property:developer of"). > It is strongly suggested not to create property pages that are called like > inverse properties (it won't destroy anything, but it might create unnecessary > confusion). Could you give an example of this, please? In particular, what are you meaning by "are linked to"? > Also, you cannot use inverse properties to enter semantic data > into the wiki: all annotations must be on the page that is the subject of the > non-inverted property. So inverse properties are like the "what pages link here?" Wiki feature? > Inverses in queries are currently only supported if they are of Type:Page. That makes sense. > == Development Information == > > The main changes that I expect to be required in SMW extensions is in places > where you deal with property subjects and silently expect them to be of > Type:Page. If users can enter inverse properties, then a query for a subject > can also return datavalues of other datatypes, so you need to use the generic > datavalue API, or check the type of the datavalue first. Could you give an example of such a query, for illustrative purposes? > I hope that SMW already works properly in all cases where inverses can occur. > Feedback is welcome. This is a welcome step forward. The other feature that I'm hoping to see relatively soon are transitory properties. -- Jonathan "Dataweaver" Lang |
From: Markus K. <ma...@se...> - 2009-08-26 21:37:01
|
On Mittwoch, 26. August 2009, Jon Lang wrote: > Markus Krötzsch wrote: > > If applicable, inverse properties generally are linked to the page of the > > corresponding property (so "-developer of" links to "Property:developer > > of"). It is strongly suggested not to create property pages that are > > called like inverse properties (it won't destroy anything, but it might > > create unnecessary confusion). > > Could you give an example of this, please? In particular, what are > you meaning by "are linked to"? Sorry, I was not very clear here: Sometimes property names are displayed somewhere, for example in the header of tables created by #ask. Such texts are often linked to the property's page. In case of inverses, links will go to non-inverse property pages. > > > Also, you cannot use inverse properties to enter semantic data > > into the wiki: all annotations must be on the page that is the subject of > > the non-inverted property. > > So inverse properties are like the "what pages link here?" Wiki feature? Very roughly, yes. > > > Inverses in queries are currently only supported if they are of > > Type:Page. > > That makes sense. > > > == Development Information == > > > > The main changes that I expect to be required in SMW extensions is in > > places where you deal with property subjects and silently expect them to > > be of Type:Page. If users can enter inverse properties, then a query for > > a subject can also return datavalues of other datatypes, so you need to > > use the generic datavalue API, or check the type of the datavalue first. > > Could you give an example of such a query, for illustrative purposes? What query do you mean? You mean the actual source code that uses inverse properties? It is not different from code using non-inverse properties, really. > > > I hope that SMW already works properly in all cases where inverses can > > occur. Feedback is welcome. > > This is a welcome step forward. The other feature that I'm hoping to > see relatively soon are transitory properties. This is much harder (I think you mean "transitive" here). Maybe not so soon ... -- Markus -- Markus Krötzsch <ma...@se...> * Personal page: http://korrekt.org * Semantic MediaWiki: http://semantic-mediawiki.org * Semantic Web textbook: http://semantic-web-book.org -- |
From: Laurent A. <la...@al...> - 2009-08-26 22:04:06
|
Very intriguing. Are you planning to have support for some kind of display name, through a property defined on the Property page maybe ? It would be nice to have a way to hide the reverse notation with a meaningful string sometimes. - Laurent Alquier Http://www.Alquier.org On Aug 26, 2009, at 5:36 PM, Markus Krötzsch <markus@semantic-mediawiki.or g> wrote: > On Mittwoch, 26. August 2009, Jon Lang wrote: >> Markus Krötzsch wrote: >>> If applicable, inverse properties generally are linked to the page >>> of the >>> corresponding property (so "-developer of" links to >>> "Property:developer >>> of"). It is strongly suggested not to create property pages that are >>> called like inverse properties (it won't destroy anything, but it >>> might >>> create unnecessary confusion). >> >> Could you give an example of this, please? In particular, what are >> you meaning by "are linked to"? > > Sorry, I was not very clear here: Sometimes property names are > displayed > somewhere, for example in the header of tables created by #ask. Such > texts are > often linked to the property's page. In case of inverses, links will > go to > non-inverse property pages. > >> >>> Also, you cannot use inverse properties to enter semantic data >>> into the wiki: all annotations must be on the page that is the >>> subject of >>> the non-inverted property. >> >> So inverse properties are like the "what pages link here?" Wiki >> feature? > > Very roughly, yes. > >> >>> Inverses in queries are currently only supported if they are of >>> Type:Page. >> >> That makes sense. >> >>> == Development Information == >>> >>> The main changes that I expect to be required in SMW extensions is >>> in >>> places where you deal with property subjects and silently expect >>> them to >>> be of Type:Page. If users can enter inverse properties, then a >>> query for >>> a subject can also return datavalues of other datatypes, so you >>> need to >>> use the generic datavalue API, or check the type of the datavalue >>> first. >> >> Could you give an example of such a query, for illustrative purposes? > > What query do you mean? You mean the actual source code that uses > inverse > properties? It is not different from code using non-inverse > properties, > really. > >> >>> I hope that SMW already works properly in all cases where inverses >>> can >>> occur. Feedback is welcome. >> >> This is a welcome step forward. The other feature that I'm hoping to >> see relatively soon are transitory properties. > > This is much harder (I think you mean "transitive" here). > Maybe not so soon ... > > -- Markus > > > > -- > Markus Krötzsch <ma...@se...> > * Personal page: http://korrekt.org > * Semantic MediaWiki: http://semantic-mediawiki.org > * Semantic Web textbook: http://semantic-web-book.org > -- > > --- > --- > --- > --------------------------------------------------------------------- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel |
From: Markus K. <ma...@se...> - 2009-08-27 20:38:44
|
On Donnerstag, 27. August 2009, Laurent Alquier wrote: > Very intriguing. > > Are you planning to have support for some kind of display name, > through a property defined on the Property page maybe ? > > It would be nice to have a way to hide the reverse notation with a > meaningful string sometimes. Yes, we have considered this, and it might be something that we can still add at some point. This could certainly be built on top of the current extension (in essence, it is just another way of addressing the inverses). However, there are a number of open design issues that we have not solved yet: (1) What happens if the inverse label is also the name of a (non-inverse) property? (2) What happens if two properties have the same inverse label? (3) What happens if one property has multiple inverse labels? I think (3) is easy enough: there is no reason not to have multiple labels there. But the other two are tricky. Regards, Markus > > - Laurent Alquier > Http://www.Alquier.org > > > On Aug 26, 2009, at 5:36 PM, Markus Krötzsch <markus@semantic-mediawiki.or > > g> wrote: > > On Mittwoch, 26. August 2009, Jon Lang wrote: > >> Markus Krötzsch wrote: > >>> If applicable, inverse properties generally are linked to the page > >>> of the > >>> corresponding property (so "-developer of" links to > >>> "Property:developer > >>> of"). It is strongly suggested not to create property pages that are > >>> called like inverse properties (it won't destroy anything, but it > >>> might > >>> create unnecessary confusion). > >> > >> Could you give an example of this, please? In particular, what are > >> you meaning by "are linked to"? > > > > Sorry, I was not very clear here: Sometimes property names are > > displayed > > somewhere, for example in the header of tables created by #ask. Such > > texts are > > often linked to the property's page. In case of inverses, links will > > go to > > non-inverse property pages. > > > >>> Also, you cannot use inverse properties to enter semantic data > >>> into the wiki: all annotations must be on the page that is the > >>> subject of > >>> the non-inverted property. > >> > >> So inverse properties are like the "what pages link here?" Wiki > >> feature? > > > > Very roughly, yes. > > > >>> Inverses in queries are currently only supported if they are of > >>> Type:Page. > >> > >> That makes sense. > >> > >>> == Development Information == > >>> > >>> The main changes that I expect to be required in SMW extensions is > >>> in > >>> places where you deal with property subjects and silently expect > >>> them to > >>> be of Type:Page. If users can enter inverse properties, then a > >>> query for > >>> a subject can also return datavalues of other datatypes, so you > >>> need to > >>> use the generic datavalue API, or check the type of the datavalue > >>> first. > >> > >> Could you give an example of such a query, for illustrative purposes? > > > > What query do you mean? You mean the actual source code that uses > > inverse > > properties? It is not different from code using non-inverse > > properties, > > really. > > > >>> I hope that SMW already works properly in all cases where inverses > >>> can > >>> occur. Feedback is welcome. > >> > >> This is a welcome step forward. The other feature that I'm hoping to > >> see relatively soon are transitory properties. > > > > This is much harder (I think you mean "transitive" here). > > Maybe not so soon ... > > > > -- Markus > > > > > > > > -- > > Markus Krötzsch <ma...@se...> > > * Personal page: http://korrekt.org > > * Semantic MediaWiki: http://semantic-mediawiki.org > > * Semantic Web textbook: http://semantic-web-book.org > > -- > > > > --- > > --- > > --- > > --------------------------------------------------------------------- > > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > > 30-Day > > trial. Simplify your report design, integration and deployment - and > > focus on > > what you do best, core application coding. Discover what's new with > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > _______________________________________________ > > Semediawiki-devel mailing list > > Sem...@li... > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- Markus Krötzsch <ma...@se...> * Personal page: http://korrekt.org * Semantic MediaWiki: http://semantic-mediawiki.org * Semantic Web textbook: http://semantic-web-book.org -- |
From: Temlakos <tem...@gm...> - 2009-08-26 22:17:55
|
Markus: This is certainly an interesting development, but now I need to know: Where does that leave a wiki administrator, like myself, who created a multitude of properties of Type:Page, and their inverses, and even developed template code to mark up a page with inverse-property annotations to point right back to every page that pointed to the page in question? For example: in an article describing, say, the planet Saturn, I included this instruction: "Annotate this page multiple times with the property of "Satellite," the values of which shall be the names of every page that listed this page as "Primary." In that manner, Saturn is automatically annotated with [[Satellite::Mimas]], [[Satellite::Enceladus]], /et cetera/, because the articles on Mimas and Enceladus list Saturn as their primary. Now you tell me that, beginning with the next snapshot release of SMW, much of that markup will be unnecessary. In other words, if I wanted to find all the capital cities of a given region, I would need to: {{#ask:[[-Capital.region::Middle East]] }} and I would get Jerusalem, Amman, Damascus, Cairo, Baghdad, Beirut, Doha, and Kuwait City, so long as I had annotated the articles on Israel, Jordan, Syria, Egypt, Iraq, Qatar, and Kuwait with a value for the property called "Capital." Thus I would not need to annotate Jerusalem with the notation [[Is capital of::Israel]]. So tell me this: Would I ever need to make an explicit declaration of an inverse property? Under what circumstances would such inverse declaration be valuable? I can think of one: genealogical references. Specifically: the property "Father of" could have not just one inverse, but two: "Son of" and "Daughter of." Likewise, either "Son of" or "daughter of" has a non-exclusive inverse relationship with the properties "Father of" and "Mother of." Now if I had simply declared "Parent of" and "Child of," then the inverse relationships would be one-to-one and I could simply declare one or the other, and not both. Well, it looks as though I'll have a lot of cleanup to do. Clearly, a lot of those inverse properties will no longer be necessary. Question: Does SMW have a tool to find out which properties are currently referred to in a query or concept? I wouldn't want to "undeclare" or "deannotate" a property if it's going to break a query. Temlakos Markus Krötzsch wrote: > Using the Codeathon at Wikimania 2009, we have now implemented support for > "inverse properties". This email gives an overview of the features (usr > perspective) and internals (developer perspectives). Some SMW extensions will > need to be adjusted to work with the new feature. > > == Introduction == > > The inverse of a property simply is the property that points into the other > direction. For example, if "developer of" connects a person to a software > tool, then the inverse of "developer of" connects software tools to persons. > So far, it was very hard to use properties in other directions. In our > example, you could, e.g., have an ask query showing the all persons who > develop some open source tool, but you could not have a query that shows all > software tools that are developed by people living in Argentina. To do the > latter, you would have had to use a property "is developed by" that explicitly > connects software tools to their developers, and you would have had to add > data for that again. If you need both directions, you would have to maintain > both properties individually, which is not very convenient. > > == Feature Details == > > SMW (SVN) now allows you to directly refer to the inverse of any property by > simply putting a "-" in front of its name. For example, "-developer of" gives > you access to what I called "is developed by" above. This can be used in any > place where property names occur, including browsing special pages, ask > queries, and output directives of queries. So the projects developed by people > from Argentina can be obtained with a query > > {{#ask: [[-developer of:: <q>[[lives in::Argentina]]</q> ]] }} > > or simply > > {{#ask: [[-developer of.lives in::Argentina]] }} > > > We are aware that the "-" prefix is not the most readable way of solving the > problem. However, the solution we have now avoids a number of complications > that other solution would introduce (for example, you cannot have chains of > inverses, like Property:A inverse_of Property:B inverse_of Property:C > inverse_of ...; also, there is no relevant interplay of "subproperty of" and > inverses). > > If applicable, inverse properties generally are linked to the page of the > corresponding property (so "-developer of" links to "Property:developer of"). > It is strongly suggested not to create property pages that are called like > inverse properties (it won't destroy anything, but it might create unnecessary > confusion). Also, you cannot use inverse properties to enter semantic data > into the wiki: all annotations must be on the page that is the subject of the > non-inverted property. > > Inverses in queries are currently only supported if they are of Type:Page. > > > == Development Information == > > If your code uses SMW properties that are generated from user inputs, then you > need to be aware of inverse properties to make sure everything works > correctly. Internally, an inverse property, like any property, is represented > by an SMWPropertyValue object. It will look like the property value object for > the non-inverse version of the property. To check if it actually is the > inverse, you can use the new method isInverse(). You can pass inverse > properties to the SMW store, and it will take care of everything. > > The main changes that I expect to be required in SMW extensions is in places > where you deal with property subjects and silently expect them to be of > Type:Page. If users can enter inverse properties, then a query for a subject > can also return datavalues of other datatypes, so you need to use the generic > datavalue API, or check the type of the datavalue first. > > Another place where changes might be needed is when passing on parameters as > strings. If you use getWikiValue() on an inverse property, then you will > obtain the property name with "-" in front, as expected. But if you use > "getShortWiikiText()" and other functions, you will get the name of the > property without any "-". > > > I hope that SMW already works properly in all cases where inverses can occur. > Feedback is welcome. > > Cheers, > > Markus > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > ------------------------------------------------------------------------ > > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > |
From: Markus K. <ma...@se...> - 2009-08-27 20:38:44
|
On Donnerstag, 27. August 2009, Temlakos wrote: > Markus: > > This is certainly an interesting development, but now I need to know: > > Where does that leave a wiki administrator, like myself, who created a > multitude of properties of Type:Page, and their inverses, and even > developed template code to mark up a page with inverse-property > annotations to point right back to every page that pointed to the page > in question? For example: in an article describing, say, the planet > Saturn, I included this instruction: "Annotate this page multiple times > with the property of "Satellite," the values of which shall be the names > of every page that listed this page as "Primary." In that manner, Saturn > is automatically annotated with [[Satellite::Mimas]], > [[Satellite::Enceladus]], /et cetera/, because the articles on Mimas and > Enceladus list Saturn as their primary. > > Now you tell me that, beginning with the next snapshot release of SMW, > much of that markup will be unnecessary. > > In other words, if I wanted to find all the capital cities of a given > region, I would need to: > > {{#ask:[[-Capital.region::Middle East]] }} > > and I would get Jerusalem, Amman, Damascus, Cairo, Baghdad, Beirut, > Doha, and Kuwait City, so long as I had annotated the articles on > Israel, Jordan, Syria, Egypt, Iraq, Qatar, and Kuwait with a value for > the property called "Capital." Thus I would not need to annotate > Jerusalem with the notation [[Is capital of::Israel]]. Exactly. > > So tell me this: Would I ever need to make an explicit declaration of an > inverse property? No, you probably wouldn't. But the system that you set up as a workaround would of course continue to work, so you can decide whether you want to keep it (e.g. for the sake of the more readable labels). > > Under what circumstances would such inverse declaration be valuable? I > can think of one: genealogical references. Specifically: the property > "Father of" could have not just one inverse, but two: "Son of" and > "Daughter of." Likewise, either "Son of" or "daughter of" has a > non-exclusive inverse relationship with the properties "Father of" and > "Mother of." Now if I had simply declared "Parent of" and "Child of," > then the inverse relationships would be one-to-one and I could simply > declare one or the other, and not both. The properties "father of" and "son of" are not inverses in the usual sense of the word. The exact relationship between the two is more complex, and we do not currently have plans to support such descriptions in a formal sense. Of course, you can always "associate" such properties with each other in an informal way, but this would not be reflected in query results. > > Well, it looks as though I'll have a lot of cleanup to do. Clearly, a > lot of those inverse properties will no longer be necessary. Okay, great to hear that this simplifies your wiki setup. > > Question: Does SMW have a tool to find out which properties are > currently referred to in a query or concept? I wouldn't want to > "undeclare" or "deannotate" a property if it's going to break a query. I fear that we do not currently have a way for doing this, other than by full text search. For concepts, you can also find the query text within the database, so it might be possible to get these by searching the database. We intend to have a way of keeping track of queries within pages in the future, and such functions might be part of such an effort. But there is absolutely no record of this kind of information in SMW so far. Markus > > Temlakos > > Markus Krötzsch wrote: > > Using the Codeathon at Wikimania 2009, we have now implemented support > > for "inverse properties". This email gives an overview of the features > > (usr perspective) and internals (developer perspectives). Some SMW > > extensions will need to be adjusted to work with the new feature. > > > > == Introduction == > > > > The inverse of a property simply is the property that points into the > > other direction. For example, if "developer of" connects a person to a > > software tool, then the inverse of "developer of" connects software tools > > to persons. So far, it was very hard to use properties in other > > directions. In our example, you could, e.g., have an ask query showing > > the all persons who develop some open source tool, but you could not have > > a query that shows all software tools that are developed by people living > > in Argentina. To do the latter, you would have had to use a property "is > > developed by" that explicitly connects software tools to their > > developers, and you would have had to add data for that again. If you > > need both directions, you would have to maintain both properties > > individually, which is not very convenient. > > > > == Feature Details == > > > > SMW (SVN) now allows you to directly refer to the inverse of any property > > by simply putting a "-" in front of its name. For example, "-developer > > of" gives you access to what I called "is developed by" above. This can > > be used in any place where property names occur, including browsing > > special pages, ask queries, and output directives of queries. So the > > projects developed by people from Argentina can be obtained with a query > > > > {{#ask: [[-developer of:: <q>[[lives in::Argentina]]</q> ]] }} > > > > or simply > > > > {{#ask: [[-developer of.lives in::Argentina]] }} > > > > > > We are aware that the "-" prefix is not the most readable way of solving > > the problem. However, the solution we have now avoids a number of > > complications that other solution would introduce (for example, you > > cannot have chains of inverses, like Property:A inverse_of Property:B > > inverse_of Property:C inverse_of ...; also, there is no relevant > > interplay of "subproperty of" and inverses). > > > > If applicable, inverse properties generally are linked to the page of the > > corresponding property (so "-developer of" links to "Property:developer > > of"). It is strongly suggested not to create property pages that are > > called like inverse properties (it won't destroy anything, but it might > > create unnecessary confusion). Also, you cannot use inverse properties to > > enter semantic data into the wiki: all annotations must be on the page > > that is the subject of the non-inverted property. > > > > Inverses in queries are currently only supported if they are of > > Type:Page. > > > > > > == Development Information == > > > > If your code uses SMW properties that are generated from user inputs, > > then you need to be aware of inverse properties to make sure everything > > works correctly. Internally, an inverse property, like any property, is > > represented by an SMWPropertyValue object. It will look like the property > > value object for the non-inverse version of the property. To check if it > > actually is the inverse, you can use the new method isInverse(). You can > > pass inverse properties to the SMW store, and it will take care of > > everything. > > > > The main changes that I expect to be required in SMW extensions is in > > places where you deal with property subjects and silently expect them to > > be of Type:Page. If users can enter inverse properties, then a query for > > a subject can also return datavalues of other datatypes, so you need to > > use the generic datavalue API, or check the type of the datavalue first. > > > > Another place where changes might be needed is when passing on parameters > > as strings. If you use getWikiValue() on an inverse property, then you > > will obtain the property name with "-" in front, as expected. But if you > > use "getShortWiikiText()" and other functions, you will get the name of > > the property without any "-". > > > > > > I hope that SMW already works properly in all cases where inverses can > > occur. Feedback is welcome. > > > > Cheers, > > > > Markus > > > > > > ------------------------------------------------------------------------ > > > > ------------------------------------------------------------------------- > >----- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > > 30-Day trial. Simplify your report design, integration and deployment - > > and focus on what you do best, core application coding. Discover what's > > new with Crystal Reports now. http://p.sf.net/sfu/bobj-july > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Semediawiki-devel mailing list > > Sem...@li... > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- Markus Krötzsch <ma...@se...> * Personal page: http://korrekt.org * Semantic MediaWiki: http://semantic-mediawiki.org * Semantic Web textbook: http://semantic-web-book.org -- |
From: Markus K. <ma...@se...> - 2009-08-27 20:38:47
|
On Donnerstag, 27. August 2009, Jon Lang wrote: > Markus Krötzsch wrote: > > Jon Lang wrote: > >> Markus Krötzsch wrote: > >> > == Development Information == > >> > > >> > The main changes that I expect to be required in SMW extensions is in > >> > places where you deal with property subjects and silently expect them > >> > to be of Type:Page. If users can enter inverse properties, then a > >> > query for a subject can also return datavalues of other datatypes, so > >> > you need to use the generic datavalue API, or check the type of the > >> > datavalue first. > >> > >> Could you give an example of such a query, for illustrative purposes? > > > > What query do you mean? You mean the actual source code that uses inverse > > properties? It is not different from code using non-inverse properties, > > really. > > I mean, can you give me an example of a query that involves an inverse > property that would not be of Type:Page? #ask queries do not support inverses of properties that do not have Type:Page. I was talking about internal API-side queries. Especially, the store object of SMW has a method getPropertySubjects() that is given a property and a value, and which used to return all wiki pages where this property was given this value. For example, you can get all things that have value "1000" for property "population". With inverse properties, however, the same function can also be used the other way around: you can query for all things that have thee value "Germany" (wiki page) for property "-population". The result then might contain the number "80,000,000" (which is not a wiki page). Programmers thus need to be careful not to presume that the result contains only wiki pages. > > >> > I hope that SMW already works properly in all cases where inverses can > >> > occur. Feedback is welcome. > >> > >> This is a welcome step forward. The other feature that I'm hoping to > >> see relatively soon are transitory properties. > > > > This is much harder (I think you mean "transitive" here). > > Maybe not so soon ... > > I do mean "transitive"; sorry about that. > > Temlakos wrote: > > So tell me this: Would I ever need to make an explicit declaration of an > > inverse property? > > > > Under what circumstances would such inverse declaration be valuable? I > > can think of one: genealogical references. Specifically: the property > > "Father of" could have not just one inverse, but two: "Son of" and > > "Daughter of." Likewise, either "Son of" or "daughter of" has a > > non-exclusive inverse relationship with the properties "Father of" and > > "Mother of." Now if I had simply declared "Parent of" and "Child of," > > then the inverse relationships would be one-to-one and I could simply > > declare one or the other, and not both. > > Continuing the same example, there's another possible complication: > "Brother of" could have either "Brother of" or "Sister of" as an > inverse. In particular, a Property can be its own inverse. Yes, a property like "sibling of" can indeed be its own inverse. The inverse of "brother of" would be "has male sibling". Inverses are always unique and fully determined, but they do not always have a common name in daily life. > > From what I gather, the current version seeks to sidestep all of these > issues by not actually specifying an inverse property. Brother_of may > have either Brother_of or Sister_of as inverses conceptually; The notion of "inverse" as such has a very clear definition. The examples you mention refer to some other notion which would not be so easy to capture in a formal way. I think the relationship between "siter of" and "brother of" that you refer to could be described as: "The property "brother of" and the inverse property of "sister of" can have common instances, i.e. a person can be "brother of" another person, and at the same time be "-sister of" this person." This could be a relevant definition, but it would be very hard to exploit in #ask queries: knowing about this relationship between sister_of and brother_of does not give you any additional query results. So I don't see what SMW should do with it. > but > semantically, Brother_of has only one inverse: "-Brother_of". Right. The inverse in this case just does not have a good name. > > This is sufficient for the purposes of #ask; but it's less than > satisfactory if you intend to examine the SMW using an Ontology > analyzer. Can you give an example of such an "analyzer"? > For that, you need to declare what the inverses are. I > think I've got a way for this to be done that would maintain the > coherence of the SMW with minimal fuss for the page authors; but it's > harder to explain than it is to understand. The basic principles > follow: > > 1. Use the Property Pages to specify what the valid inverses are. > 2. When inverses are involved, use an extended version of the Property > syntax that lets you specify which inverse to use. This might require > SMW to verify an edit before accepting it. > 3. When an explicit inverse doesn't exist on the target page, SMW > pretends that it does, and uses the property's extended syntax to > decide what kind of property to tag the inverse as. > 4. When an explicit inverse already exists on the target page, > automatically rewrite the extended portions of one or both of the pair > of properties so that each conforms to the other property. This might > involve making a minor update to the target page. I can imagine that it could be done, but I still do not see what the purpose of specifying this kind of information is. The brother-sister-example really involves four properties: "brother of female sibling", "brother of male sibling", "sister of male sibling", "sister of female sibling". You seem to suggest to merge some of these into one property and have a new mechanism to distinguish which one is meant. My suggestion would be, if you really need this information in this detail, to create these properties and make them subproperties of "brother of" and "sister of" as appropriate. Then you can have this granularity of data in SMW without the need for any extension. Markus -- Markus Krötzsch <ma...@se...> * Personal page: http://korrekt.org * Semantic MediaWiki: http://semantic-mediawiki.org * Semantic Web textbook: http://semantic-web-book.org -- |