Re: [Sorry, resend whole message] Re: reusing vocabularies / mapping withowl:equivalentClass

On 15.10.08 11:57, "Hugh Glaser" <hg@ecs.soton.ac.uk> wrote:

> [Hit the wrong key, please ignore previous email]
> 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?

Then why was owl:equivalentClass added to the standard? ;-)

In the case I'm working on, a recipe format, there are other formats, but
they all have their drawbacks and developing a new voacbulary seemed
justified. But of course the preexisting vocabularies where/are not totally
useless, so it makes sense to express equivalences.
A vocabulary is made of several terms and they all belong together. A recipe
format with ingredients but without method goes only halfway. To express
that connectedness I find it justified to define a whole vocabulary and then
map terms where appropriate to other terms. Maybe it's okay to use dc: for
the really very standard parts like title and author but apart from that I
want the whole thing to look and feel self contained. That sounds like a
rather aesthetical and therefor negligable argument but otoh it seems
unevitable to me that different vocabularies have to be mapped that way
because it's just unthinkable that everyone agrees on the same terms. So why
not take that necessity into account, instead of toilsomely reusing terms
from 7 different vocabs?

> We find ourselves doing things like rdfs:subPropertyOf 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:
> "If you want to express that something has a name/title/label, use
> rdfs:label."

Did I say that? Actually I don't think that rdfs:label is the right choice
here. I'm not talking about names or labels for the same element, but about
different elements that are semantically equivalent. In my understanding
rdfs:label is used attach labels to elements like eg listname or full name,
labels in different languages etc.


Cheers
Thomas


> Such advice might be enhanced by:
> If you have something that can play that role, then please establish
> appropriate linkage to rdfs:label in the following way.
> 
> This seems to be very much the Linking Data world, but at the ontology
> level, which is where some focus is now being turned, with the new diagram
> appearing on
> http://esw.w3.org/topic/SweoIG/TaskForces/CommunityProjects/LinkingOpenData.
> Giving some more guidance on best practice, rather than allowing complete
> organic growth is often good.
> 
> Best
> Hugh
> 
> 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
>> 
>> 
>> 
> 



.
Thomas Lörtsch
Living at Home Multi Media GmbH
Redaktion Online
..
Stubbenhuk 5
20459 Hamburg
...
eMail: loertsch.thomas@guj.de

Received on Wednesday, 15 October 2008 10:32:21 UTC