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
