Re: [Linking-open-data] [ANN] MOAT

On Jan 21, 2008 2:41 PM, Reto Bachmann-Gmür <rbg@talis.com> wrote:
> Alexandre Passant wrote:
> > Hi,
> >
> > On Jan 21, 2008 12:22 PM, Dave Reynolds <der@hplb.hpl.hp.com> wrote:
> >
> >> Alexandre Passant wrote:
> >>
> >>> On Jan 21, 2008 12:36 AM, Frederick Giasson <fred@fgiasson.com> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>>
> >>>>> Let's look at:
> >>>>> http://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20051102/img/ex-sub.pn
> >>>>>
> >>>> Yeah, so instead of a foaf:Document we would have a moat:Meaning. And
> >>>> instead of using a moat:concept, we would use a skos:subject.
> >>>>
> >>>> This could make sense intuitively. Would have to check further if it
> >>>> really does.
> >>>>
> >>> The problem here is that, again, the skos:subject range is a
> >>> skos:Concept, which will not allow people to use existing URIs that
> >>> are not defined as skos:Concept
> >>>
> >> Not sure I agree. It means that any URI you use in this way can be
> >> inferred to also be a skos:Concept. It may not have been labelled as
> >> such in the original source but that doesn't necessarily cause a
> >> problem, open world assumption and all that.
> >>
> >
> > I see what you mean, and it sounds ok theorically.
> > But in that case, using a skos:Concept in the ontology but telling to
> > users "use any URI you want" won't make sens I think. That's better to
> > tell them "use an URI" with an rdf:Resource range imho.
> > Moreover, some tools use domain / range of properties to filter
> > queries (eg: in ontology-based forms).
> > So using a skos:Concept may restrict the URIs to be retrieved.
> >
> Such a tool would be closing the world and thus not actually a semantic
> web tool. If you want to force the object to be a URI the range would
> have to be a typed literal. Having a range of rdfs:Resource people are
> free to use anything, including b-nodes an literals.

Thanks, I thaught having rdfs:Resource as a property range will imply
to use the URI of a resource.
So, is there any way to set the range as "the URI of some resource
(and not the one of the page that describes it)" ? Or should I use an
xml:anyURI range and then query that URI by asking for
application/rdf+anything to be sure it is something deferencable ?
(since this is what I want to explicit)
BTW, having a anyURI means the range is the URI or the thing that this
URI represents ?

Personally I don't
> see why "An abstract idea or notion; a unit of thought." (definition of
> skos:Concept) is too restrictive. I think a tool doing inferencing can
> safely deduct (and thus should be allowed to) that the object is an
> abstract idea.
The definition sounds good, but there's still that problem of
inconsistency it could lead to.

> >> It *could* lead to a inconsistency if there are some conflicting axioms
> >> but that seems somehow unlikely. Are there any specific examples of a
> >> resource one might want to use as in this way where inferring they were
> >> also a skos:Concept would lead to an inconsistency?
> >>
> >
> > In case I have my own ontology with a main Class that is
> > owl:disjointWith skos:Concept, because I explicitely do not want
> > people to use broader / narrower links between instances of this
> > class, it will fail.
> > Ok, this is just an example, but this is the kind of use case I want to avoid.
> >
> Could you be more concretely what class would not be suitable for those
> other skos-properties?

Imagine I extend FOAF to define a specific kind of agent. I don't want
the users of my system to say that one agent is broader that another
one, just because I think it makes no sense, and I don't want to get
this kind of triples in my knowledge base.
So to avoid those triples, I add a disjonction in my model.
This is only an example, but what I mean is that there could be use
case where infering the resource to be a skos:Concept may lead to
inconsistency.

Alex.

> Cheers,
> reto
>
> --
> Reto Bachmann-Gmür
> Talis Information Limited
>
> Find out more about Talis at www.talis.com
> Shared InovationTM
>
> Any views or personal opinions expressed within this email may not be those of Talis Information Ltd.
>
>
>

Received on Monday, 21 January 2008 15:14:38 UTC