path: root/pimo/doc/handbook_latex/solvedissues.tex

\section{Issues solved by Agreement}
\subsection{Relation between PIMO:Thing and NIE:InformationElement}
\paragraph{Background} PIMO:Things are unique representations of concepts, such as a person, a book,
  a product, a company. For these, often ontologies exist already in NIE, 
  for example nco:PersonContact models people and a bibtex ontology for NIE may be soon available.
  To identify and distinguish pimo:Thing, an instance needs to have all identifying properties of occurrences attached, so for example a pimo:Event should get the NCAL ncal:uid as a property to match it and a pimo:Person should have the nco:contactUID as property. This helps finding them in the various databases available. 
  So ncal:uid and nco:contactUID should be possible properties for a pimo:Thing (or subclasses). Using a property from NIE with domain nie:InformationElement on a pimo:Thing infers that the Thing is a NIE:InformationElement. Also, the user may want to use the ontologies defined in NIE to annotate people and events, for example NIE defines a relation that a person can attend a meeting, this does not necessarily be remodeled again in PIMO.
  \paragraph{Problem} The properties defined in NIE should not be modeled again in PIMO. Sometimes properties from NIE should be usable on PIMO:Things.
  \paragraph{Solution pimo:Thing rdfs:isSubClassOf nie:InformationElement}
  This solution would allow us to reuse properties from NIE within PIMO without any problems. Also, as NIE properties are all optional, Things are not invalid because they miss some properties. For specialized classes, it is possible to make them subclasses of the specialized NIE classes (pimo:Person rdfs:subClassOf nco:PersonContact). 
  Advantage: we reuse NIE completly for modelling in PIMO.
  Disadvantage: this would bind the PIMO classes with NIE.
  \paragraph{Solution nie:InformationElement rdfs:isSubClassOf pimo:Thing}
  This was a rather bad idea, that came up when we didn't want the first solution.
  The trouble here is, that suddenly all InformationElements would be Things,
  even if they are only extracted by DataWrapper, and then all data in the store
  is suddenly invalid because all InformationElements miss the required properties
  of pimo:Thing.
  \paragraph{Solution instances are then both pimo:Things and nie:InformationElements}
  A pimo:Person, before annotated with an identifier comign from NIE, would then
  also have a type of nie:ContactElement and have as only property the identifier.
  \paragraph{Intermediate Status} 8.1.2008: Knud, Leo discussed it, also looking at https://dev.nepomuk.semanticdesktop.org/repos/trunk/ontologies-public/2007/11/01/nietopimomapping.rdf
  \paragraph{Picked Solution} instances are both pimo:Things and nie:InformationElements.
  This was agreed by best practice and written down here on 30.7.2008.

\subsection{object property, datatype property, annotation-property}
In general applications, we have noticed that we need to distinguish
between object properties (relating a Thing with another Thing),
datatype properties (annotating a Thing with a literal),
and meta-properties that are generally not visible nor
editable by the user.

These are present in OWL and we may want to copy their modelling
approach.
Then, \texttt{pimo:isRelated}, \texttt{hasTopic}, \texttt{isTopicOf}, \texttt{hasPart} and \texttt{isPartOf} must be modelled as ``object property''.
At the moment, datatype properties are the duration of a meeting and the geo-position of a location.

There are two ways to express this modelling:
\note{Knud: 07.01.08: They must be sub-properties? Would they not be instances?}
\note{Leo: meta-modelling: I want to avoid creating new subclasses of rdfs:property and instead use sub-properties. 
Although both is possible in Protege, some Aimplementations will have hickups on resources being a pimo:DatatypeProperty while they expect a rdfs:Property.
Also, we then have trees of sub-properties nicely refining the three roots}
\begin{enumerate}
	\item using rdf:type and adding the rdf:type pimo:ObjectProperty to a  property in question
	\item using rdfs:subPropertyOf and adding the rdfs:subPropertyOf pimo:objectProperty to a property in question.
\end{enumerate}
Both express the same semantic meaning, but have different implications. 

We have chosen (2) (rdfs:subPropertyOf pimo:objectProperty) because of:
\begin{itemize}
	\item Using (1), you would have to add the rdfs:subPropertyOf annotation to any property in addition to RDF:type (speaking against 1)
	\item Using (1) you would have to make pimo:ObjectProperty a rdfs:subClassOf rdf:Property, and this would practically enforce that you have to add (x) rdf:type rdf:Property to any (x) that is marked as rdf:type pimo:ObjectProperty. In practice, you need the rdf:type rdf:Property because otherwise most command-line tools (for generating ontology mapping files, etc) and other tools which don't have inference won't work then anymore.
	\item Using (1) you can end up with sub-properties of pimo:isRelated which are not declared as pimo:ObjectProperty. This is semantically wrong, any sub-property of a object property is also an objct property, and the same with datatype properties
\end{itemize}



The \texttt{nao:prefLabel}/\texttt{nao:altLabel}/\texttt{nao:personalIdentifier} are borderline,
they should be meta-properties (implementors have to treat them specially anyway, no marking needed).
They should be, as any other nao property, marked as annotation-properties.

In the meaning and interpretation of owl, annotation properties must not be part of property axioms (subproperty relations), this will not hold for us.
But OWL also defines \texttt{rdfs:label} and \texttt{rdfs:comment} as annotation properties,
we would probably do the same.
\url{http://www.w3.org/TR/owl-ref/#Annotations}

\paragraph{Proposed Solution:} define \texttt{pimo:ObjectProperty}, \texttt{pimo:DatatypeProperty}, and leave out \texttt{pimo:AnnotationProperty}. Every property in an ontology that is meant to be editable by a user must be a sub-property of one of those. 
Gunnar, Leo, Knud like this.

\subsection{Abstract classes}
Some classes in PIMO are abstract and only used for meta-modelling, they should not be shown in user interfaces.
Agent, Locatable, LogicalMediatype, ProcessConcept.

We need a property to mark them. Protege has something like this: 
\begin{verbatim}
<rdfs:Class rdf:about="&pimo;ClassOrThingOrAssociation"
	 a:role="abstract">
\end{verbatim}

\paragraph{Proposed Solution:} pimo:role = pimo:Abstract or pimo:Concrete
Gunnar, Leo, Knud agree.


\subsection{Abstract object}
\label{issue:abstractobject}
Status: (Knud and Leo skype on 12th September.)
Knud suggests that this may already be represneted in the Thing class.

Knud: If there is a physical object in pimo:Upper, how about an abstract object?
Leo: we may want to consult Ludger and SUMO about this

\paragraph{Solution:} delete PhysicalObject, forget AbstractObject
Gunnar, Leo, Knud agree.

\subsection{Work Context / Multiple Domains (related to CDS?)}
In general modeling on the level of Tags and 
Things that occur throughout the whole PIMO of the user, 
the given structures of Thing and its subclasses are good.
Everything is related to everything.

There are cases when one single Thing has to be modeled
in a very detailled way, such as a single Document that
contains references to other documents, a list of people 
and a list of topics. 
The knowledge expressed here is interconnected and focused
on one topic/domain. The quality of the information
may be on the level of a brainstorm, including 
false information or wild ideas.
Also, there may be multiple documents about the same domain,
or multiple documents that express similar concepts, but
intentionally different.

The idea of a work context (or work domain) is to 
provide a container for knowledge articulation.
The user can create such domains to model knowledge
that is only valid within the domain, but not 
within his other PIM activities.

The work context can be used for smaller domains such
as writing one brainstorm document, or for larger domains
such as separating private life and business information.

\paragraph{Proposed Solution:} postpone the details,
suggested solution is to use pimo:Topics and ``HasTopic'' relations
of Things.
Agreed by Leo, Gunnar, Knud (8.1.2008)

\subsection{Naming of properties: x vs hasX}

Simon Scerri in email on 14.11.2007 to tf-ont:

May I remind why we could not stick to just one of the formats in the existing ontologies.

* Problem with the  'X format':
Property: nrl:semantics; Class: nrl:Semantics; ===> In this case its much more useful to have the property as nrl:hasSemantics for the difference between the two to be clearer.

* Problem with the 'hasX format':
Property: nao:prefLabel is a subproperty of rdfs:label. ===> Given the 'X format' of the rdfs super-property, a 'hasX format' for the sub-property is not the 'natural' guess. (This is the same in skos:prefLabel)

And so we had agreed that although sticking to just one standard format is nicer, there's no 'best practice' for these given reasons. But if I remember correctly, the 'hasX format' should be the first choice! 

\paragraph{Proposed Solution:} no changes to the ontology now, this has been going on forever without any final decision, short names are preferred though.
Agreed by Leo, Gunnar, Knud (8.1.2008)

\subsection{Incorporate Relations from AS}
Status: Knud looks at this and sees if it can be used
for the Organizational ontology.
If this cannot be done, no problem. This is a bonus level.

Benjamin Horak from DFKI made a multi-lingual ontology,
including alt-labels, for some common properties.
They are inspired by FOAF.

Leo: Perhaps we should move this to a domain ontology 
based on FOAF/FoafCorp?

http://www.dfki.uni-kl.de/~horak/2007/ontologies/docutag/as.owl\#

\paragraph{Proposed Solution:} leave it out,
maybe publish later
Agreed by Leo, Gunnar, Knud (8.1.2008)

\subsection{Representation of Time}
Status: (Knud and Leo skype on 12th September.)
Ludger had a representation of Time in the original PIMO-Upper,
I would propose we reuse the approach of NIE/NCAL for duration, point in time,
recurring events.
Then, we would delete ``TimeConcept'' from the ontology and copy the properties
from NIE to ProcessConcept. Any arguments if this is good or bad?

The decision was taken on the August TF-Ont meeting, we stick to XSD and provide a simple class for durations without further going into details.

\paragraph{Solution:} Remove TimeConcept and PeriodOfTime altogether.
Remove them from the chapter above ``representing time''. leave processconcept in.
Agreed by Leo, Gunnar, Knud (8.1.2008)


\subsection{Ludger, Michael, can't we drop hasOther* ?}
Leo thought on 12.9.2007, that we may not need hasOtherconceptualization and
hasOtherRepresentation anymore:

HasOtherConceptualization is captured already by subclass relations, external ontologies
can define subclasses of pimo:Upper classes. When a user creates a class in his PIMO,
it can be matched against any class from pimo:Upper or mid-level ontologies,
by annotating personal classes as subclasses of them. The semantics of hasOtherConceptualization does not affect the data in any way, changing it to subClassOf would have a clear semantics.

hasOtherRepresentation is already captured by the groundingOccurrence and occurrence relation. On itself, hasOtherRepresentation has the semantics of being a subproperty of pimo:occurrence. Maybe it is not needed and pimo:occurrence is enough.

Ludger supports both, they stay in.

\subsection{How to connect a Thing to the user - what are the Things of the user?}
The problem is: where does the PIMO of the user start and end?
Which Things are created by him and should be suggested for annotations,
which not?

There are two competing goals here, both contradict each other:
\begin{itemize}
	\item (A) Things used by the user should be in the attention of the user, created in an ordered process and formally well described. The list of ``all Things of the user'' should be exact. This implies that the Things are marked somehow.
	\item (B) Mid-level ontologies can contain Things shared across users, they should be 
	integrated without effort.
\end{itemize}

The solution to support A would be to add a pimo:definedBy annotation to each Thing connecting it to the PIMO of the user.
The solution to support B would be to use any resource that has type PIMO:Thing as a Thing used by the user.

Discussions were done many times, the last and final with Leo Sauermann, Michael Sintek and Sebastian Trüg on 21.11.2007 in Kaiserslautern.
Solution: use NRL:imports to define what elements are ``in the scope of the user''.
See also Section~\ref{sec:nrlgraphs}.

For pragmatic reasons, Leo added the recommendation to use pimo:isDefinedBy as NRL
is not fully available and its not clear how resources relate to graphs.


\subsection{hasOtherRepresentation, hasOtherConceptualization, hasOtherSlot}
\textbf{Agreement}: (Leo and Knud skype on 12.9.2007):
we make them subclasses/subproperty/grounding and see if trouble comes.

These could be subproperties of groudningOccurrence, rdfs:subClassOf and rdfs:subPropertyOf.
   But other ontologies not conformant to NRL would then cause trouble with our inference
   engine. So, what to do.

\subsection{How do we relate to NAO?} The identification properties are also in NAO. 
	NAO was started by using the core properties of the old PIMO, what to do now? 
\textbf{Suggestion Leo}: we subclass/subproperty from NAO, once NAO is in a usable state. We wait until NAO is finished and update PIMO then.

\textbf{This is done, as far as known. On review, hopefully some bugs are found}.


\subsection{Semantic Relations and inference, how to untie hasPart, Collections, and Topics.}
Agreement: (Leo and Knud skype on 12.9.2007) This has to be done with rules, using an inference engine. 
For rules, refer to the RIF group.
HasPart is not transitive, because there are papers that have proven that
hasPart is not always transitive. In some application domains, specific
subproperties of hasPart can be declared transitive.

	One Thing can both be a Topic of another Thing (hasTopic) or part of it (hasPart). 
	A project can be the topic of a document, and the document can be part of the project.
	The project can also be seen as a collection, namely a collection of Things that are part of the project or have the project as topic. This would be interesting to somehow represent in a way that would make use of transitive closures, for example when searching for ``documents that have the topic nepomuk'' users may expect to find documents that have the topic ``NRL'' which is a part of NEPOMUK. But actually, the topic of the NRL document is NRL, and it does not describe facts about NEPOMUK. But all these generic terms are - generic - so using them for inference may open a can of worms. Perhaps we should make hasPart transitive and see what happens. 
	We then also should say that: CONSTRUCT {?x pimo:hasTopic ?B} 
WHERE {?x pimo:hasTopic ?A. ?A pimo:partOf ?B.}

\subsection{Equivalence}
When using hasOtherRepresentation and hasOtherConceptualization
  we did assert equivalence (transitive, reflexive, symmetric). This sounds like it could
  cause trouble. Equivalence relations cause many triples to be inferred,
  if A and B are equivalent, Statements like (A p o) imply (B p o).
  \textbf{Agreement} by LeoSauermann, LudgerVanElst, MichaelSintek on 6.7.2007: we need transitivity to benefit from multiple hasOtherRepresentation, to find any hasOtherRep that is connected to a PIMO Thing. Reflexive/symmetric are open and not decided as ``must have''.

\subsection{pimo:user or pimo:isDefinedBy}
  One of the main ideas of PIMO is to get all Things (and their titles and types)
  of a user with the simplest query possible. We have to clearly decide how we
  mark which Things are part of a user's PIMO and which not. 
  One way is to connect Things to the PIMO-model, using the pimo:isDefinedBy
  property. This is similar to rdfs:isDefinedBy (which is discouraged by NRL,
  but we don't have to subproperty it).
  Or we use the property pimo:user, a subproperty of nco:creator,
  this has the advantage that automatically a creator is set.
  But the disadvantage that the user is not exactly the creator, but
  more his system is. Next disadvantage is that this triple
  asks for trouble when inserting it and validation is on,
  because pimo:user has many restrictions (claudia:Claudia pimo:user claudia:Claudia)
  Both solves the problem, we should decide for one.
  \textbf{Agreement} by LeoSauermann, LudgerVanElst, MichaelSintek on 6.7.2007:
  we use pimo:isDefinedBy and connect Things to the PIMO of the user, and the user to his/her pimo.
  
\subsection{What classes and instances appear in a user interface?}
	Assumed that many classes and instances are stored in an available RDF data store, 
	what classes and instances should be shown to the user? Are all of them of interest? 
	When applying filter rules, should the filter rules be excluding 
	(not wanted classes are filtered out) or including (wanted classes are filtered in).
	\textbf{Agreement} by LeoSauermann, LudgerVanElst, MichaelSintek on 6.7.2007:
  This is what NRL views were made for, we can give a recommendation how to do this
  using NRL.