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
<[email protected]> 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
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
_______________________________________________
Crm-sig mailing list
[email protected]
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:[email protected]
Web-site:http://www.ics.forth.gr/isl
_______________________________________________
Crm-sig mailing list
[email protected]
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:[email protected]
Web-site:http://www.ics.forth.gr/isl
_______________________________________________
Crm-sig mailing list
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
