Hi Markus,
I also make the same careful distinction as you about MW categories vs
RDF classes. I don't use categories for concrete RDF classes, as I
prefix concrete classes with "Type:" now storing them in the Main:
namespace (example: Type:Community). I use the word 'concrete' here to
indicate classes whose names are /nouns/.
Those classes whose names are adjectives ('Deprecated' for instance,
short for 'DeprecatedThings'), I have a different tactic: These are
categories though I prefix them with a "Tag:" prefix, eg
Tag:Deprecated, taking advantage of a "Tag" alias for the Category
namespace, so as to use SMW's present mechanisms without alteration.
This tactic may evolve, as my general strategy is to treat the Category
namespace as an unrestricted repository for users' folksononmy entries,
treating Type: and Tag: entries in a more controllable manner.
You may recall I have modified SMW to respect the MW setting for
initial-capitalization of pagenames in the Property namespace, to handle
xml-namespace prefixes correctly, eg "skos:prefLabel" not
"Skos:prefLabel". I'm interested also in distinguishing between common
nouns and proper nouns too. Recall I asked you about SMW's current
handling of the (old) Type namespace. I'd switch these class entries
(from the Main: namespace and the alias Tag: namespace) to controlled
namespaces when SMW can apply similar but optional 'partative'
processing within other namespaces as it does today within the Category
namespace.
Thanks/jmc
PS "Queries in SMW also interpret the category hierarchy in the same way
as OWL, but this can be switched off if it does not work for you."
How does one do this? Sounds like a good lead towards locating current
'partative' processing methods.
On 11/10/2013 11:33 PM, Markus Krötzsch wrote:
> On 10/11/13 13:06, Jonathan Lang wrote:
>> On Nov 10, 2013, at 2:33 AM, Markus Krötzsch <mar...@semantic-mediawiki.org>
>> wrote:
>>
>>> On 10/11/13 10:43, Niklas Laxström wrote:
>>>> What is OWA?
>>> John refers to the "Open World Assumption". This is an informal concept
>>> used in knowledge representation to describe the assumption that
>>> statements that are not made are "unknown" rather than "false". This is
>>> contrasted with the "Closed World Assumption" that is common in
>>> databases, where we assume that unspecified information is false.
>> -snip-
>>
>> Thank you for that; it was incredibly informative. If you don’t mind, I
>> have a followup question of my own:
>>
>>> What John refers to is that SMW assumes a default type for properties
>>> (Page). Therefore, the input behaviour is not monotonic: if you specify
>>> another type later, then this will make the formerly true type Page
>>> false. However, this is not a "violation" of the OWA. Wikitext is just a
>>> surface syntax and not the internal knowledge model of SMW. Wikitext can
>>> never be monotonic: for example, if a page contains
>>> "[[someprop::somevalue]]" and you add an input character "X" to obtain
>>> "[X[someprop::somevaue]]" then SMW will no longer contain the fact.
>>> Parser functions, templates, comments, etc. will all lead to similar
>>> effects.
>> I think I understand what you’re saying here. What I’d like to know is
>> whether any of this applies to the equivalency that exists (or is that past
>> tense? I’m a bit behind the development curve right now) between OWL
>> classes and MW Categories? That is, aren’t we making potentially
>> unwarranted assumptions about the semantic significance of a Category when
>> we assume that all Categories are classes, and vice versa?
> That depends on how you use MW classes. Instances of OWL classes are
> propagated up the hierarchy: if A instanceOf B and B subclassOf C then A
> instanceOf C). MW classes do not behave like this. If one uses MW
> classes in a way for which this behaviour is not useful, then OWL
> classes are not a good way to capture this. In this case, the OWL export
> that SMW generates is of limited utility. Queries in SMW also interpret
> the category hierarchy in the same way as OWL, but this can be switched
> off if it does not work for you. Assuming that all MW categories in all
> wikis are intended to be used like OWL classes would certainly be an
> unwarranted assumption. SMW does not make that assumption, but if you
> install SMW on a wiki with its default configuration, then you choose
> this as your preferred way of treating categories.
>
> Note that the previous paragraph speaks mainly about how a system
> behaves and whether this is desired or not. This is the only level on
> which we can discuss the relationship of MW and OWL -- considering them
> as pieces of technology that do something for the user. In particular,
> MW does not have a specified semantics (or even a formal syntax!), since
> it is not a format meant to exchange information across applications. So
> there is no right or wrong way of using MW categories, and one cannot
> say that they are generally compatible or generally incompatible with OWL.
>
> Cheers,
>
> Markus
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Semediawiki-devel mailing list
> Semediawiki-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
