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