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 😉
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
