Hi
Just a quick question on this. We develop the model
independently of technology. I can see that this discussion is
getting technical. I currently implement propositions sets using
RDF named graphs because we can and it works but it is
not stipulated. Rob suggests that there are tech upgrades that
might suit this issue better. However, isn't it the case that we
need to be able to implement in different ways (I don't
currently know much about RDF*) depending on the systems we
have? How is RDF* implemented? - is it backwardly compatible
with what we are all using? Do we give more modelling credence
to things that everyone uses? etc., etc. But aren't these
questions the reason why we are technology independent? Given
this, my question is, - have we got to a stage when the
modelling now depends on a particular technology? Can someone
provide some clarification on this? Which solution is tech
independent? Are they all independent of this tech discussion?
One is at least.
D
On Thu, 11 May 2023 at 16:18, Martin Doerr via Crm-sig
<crm-sig@ics.forth.gr> wrote:
Dear Robert,
We have just created the new issue to discuss this in
detail. We should prepare a detailed analysis, citing all
pros and cons. May be we continue this discussion better in
a subgroup?
Named Graphs are not a very specific technology, if we take
the fact that all current triple stores are actually
implemented as quad stores, regardless whether they call the
construct "Named Graph" or "context". We have used and
implemented this feature, and it is very performant. It runs
on BlazeGraph as well. I think their is not a simple answer
to that. Performance can become a major issue, when you have
really a lot of data.
For the attribution of artists and "style of" vs "school of"
etc. of the collection management system of the British
Museum, the ResearchSpace Project had created a set of
subproperties of P14 carried out by, which could be used as
input for a roles vocabulary.
I did not propose to use Dig as is, but to consider the
construct. The W3C annotation model is very interesting. We
would need a connection to the Creation Event of making an
annotation, and whose opinion it is, in order to make it CRM
compatible. Why not allowing a Named Graph as target? We
should compare the segment construct of the W3C annotation
model with the METS <area> types and extensions we used. The
Dig model was used to trace provenance of annotated area
through transformations of digital objects. That was very
important for exchanging research insights on 3D models. To
be discussed!
We can extend E13 to Proposition Sets, which would be very
important to describe consistently CRMinf and generalized
observations. That would then be most effectively implementd
via Named Graphs.
Opinions?
Best,
Martin
On 5/11/2023 3:41 PM, Robert Sanderson wrote:
If the intent is that the assertion is in the discourse,
and not a syntactic workaround for .1 properties that would
be unnecessary if we had RDF* or property graphs, then I
would say E13 is exactly the right approach to use. In
comparison, I consider the PC classes to be just that - a
syntactic work around needed in RDF and not part of the
discourse. In LInked Art, in a discussion around uncertain
attribution of artists and "style of" vs "school of", we
posited the need for a property on E13 for this scenario.
(Also the need for .1 on P11 for the same reason as we have
it on P14)
I would say that Dig's annotation is *not* the correct
approach for several reasons:
* Named Graphs are a very specific technology that have
never seen significant uptake and are likely (IMO) to
decrease in usage once RDF* is formalized.
* Dig needs to be updated, and Annotation is (I would hope)
likely to go away ... because ...
* ... it could just use the Web Annotation Data Model:
https://www.w3.org/TR/annotation-model/
(And reification has all the problems discussed in this
thread already)
Rob
On Thu, May 11, 2023 at 7:17 AM George Bruseker via Crm-sig
<crm-sig@ics.forth.gr> wrote:
Dear Martin,
I agree that E13 is a poor man's solution to a
complicated problem. But it is for some, the solution
available. Other solutions like Inf for documenting
historical argumentation and using named graphs is
great as a possibility. Using prov o to represent the
meta discursive level of the provenance of the dataset
as such great. But my immediate interest was simple
the humble ability of E13 to be able to point to all
statements that can be made with precisely one link in
CRM. I'll keep watching the space!
Cheers,
G
On Thu, May 11, 2023 at 1:25 PM Martin Doerr
<mar...@ics.forth.gr> wrote:
Dear George,
I agree with you below about the historical
aspects. The annotation model has the same
historical aspect, but is not limited to a single link.
Let us discuss!😁
Best,
Martin
On 5/11/2023 12:41 PM, George Bruseker wrote:
Dear Francesco, Martin,
Again for the record since I seem to be being read
at cross purposes, when I mention the word
'provenance' I do not mean it in the sense of
dataset provenance (to which prov o would apply).
I mean that in the world to be described (the real
world of tables charis cats dogs scholars ideas
etc.) there are real world events in which people
attribute things to things (see my
previous email). This is content of the world to
be represented in the semantic graph (not a
metagraph about the graph). This is describable
and is described in CIDOC CRM using E13 and its
friends. If you want to say that there was a
historical situation that someone in your
department said (likely in the information system)
that some attribute related two things you can do
this with E13 (or I have completely misunderstood
the CIDOC CRM). This happens all the time in art
history. One particular often arising case is an
argument about who played what role in some
object. Was Davinci the painter or was it Simon?
This is just a hum drum case of needing to apply
CIDOC CRM to real cases. Since E13 is a mechanism
for so doing on all other statements, it would be
a logical continuation that it could be used also
on .1 statements. But for technical reasons it
cannot, that is why I suggested a mild technical
solution that makes the technical
extension logically coherent. It is in this sense
that I mean provenance and not in the metasense of
the provenance of the data qua data, also an
exciting but other issue to my mind.
Cheers,
George
On Thu, May 11, 2023 at 12:27 PM Martin Doerr via
Crm-sig <crm-sig@ics.forth.gr> wrote:
Dear Francesco,
This is an excellent paper.
I cite: "However, reification has no formal
semantics, and leads to a high increase in the
number of triples, hence, it does not scale
well. "
I agree with your proposals. Prov-O mapping is
a must for CRM-SIG.
Best,
Martin
On 5/10/2023 11:55 PM, Francesco Beretta via
Crm-sig wrote:
Dear Martin, George, All,
I would not dare to suggest some solution of
this complex issue but let me hint to a
couple of useful papers (among many others):
Sikos, Leslie F., and Dean Philp,
‘Provenance-Aware Knowledge Representation: A
Survey of Data Models and Contextualized
Knowledge Graphs’, /Data Science and
Engineering/, 5.3 (2020), 293–316
<https://doi.org/10.1007/s41019-020-00118-0>
Hernández, Daniel, Aidan Hogan, and Markus
Krötzsch, ‘Reifying RDF: What Works Well With
Wikidata?’, in /Proceedings of the 11th
International Workshop on Scalable Semantic
Web Knowledge Base Systems Co-Located with
14th International Semantic Web Conference
(ISWC 2015), Bethlehem, PA, USA, October 11,
2015./, 2015, pp. 32–47
<http://ceur-ws.org/Vol-1457/SSWS2015_paper3.pdf>
Once again, I would like to suggest carefully
distinguishing between the CRM domain of
discourse, in which the E13 class is
conceptualized, and the issue of stating the
provenance of the information modelled in the
discourse domain, including instances of
class E13 as part of the modelled domain.
For this last task (or domain of discourse),
it would seems reasonable and in line with
best practices to use the PROV model and the
corresponding PROV-O ontology, a W3C
recommendation. Or providing a specific
extension of the CRM, compatible and aligned
with the PROV model. But using PROV-O seems a
good choice in order to facilitate
interoperability.
There remains the more fundamental question
of whether the current debate about RDF
implementation is not in fact indicative of a
more fundamental problem related to
properties of properties and the implicit and
richer information they contain, which cannot
be adequately expressed in RDF without
conceptualising them in terms of actual
classes. Aren't these rather hybrid
P(roperty)C(lasses), especially if they
should be declared as subclasses of E1, to be
considered as /de facto/ classes and not just
properties? Because if they are just
statements, then adopting one or the other
form of existing RDF reifications practices
seems to be the good way to go.
Best
Francesco
Le 10.05.23 à 18:48, Martin Doerr via Crm-sig
a écrit :
Dear All,
I suggest to resolve the issue of referring
to the provenance of .1 properties more
specifically:
Solution a: Add properties to E13 to specify
a .1 property. This may be more effective
than the double indirection via PC class
instance and 4 links of the E13 construct.
Solution b: Use RDF reification for this
specific problem via the PC class.
We need to examine in both cases the
inferences we want to maintain about the
base property and its domain and range, and
what the relevant query construct is.
Personally, I prefer solution c: Use the
annotation model of CRM Dig, which goes via
Named Graphs. This is much more performant
and logically clearer, because Named Graphs
are implemented as direct references to
property identifier, and maintain a
reference count for each one. This is an
important logic in its own right. Inferences
about the .properties would work in out ouf
of a Named Graph, whereas the reification
may need additional rules.
The query languages of Quad stores support
them explicitly.
The latest version of 3M supports Named
Graph definitions. This feature should be
tested.
I would rather discourage E13 in the long
term as a means to denote provenance
generally and recommend a uniform use of
Named Graphs. I am aware that not all RDF
encodings support the feature. I that case
we could resort to reification.
Opinions?
Best,
Martin
On 5/9/2023 10:37 PM, Francesco Beretta via
Crm-sig wrote:
Dear Christian-Emil, All,
For the reasons I detailed in my other
email, I totally agree with your point of
view and would like to raise all possible
caveats to this kind of mixing up quick and
dirty implementation solutions and
consistent conceptual modelling.
If we need more classes, even on a
provisional and experimental perspective, I
would strongly suggest to produce them and
document them as such, with stable URIs,
and then refine progressively the ontology
and integrate it into the CRM family. Of
course, a nice place to do this is
ontome.net <http://ontome.net> 😉
Best
Francesco
Le 08.05.23 à 17:36, Christian-Emil Smith
Ore via Crm-sig a écrit :
Also: RDF(S) is an implementation
technology. We can assume that there
exists a implmentation function from the
CRM-FOL to RDF(S), but this may not be a
1-1 function. Strange constructs like the
PC0(?) may not have counterparts in
CRM-FOL. Changing the ontology on the
bases of special tricks used in the
implementation may not always be a good
idea, but may inspire us to make well
thought out and consistent changes in the
ontology.
_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
------------------------------------
Dr. Martin Doerr
Honorary Head of the
Center for Cultural Informatics
Information Systems Laboratory
Institute of Computer Science
Foundation for Research and Technology - Hellas (FORTH)
N.Plastira 100, Vassilika Vouton,
GR70013 Heraklion,Crete,Greece
Vox:+30(2810)391625
Email:mar...@ics.forth.gr
Web-site:http://www.ics.forth.gr/isl
_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
------------------------------------
Dr. Martin Doerr
Honorary Head of the
Center for Cultural Informatics
Information Systems Laboratory
Institute of Computer Science
Foundation for Research and Technology - Hellas (FORTH)
N.Plastira 100, Vassilika Vouton,
GR70013 Heraklion,Crete,Greece
Vox:+30(2810)391625
Email:mar...@ics.forth.gr
Web-site:http://www.ics.forth.gr/isl
_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
Rob Sanderson
Senior Director for Digital Cultural Heritage
Yale University
--
------------------------------------
Dr. Martin Doerr
Honorary Head of the
Center for Cultural Informatics
Information Systems Laboratory
Institute of Computer Science
Foundation for Research and Technology - Hellas (FORTH)
N.Plastira 100, Vassilika Vouton,
GR70013 Heraklion,Crete,Greece
Vox:+30(2810)391625
Email:mar...@ics.forth.gr
Web-site:http://www.ics.forth.gr/isl
_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
