Re: [Semediawiki-user] combining online queries

[Markus <ma...@ai...>]

On Tuesday 16 May 2006 18:50, Olivier Dameron wrote:
> Hi Markus,
>
> On Tue, 16 May 2006 16:16:08 +0200, Markus Kr=F6tzsch
>
> <ma...@ai...> wrote:
> > It should work. A related remark first: if you want to say "rdf:type"
> > then you might prefer to use MediaWiki's categories.
>
> I really don't think so: how will I make the difference between
> [universities or partos of universities] on one hand, and things that are
> somehow related to universities ont the other hand ?

I don't quite get this example, but I am sure that you can find many exampl=
es=20
that demonstrate your point. We clearly do not increase expressivity by=20
limiting the set of URIs that wiki users can refer to! So this is all agree=
d.

Our motivation is in fact different. SMW is planned to be a tool for=20
semantically annotating a wiki in the wiki-way. The primary purpose here is=
=20
to structure the existing data in the wiki. We want to give the users total=
=20
freedom about the language elements, i.e. individuals, properties, classes,=
=20
that are described or used for description. We do, however, not want to let=
=20
users choose the structuring paradigm (e.g. "Do we use OWL or RDFS=20
classes?"). This should eventually be the choice of the wiki admin, since i=
t=20
has many technical ramifications (which tools can you use? how complicated=
=20
are certain tasks? ...).

But if you allow reference to arbitrary URIs, then you might have users=20
referring to owl or rdf language constructs (which represent the underlying=
=20
formalism) as if they were actual language elements (e.g. properties). This=
=20
forces you to use either RDF or OWL-Full as a data model, and the admin has=
=20
no choice. In other words, the use of external URIs is a feature by which a=
=20
single article (and thus a single user) can enforce certain datamodels upon=
=20
the whole wiki. We think that this creates problems for the typical semanti=
c=20
web reuse scenarios, since you can no longer know what kind of data the wik=
i=20
exports: one day it is OWL-DL, another day, it is OWL-Full with all=20
OWL-language constructs redefined, yet another day, you have nice polynomia=
l=20
OWL-fragement of RDF. So everybody who uses the wiki's data must either=20
employ an OWL-Full reasoner ;-) or has to ignore/strip/reshape part of the=
=20
RDF export and thus to effectively change the knowledge the wiki exports. T=
he=20
wiki users cannot influence how this is done, and the reuser cannot foresee=
=20
what language the wiki-users will decide on today.

Other than this, I am fine with e.g. using some foaf-property like an=20
attribute within the wiki. And this might be enabled via=20
inter-project-link-like "interontology links" that are switched on or off b=
y=20
the admin. Then the admin also might decide to enable "rdf:" if he likes th=
is=20
concept of a wiki that can talk about the details of this W3C standard ...

Best regards,

Markus

>
> > For these, we
> > already have some limited support for hierarchy data (so sub-category
> > realtionsships are respected).
>
> I think that the problem to solve should drive the choice of the tool, and
> not the other way around.
>
> > This is not the case for any user
> > defined reltionship, be it called "rdf:type" or not. So, instead of
> > writing [[rdf:type::University]], consider using
> > [[Category:University]]. In this way, you end up with two
> > individuals: an article University and a category (owl:class)
> > Category:University. This is not much of a problem for wiki usage,
> > but of course you cannot put the Category:University into other
> > categories (you just can make it a subcategory). In short: you would
> > use the owl-class model where classes are interpreted as sets of
> > individuals -- not the rdfs class model where this is not the case.
>
> I am not sure I understand you correctly here:
> all owl:Class is an rdfs:Class. Even in owl, the subsumption relation is
> rdfs:subClassOf and the instanciation relation is rdf:type.
>
> I agree that I shoud make University an owl:Class and not a rdf:Class
>
> > In any case, I would avoid calling relations rdf:... simply because
> > this might be misleading for the users.
>
> then we probably need either a solution for hiding it from the user, or a
> solution for saying that the Is_a relation should be interpreted by formal
> tools as rdf:type. I am not so sure though.
>
> > In the rdf export, every
> > relation gets a URI along the same scheme, no matter whether it
> > starts with rdf: or not. So the real rdf:... properties are different
> > from the wiki's relations.
>
> Aaah, I was not aware of this.
> I find it confusing and somehow in contradiction with the capability to
> import ontologies. I can't think of any advantage for obfuscating the
> namespaces like it is currently done. Any hint?
>
> > This said, here comes your query:
> >
> > <ask>[[works at::<q>[[Category:University]]</q></ask>
>
> thanks
>
> > I guess mutliple levels of nesting are not supported (or only to some
> > degree).
>
> Right. No big deal though, as I believe this kind of thing is exactly what
> a reasoner (rdfs, DL,... whatever the user needs at usage time and
> according to its requirements) should do, and i don't see the point of
> having such reasoners embedded within semediawiki. I started thinking abo=
ut
> the possibility to call externa lreasoning services, but nothing matured
> enough yet.
>
> > * MediaWiki (Semantic or not) supports " " in article names. Hacks
> > like "_" or CamelCase are no longer needed. Just write as in normal
> > English texts.
>
> Point taken. This is an old habit from formal ontology tools and old scho=
ol
> wikis :-)
>
> > * Feel free to put the examples at [[Help:Inline query examples]] and
> > link it from [[Help:Inline queries]]. It would be a helpful addition
> > to our documentation.
>
> Will do.
>
> Cheers,
> Olivier

=2D-=20
Markus Kr=F6tzsch
Institute AIFB, University of Karlsruhe, D-76128 Karlsruhe
ma...@ai...        phone +49 (0)721 608 7362
www.aifb.uni-karlsruhe.de/WBS/     fax +49 (0)721 693  717