stanbol-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olivier Grisel <olivier.gri...@ensta.org>
Subject Re: Stanbol Enhancement Structure (discussion)
Date Mon, 07 Mar 2011 11:17:06 GMT
2011/3/7 Rupert Westenthaler <rwesten@apache.org>:
>
> or (3) force implementors of EnhancementEngines to add both
> sb:Annotation and sb:EntityAnnotation as rdf:type.
>
> All this three Solutions do not seam very promising because
>  - users will not want to enable reasoning
>  - UNIONS do make queries very complex, and what happens if we add an
> other Annotation type?
>  - adding multiple rdf:types would be nice solution for the client
> side, but has the danger that some functionality will break if an
> EnhancementEngines does not add the additional type.

I agree we should not impose UNIONS of rdfs reasoning to the client
side. I had solution 3 in mind: every time you add an annotation that
is about the identification of an Entity in the text (as opposed to
the time of annotations such as finding the topic of the content item,
the language, a keyphrase, ...), the enhancement engine should add
both rdf:type sb:Annotation and rdf:type sb:EntityAnnotation. If it
does not it's considered a bug and has to be fixed.

The goal is to make it more explicit to the client what kind of
annotations it is: it can be useful to define a mapping from
annotation sub type to an icon in UI in the client for instance. I we
do not make this explicit, the client will have to implement many
rules to test for attribute presence to guess  the subtype and display
the right icon in the UI.

> Therefore I would suggest to just define sb:Annotation in the
> Enhancement Structures. If someone is only interested in
> EntityAnnotations he need only to add the sb:entity and the
> sb:entity-type property as required constraints to the query.
>
> select ?entityAnnotation, ?title, ?entity, ?type
> where {
>   ?entityAnnotation rdf:type sb:Annotation .
>   ?entityAnnotation dc:title ?title .
>   ?entityAnnotation sb:entity ?entity .
>   ?entityAnnotation sb:entity-type ?type
> }
>
>
> Even if concepts like "sb:EntiyAnnI otation" are not part of the
> enhancement structure we can add them by defining them (formally) in
> an own model that users can load if the want to use reasoning. Such a
> model would use OWL as an ontology language and also assume that when
> it is used an OWL reasoner is present.
> Within such an model the Concept "sb:EntityAnnotation" would be
> defined by declaring that it is an "sb:Annotation" with two
> owl:someValuesOf restriction for "sb:entity" and "sb:entity-type". In
> addition if would define "sb:entity" as an owl:FunctionalProperty
> (meaning that it can only have a single value).
> An OWL reasoner would now be able to deduce that an
> "sb:EntityAnnotation" instance with a value for sb:entity and one or
> more values for sb:entity-type is actually an "sb:EntityAnnotation"
> instance.

I agree we can have intentional definition of the sb:EntityAnnotation
sub-type but that impose further burden on the client who must either:
- have a owl reasoner (and understand how OWL reasoning works and the
intentional type definition approach)
- be a master of SPARQL playing with OPTION and FILTER (which is BTW
probably less efficiently computed on the server side than explicit
queries on materialized sub-types).

My will to introduce the sb:EntityAnnotation sub-type is to make the
model more explicit to reduce the cognitive pressure on the client and
an the expectations put on the query plan optimizer on the server.

> About sb:Suggestion
>> For Suggestion I would rather name it LinkingSuggestion,
>> LinkSuggestion or ResolutionSuggestion to make it explicit that is
>> this type of enhancement is about suggesting to link to a resource
>> from the LOD cloud or from a private LinkedData knowledge base (using
>> the entityhub as proxy).
>
> Defining sb:LinkSuggestion and sb:ResolutionSuggestion as
> rdf:subClassOf sb:Suggestion would cause the same problems as
> described for sb:Annotation. Therefore I would recommend to use only
> sb:Suggestion and use an property to distinguish between these two
> types.
>
> The sb:LinkSuggestion and sb:ResolutionSuggestion concepts can be
> defined in the Reasoning (OWL) model if needed.

My proposal was not to make sub type sb:Suggestion with
sb:LinkSuggestion but to rename it.  sb:LinkSuggestion would be a
toplevel type in my model. Unless you have other kind of suggestions
that are not about linking with resources.

But I agree we can keep the sb:Suggestion name if you prefer.

As for Occurrences we agree, hence no further comments here.

Regards,

-- 
Olivier
http://twitter.com/ogrisel - http://github.com/ogrisel

Mime
View raw message