Sergey Chernyshev wrote: > I think some of this issue was tried to be addressed with n-ary relations > http://semantic-mediawiki.org/wiki/N-ary_relations > > But they were not implemented in the extend it was originally planned - > here's original page on Ontoworld and associated talk page: > http://ontoworld.org/wiki/N-ary > http://ontoworld.org/wiki/Talk:N-ary_relations > > I'll be happy to continue discussion on this issue.
Yes. I found the N-ary relations stuff after I had made my original post on this subject, and briefly considered dropping the issue, as both approaches handle very similar problem-domains. However, I think that the "virtual page" concept brings some flexibility to the table that n-Ary relations (rather, n-Ary properties) lack. Strictly from a mechanical perspective, I'm pretty sure that an arbitrary n-Ary property could be transformed into a set of 1-ary properties on a related page with no loss of information. The main problem with doing so is that it doesn't always make sense to define an actual separate page for a given collection of properties - but that's exactly the issue that the virtual page concept addresses. The only things you have to do with a virtual page that you don't have to do with an n-Ary property is to assign an identifier to it, and to separately assign a property that relates the virtual page to the page that it's on. Indeed, the latter technically doesn't _have_ to be done; but if it isn't semantically related to its hosting page, why is it there? n-Ary properties add complications to the querying mechanism; in particular, there's the matter of what to do if the property value that you're including in a query shows up in an n-ary property: what do you return? And the person creating the query also has to address the issue of whether or not the property that he's looking for might show up within an n-ary property. With virtual pages, no such complications exist: simply return the URL of the virtual page. n-Ary properties complicate the terminology: what do you call a property-within-a-property? The intuitive answer (a "sub-property") is wrong. I'm leaning toward calling n-ary properties "structured properties", and the properties encapsulated within their values "fields". n-Ary properties require that you define all of the property's fields in one place: namely, within the value of the property. A virtual page's properties _can_ be defined in proximity to one another and/or in proximity to the virtual page's identifier if it makes sense to do so; but that's a matter of choice on the page editor's part, not a mandate being forced on him by the system. If he wants to summarize a bunch of virtual pages' properties in a single table and then talk about some of the more notable ones afterward, he can do so. If we were to apply the n-ary property concept to Temlakos' "gas giant satellites" problem, the result would be messy: either all of Jupiter's moons would be treated as n-ary properties of Jupiter, or its major moons (Callisto, Ganymede, Europa, and Io) would be handled as related pages while the remaining moons would be treated as properties of Jupiter. The former is a problem because moons such as Europa _do_ warrant their own pages; the latter is a problem because mixing related pages and properties-within-properties leads to semantic discord. But because there's no semantic difference between a virtual page and an actual page, no such problems arise in this paradigm. What n-ary properties have going for them is that it's impossible to forget to associate the encapsulated information with the page that it's on, and that you don't have to assign unique identifiers to each "structured property". -- Jonathan "Dataweaver" Lang ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
