Laurent - here you advocate putting the linking properties within the parents' pages (i.e., having a menu point to its menu items), which is actually the opposite of what's advocated in the "Data design issues" section. Is that on purpose, or by accident?

-Yaron


On Wed, Dec 17, 2008 at 11:44 PM, Laurent Alquier <laurent@alquier.org> wrote:
If that can be of any help, I have had great success so far, following an extrapolation of the rules of thumb from the 'Data design issues' link below.

When in doubt about making changes to the data model of my semantic media wiki, I try to remember the following :

- Categories are used to represent what an entity IS (hopefully, an entity can BE only one thing at a time)
- Properties are there to annotate a property that an entity HAS
- Link children back to parents 

For example, in the situation of Restaurants, Menus and Menu Items, I would create three categories - one for each entity.

A restaurant would have a couple of properties [[Has menu::.....]] defined (one menu for lunch and one for dinner for example).
A menu would have several properties [[Has menu item::....]] defined (to build a menu from a pool of possible menu items)
A menu item would have properties such as [[Has description::....]] or [[Has calorie count::....]].

What if an entity is two things at once ? A restaurant is also a business. I would select one category to be the main Category for the entity and I would model the relationship to the other category using a property. 

I would create a Restaurant called 'Cafe Paris' and a Business called 'Cafe Paris (business)'. The Restaurant would then have the property : [[Has legal entity::Cafe Paris (business)]]. 

'(business)' is there to differenciate both pages. You could just as well have 'Cafe Paris Co.' or whatever the right legal name is in your context.



A nice side effect to limiting categories to only one per page is the possibility to query classes of pages with one category.

For example, if you create a category Location and sub categories Country, City, Building, you can query all locations using : 

{{#ask:[[Category:Location]]....}} 

instead of : 

{{#ask:[[Category:Country||City||Building]]....}} 




I noticed it is very easy to deviate from this model and to want to group sub categories with the meaning 'Is part of' instead of 'Is also'.

For example, it would be tempting to create this hierarchy of categories :

Location
 - Country
   - City
     - Building

But doing so, a query for all Countries will return Cities and Buildings as well. 

A preferred hierarchy is to stick to the 'Is also' relationship (as in 'A city is also a location')

Location
  - Country
  - City
  - Building

Country, City and Building are all locations and should be treated at the same level.

You can build the 'Is part of' relationship using a property [[Is located in::....]] to link a City to a Country, or a Building to a City for example.




Linking children back to parents is also a great rule of thumb. 

Sometimes though, it is necessary to create reverse relationships. For example, you may want to list all menu items and show in which menu each one is used. 

The documented way using Templates is nice but it has limitations (especially if your page names have special characters such as ',' or '&'). It would be a lot better if or when Semantic Mediawiki supports real reverse relationships.

- Laurent Alquier


On Dec 17, 2008, at 3:13 PM, Yaron Koren wrote:

This section also covers some of the questions you raise - I think it's valid regardless of whether you use Semantic Forms:


Among other things, it recommends that "children" point to "parents", and not the other way around - in your case, it would be menu items having a "Has restaurant" property, etc.

-Yaron


On Wed, Dec 17, 2008 at 2:08 PM, Tempich, Christoph, Dr. <Christoph.Tempich@detecon.com> wrote:

Hi Mat,

I guess the dicussion some time ago

http://www.nabble.com/Guidelines-for-%22knowledge-modelling%22-in-SMW--td20606617.html

might help you. At least as a starting point.

Christoph

-----Ursprüngliche Nachricht-----
Von: Mat Mikul [mailto:mat.mikul@gmail.com]
Gesendet: Mittwoch, 17. Dezember 2008 19:25
An: semediawiki-user@lists.sourceforge.net
Betreff: [Semediawiki-user] Category versus Property


Hi,

I am trying to move my web based backend to instead use mediawiki. I am trying to figure out what to use - category versus property at a high level.
Is there a tutorial of some kind available somewhere?

My top level class is Restaurant and I therefore have a database table today by that name. For each Restaurant, I have menu items. And for each menu item I have ingredients.

This is implemented today as a 3 table database. Now I'm trying to move to semantic mediawiki (with semantic forms). I create Restaurant as a category and similarly Menu Item as a category and Ingredient as a category. In order to establish connections between them, I guess I should use property right?
Like each Ingredient having a property Menu Item and each Menu Item having a property - Restaurant? Or is it that the Restaurant has a property Menu Item? Or is Menu Item a subcategory of the category Restaurant?

Thank you
Mat
--
View this message in context: http://www.nabble.com/Category-versus-Property-tp21058582p21058582.html
Sent from the Semantic Mediawiki - User mailing list archive at Nabble.com.


------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Semediawiki-user mailing list
Semediawiki-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-user

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Semediawiki-user mailing list
Semediawiki-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-user

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/_______________________________________________
Semediawiki-user mailing list
Semediawiki-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-user


------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Semediawiki-user mailing list
Semediawiki-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-user