1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
|
\section{Issues Intentionally not handled by PIMO}
\subsection{Complex identifiers}
For identifiers that consist of multiple keys, or that go along more than one resource,
we need some way to capture them.
suggestion:
{\small
\begin{verbatim}
pimo:ComplexIdentifier a rdfs:Class.
pimo:ComplexIdentifierQueryBased a rdfs:Class;
rdfs:subClassOf pimo:ComplexIdentifier.
pimo:complexIdentifierTriggerProperty a rdf:Property;
rdfs:comment """The object property indicates that
the subject Query based complex identifier should
be triggered, when a resource has the property set.
For the email example, this would be
nco:hasEmailAddress""" ;
rdfs:domain pimo:ComplexIdentifierQueryBased;
rdfs:range rdf:Property .
pimo:complexIdentifierQuery a rdf:Property;
rdfs:comment """Defines a query with one parameter,
?x, that is to be filled in. The query selects
other variables (?y, ?z, ?a, ?number, etc.) that
have to be the same so that two entities can be
considered same. Example for e-mail:
SELECT ?x ?mail
WHERE {?x nco:hasEmailAddress ?e.
?e nco:emailAddress ?mail.}"""
rdfs:domain pimo:ComplexIdentifierQueryBased;
rdfs:range rdf:Literal.
\end{verbatim}
}
\paragraph{Proposed Solution:} Mention that it is a problem, but give no indications for solution. Say that nao:identifier has to be enough.
Knud, Leo, Gunnar agree on this on 8.1.2008
\subsection{Modelling Default Properties and Things that have instances}
How to model the Book ``Moby Dick'' in the version published in
1960 with 300 pages? (example invented)
It would be an instance of the class ``Book Edition''.
Now given I have a copy of the Book, then I have an instance of ``Book Copy'',
called ``Dirks's Moby Dick with Serial Number 123''.
Dirk's Moby Dick has also 300 pages, but may have a sticker on the cover
and an annotation of ``borrowed to claudia''.
The same problem arises with electronic gadgets, etc, every product.
\paragraph{Proposed Solution:} Leo: No Solutions, don't mention it.
Leo, Knud agree on this on 8.1.2008
\subsection{Associations implying Statements}
Current status (Knud and Leo via Skype, 12.9.2007):
We would say that this is useful and that statements and associations can be linked.
Revised by Leo on 13.12.2007: no time to work on this, finish the existing Things first.
A first suggestions for modelling it is in this document.
Implementation is left open for now.
One major Thing is open:
subclassing from NAO,
I can only do that once the RDFS is fixed.
Another old idea I have to mention now, because it fits to the discussion:
The problem is that often, relations are not just a statement (=triple) but have some metadata,
or that N-Ary relations cannot be expressed using plain RDF. (In XML topic maps, they can)
Typical problem:
STATEMENT:
http://sap.com - foaf:member - http://sap.com/claudia.
A way to model this (this already in the PIMO last year)
ROLE:
x - type - pimo:Role;
roleHolder - http://sap.com/claudia;
roleContext - http://sap.com;
roleValid - y.
y - type - pimo:Duration;
beginTime "..."
endTime "...".
Now, this is all pretty straightforward
To realize an effective way of doing all this, I propose to use a meta-modelling approach, where Associations (Role is a subclass of Association) are linked to imply statements of certain property, and vice versa, that statements using a property imply that an Association must exist.
Using above model Role, this means:
STATEMENT -> ROLE.
ROLE -> STATEMENT.
> Looks good to me. But how would you link specific roles with specific properties, e.g. 'Member' with 'memberOf'? This is required for this to work.
like this:
pimo:Member pimo:impliesStatementRule
"CONSTRUCT {?x pimo:hasMember ?y} WHERE {?association pimo:memberPerson ?y; pimo:memberOrganization ?x}".
This requires you to model the properties and classes beforehand:
* pimo:hasMember as the direct relation between person and organization,
* the Member class with properties
* pimo:memberPerson and
* pimo:memberOrganization.
is not done yet, but is probably interesting to do.
|
