- From: Hugh Glaser <hg@ecs.soton.ac.uk>
- Date: Wed, 15 Oct 2008 10:44:25 +0100
- To: Bernhard Schandl <bernhard.schandl@univie.ac.at>, Knud Hinnerk Möller <knud.moeller@deri.org>
- CC: Thomas Loertsch <loertsch.thomas@guj.de>, Semantic Web <semantic-web@w3.org>
Not addressing performance, but more the advice question, and linkage and
re-use:
Yes, rdfs:subClassOf and rdfs:subPropertyOf seem more sensible than
owl:equivalentClass for many things, and certainly for rdfs:label sorts of
things.
If you can use owl:equivalentClass, why did you invent a new concept and not
use rdfs:label in the first place?
We find ourselves subClassing rdfs:label for many things when we use stuff
from outside, so that our human interface tools can work. It would be a
great help if providers could do that for us, and after all they are the
people who know best what is sensible.
So Thomas says he would like to see guidance such as:
On 15/10/2008 07:07, "Bernhard Schandl" <bernhard.schandl@univie.ac.at>
wrote:
>
>
> Hi Knud,
>
>>> That way a query for everything with a 'title' could automagically
>>> sparql
>>> the clearinghouse for every owl:equivalentClass of 'title' and add
>>> those to
>>> the original query. That's a scalable solution and it doesn't need
>>> much
>>> (actually none if I'm not mistaken) inferencing power either.
>>
>> That's an interesting idea. It would be interesting to find how this
>> compares performance-wise to "ordinary" inferencing.
>
> We did this regularly in several applications, however we were not
> using owl:equivalentClass but rdfs:subClassOf and rdfs:subPropertyOf;
> and we applied this not only to labels but also to class instances:
>
> SELECT ?r ?l
> WHERE
> {
> ?r rdf:type ?t .
> ?t rdfs:subClassOf my:Something .
> ?r ?p ?l .
> ?p rdfs:subPropertyOf rdfs:label .
> }
>
> This of course requires the full closure of subClassOf and
> subPropertyOf relationships to be computed (but this can usually be
> done once and then is persisted). We found this performs quite well in
> comparison to fully fledged inferencing; however it has the drawback
> that reasoning is encoded into applications, which one might find not
> a nice solution.
>
> Best regards,
> Bernhard
>
>
>
Received on Wednesday, 15 October 2008 09:45:28 UTC