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
