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 <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.
------------------------------------------------------------------------------ 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 Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
