Re: SKOS Consistency

Hi Juan Antonio

Apologies if I misunderstood anything. A few comments below, I hope they're
helpful...

On Mon, Jul 12, 2010 at 08:24:55PM +0200, Juan Antonio Pastor Sánchez wrote:
> Dear Alistair:
> 
> I think that I do not explained well in my last message. Or maybe you
> did not get my full message (in your reply you mentioned only the
> first paragraph), because I did not say that such statements could be
> inferred automatically dynamically anyway.
> 
> As indicated, the discussion referenced in
> http://old.nabble.com/Dinamic-hasTopConcept-property-to26628730.html #
> a26628730, I ASKED about the dynamic inference of a property
> skos:hasTopConcept from the structure hierarchical relations of a
> conceptual scheme.
> 
> Because the answer of that discussion and my experience during the
> development of a thesaurus management system I have reached the
> following conclusions:
> 
> 1) The need to explicitly declare any SKOS statement (or RDF). Indeed,
> the ability to make logical inferences with skos:broader and
> skos:narrower is limited, (further discussion would be the same about
> skos:narrowerTransitive and skos:broaderTransitive). Perhaps this
> point should be a little clearer in future revisions of the SKOS
> ontology.

I'm not sure what you mean here. What inferences would you like to make?

> 2) On a more pragmatic sense, I think it is necessary to explicitly
> define the property skos:hasTopConcept for effective consultation of
> SKOS/RDF graph using SPARQL endpoints.

If you mean that you consider it good practise to state...

<S> skos:hasTopConcept <A> , <B> , <C> .

...where <A> <B> and <C> are the top-most concepts in scheme S, when publishing
complete RDF data for scheme S, then I agree. 

The main reason for including skos:hasTopConcept in the first place was in
fact to provide a convenient hook for querying the top-most concepts in a
scheme e.g. in SPARQL. (Otherwise, the SPARQL query to find all concepts
without a broader concept is awkward to write and also probably inefficient
to execute, because it relies on the negation-as-failure pattern [1].)

> 3) I think would be helpful that a thesaurus management software
> offers the possibility of detecting a conceptual scheme has no Top
> Concepts, and therefore OPTIONALLY provide its automatic creation.

This sounds like a useful feature.

> As you can see we think similarly. I think that we should not consider
> the execution of inferences from the SKOS model if not defined more
> precisely. It is risky to leave such decisions in the hands of
> automatic processes, and in any case management tools should provide
> the capability to detect incompleteness in the data and automatic
> creation (always supervised by the specialist).

Yes, sounds reasonable.

> A similar case can be found on the following statement:
> 
> <B> skos:inScheme <A>
> <B> skos:broader <C>
> 
> Surely, the SKOS model does not provide mechanisms to infer the
> following relationship:
> 
> <C> skos:inScheme <A>

Indeed it does not (we had a long and interesting discussion about this at the
library of congress back in 2008).

> But it might not be unreasonable that the management tool offers the
> POSSIBILITY of constructing (and maintaining) such statements
> automatically to facilitate management processes.
> 
> What do you think? Could be interesting for management software
> provides this functionality? or should we force the expert to manually
> define and maintain such statements?

Yes, I think this is very interesting. The two general SKOS-related features
for thesaurus management software are import and export. Export is usually
easy to do, because the TMS will maintain some internally consistent data
model, so you are usually guaranteed complete data on the way out. The
harder case is import, because how you process an import depends entirely on
whether you assume the data to be complete or not. I.e., if your thesaurus
tool assumes that an import is always a complete dataset for a scheme,
then it might want to raise errors if something appears to be missing,
rather than automatically add anything. On the other hand, if your tool can
handle partial imports (i.e., import of a part of a scheme), then yes, you
might want to add statements that appear to be missing, but also you might not.

Honestly, I hadn't thought much about this until you raised it, so it's an
interesting discussion. It would be interesting to review how the tools that
are out there handle import of SKOS data.

Cheers

Alistair

[1] http://www.w3.org/TR/rdf-sparql-query/#func-bound

> 
> Regards
> 
> 
> 
> El día 12 de julio de 2010 19:41, Alistair Miles
> <alimanfoo@googlemail.com> escribió:
> > Dear Juan Antonio,
> >
> > On Thu, Jul 08, 2010 at 06:58:50PM +0200, Juan Antonio Pastor Sánchez wrote:
> >> Hello Quentin,
> >>
> >> This issue is addressed in part when I raised the possibility of
> >> dynamic inference skos: hasTopConcept here:
> >> <http://old.nabble.com/Dinamic-hasTopConcept-property-to26628730.html#a26628730>
> >
> > I am assuming that, given a graph like...
> >
> > <A> skos:broader <B> ; skos:inScheme <S> .
> > <B> skos:inScheme <S> .
> >
> > ...you would like to be able to infer...
> >
> > <S> skos:hasTopConcept <B> .
> >
> > ...?
> >
> > If that is what you want, then note that this inference is *not* supported
> > by the SKOS data model. The reason for this is ... you guessed it ... the
> > open world assumption. I.e., in general, you cannot assume that you are in
> > possession of all the data ... there might always be more data out there. So,
> > the SKOS data model does not support any inference from the absence of data
> > (in this case, from the absence of a skos:broader assertion).
> >
> > You are, of course, free to make whatever non-standard inferences you like,
> > using whatever means, and to publish your inferences back out to the web,
> > although it's best to avoid publishing data that is inconsistent with respect
> > to the SKOS data model.
> >
> > Hth
> >
> > Alistair
> >
> >>
> >> I am currently developing a thesaurus management software based on
> >> SKOS and have come to the conclusion that the property must be
> >> explicitly declared. My opinion is based on the subsequent operation
> >> of schemes of concepts through Endpoints> <RDF using SPARQL.
> >>
> >> In this sense I think the management application must provide a
> >> maintenance operation that allows the inference of skos: hasTopConcept
> >> to allow more flexible management of a concept scheme.
> >>
> >> Regards
> >>
> >>
> >> 2010/7/6 Quentin Reul <quentin.reul@tenforce.com>:
> >> > Hi all,
> >> > I was looking at the SKOS reference [1] and I was unable to determine
> >> > whether a SKOS model would be consistent if no skos:hasTopConcept property
> >> > was defined within a concept scheme.
> >> > Cheers,
> >> > Quentin
> >> > [1] http://www.w3.org/TR/skos-reference
> >> >
> >> > --
> >> > Quentin Reul
> >> >
> >> > Semantic Technology Consultant
> >> > TenForce BVBA
> >> > Haachtsesteenweg 378
> >> > 1910 Kampenhout
> >> > Belgium
> >> >
> >>
> >>
> >>
> >> --
> >> Ph.D. Juan Antonio Pastor Sánchez
> >> Dep. of Information and Documentation
> >> Faculty of Communication and Documentation
> >> University of Murcia
> >> phone: +34 868 88 8780
> >> http://webs.um.es/pastor
> >> pastor@um.es
> >>
> >
> > --
> > Alistair Miles
> > Centre for Genomics and Global Health <http://cggh.org>
> > The Wellcome Trust Centre for Human Genetics
> > Roosevelt Drive
> > Oxford
> > OX3 7BN
> > United Kingdom
> > Web: http://purl.org/net/aliman
> > Email: alimanfoo@gmail.com
> > Tel: +44 (0)1865 287669
> >
> 
> 
> 
> -- 
> Ph.D. Juan Antonio Pastor Sánchez
> Dep. of Information and Documentation
> Faculty of Communication and Documentation
> University of Murcia
> phone: +34 868 88 8780
> http://webs.um.es/pastor
> pastor@um.es

-- 
Alistair Miles
Head of Epidemiological Informatics
Centre for Genomics and Global Health <http://cggh.org>
The Wellcome Trust Centre for Human Genetics
Roosevelt Drive
Oxford
OX3 7BN
United Kingdom
Web: http://purl.org/net/aliman
Email: alimanfoo@gmail.com
Tel: +44 (0)1865 287669

Received on Tuesday, 13 July 2010 08:38:56 UTC