Jeff: you raise some interesting points. Let me try to address them: >From what I can tell, SMW is modelling itself after a subset of OWL. This is being done for compatability reasons: if it's modelled after OWL, then it should be trivial to export it as OWL, allowing other applications on the web an easier time in accessing your site without human intervention.
OWL comes in three flavors: OWL Lite, OWL DL, and OWL Full. At this point, we can pretty much discount OWL Lite; it isn't doing what it set out to do. This leaves us with OWL DL and OWL Full for consideration. According to the OWL Guide, "OWL DL supports those users who want the maximum expressiveness without losing computational completeness (all entailments are guaranteed to be computed) and decidability (all computations will finish in finite time) of reasoning systems. OWL DL includes all OWL language constructs with restrictions such as type separation (a class can not also be an individual or property, a property can not also be an individual or class)." Meanwhile, "OWL Full is meant for users who want maximum expressiveness and the syntactic freedom of RDF with no computational guarantees. For example, in OWL Full a class can be treated simultaneously as a collection of individuals and as an individual in its own right." It sounds to me that what you're after is akin to the latter: maximum expressiveness and syntactic freedom with no computational guarantees. As such, enforcing a disjunction between class and individual (e.g., restricting classes to the Category namespace and forbidding individuals from being placed in the Category namespace) comes across as an artificial and unnecessary distinction. Meanwhile, I've been approaching this with the idea of ensuring that OWL DL reasoners will be able to make use of the site. This means that SMW has to restrict its semantic capabilities to something that can be mapped to OWL DL. In turn, this means maintaining a strict separation between class and individual. Separating classes and individuals by namespace does this rather elegantly, and using the Category namespace for this purpose has a lot to be said for it - as long as it isn't done to the exclusion of more traditional uses of Categories. In addition, doing this means that you don't need separate properties to represent class membership and subclassing: if the Class property is used outside of the Category namespace, it defines a class/instance relation; if it is used in a Category page, it defines a class/subclass relation. _________________ That's not to say that there's no merit in your approach, or that it would be difficult to implement. Indeed, all you'd need to do syntactically would be to add '[[Is a::xyz]]' and '[[Subclass of::xyz]]' properties that don't assume that xyz is in the Category namespace. Semantically, you'd need to map these to rdf:type and rdfs:subClassOf, respectively; and you'd need to change the RDF import and export capabilities to be compatible with OWL Full instead of OWL DL. This last bit is potentially the biggest hurdle involved, since it determines which reasoning engines can access the wiki. -- 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
