Hi Alexander, Vladimir,
The reason why P141 has not as range "Property" is simply because this
was not supported by any reasonable implementation at the time the model
was made. In the discussion minutes there should be explicit reference
to this decision. In the end, if you take the P2 has type
link of E13 to denote the property class the E13 assignment is about,
you have an isomorphism of E13,P140, P2, P141 with the RDF Reification
vocabulary: rdf:Statement, rdf:subject, rdf:property, rdf:object.
Further, once RDF reification existed at the time E13 was desinged, we
regarded that RDF reification would be one adequate means to describe
statements about statements.
In the meanwhile, I regard Named Graphs as superior to reification, much
cleaner. In addition, Named Graphs can preserve the complete unit of
statements made together, and that must be understood as one complex
statement. A Named Graph maps directly to E73 Information Object, so you
can attribute its creation via E65.
But statements about how statements came about are not exactly the same
as expressing modalities of certainty/uncertainty. I regard it as a
heavy overkill to deal with question marks by reification.
We must be aware of the pragmatic limitations of semantic networks. The
principle of information integration must be "recall first".
Alexander's question : "Should we include the P7_took_place_at relation
at all, given the open world assumption?" is in principle correct, but
leads to the ugly behavior, that you will get nothing back in a query.
Therefore, we should rather take all rdf statements as assumptions (a
"default questionmark"), and be happy when a query returns all POSSIBLY
correct results, rather than leaving to the user to scan manually
through billions of triples to find the link.
The question mark can still be expressed in a note to the find event.
A place like "between Mut and Balat" can be either described by the next
larger geopolitical unit, and/or , if georeferencing is used, by drawing
the respective area and giving it a new identifier, plus a note.
I have repeatedly recommended to deal with discrete uncertainty values
by supertyping all CRM properties with their uncertain counterparts:
"P7_took_place_at" is then subproperty of "P7_possibly_took_place_at".
One could formalize this with modal logic.
Alternatively, as a compatible extension, one could subtype:
"P7_took_place_at" superproperty of "P7_possibly_took_place_at".
Then a query for more precision should query "P7_took_place_at AND NOT
"P7_possibly_took_place_at".
Generally, performance of a Triple Store is not particularly degraded by
adding a hundred properties.
On ESWC2011 there was also a paper about "fuzzy RDF".
We have a whole day CRM-SIG meeting in Helsinki, Saturday June 9, before
CIDOC 2012, where we could deal with the subject, if enough participants
with mapping experience will attend.
Comments most welcome!
Best,
Martin
On 6/3/2012 11:49 πμ, Vladimir Alexiev wrote:
Hi Alexander!
So you need to attach attributes (in this case uncertainty) to a specific
property-instance (i.e. statement).
The problem is that E13/P141 lacks precision to address a specific
statement. I've noticed this in email from Oct 2011:
ISSUE: P141's range should be "Property" not "CRM Entity"
Although I came to it from a different angle: in ResearchSpace we need to
talk about (eg annotate) a specific statement.
Another use case is Attribution Qualification, which needs to be applied to
crm:P14_carried_out_by of the production of a work, e.g.:
attributed to, possibly, in the style of, studio of, circle of, school of,
after
and combinations thereof, e.g.
and studio of (meaning the named painter and his studio).
This maps to P14.1 and CRM recommends to create sub-properties, but if this
is a set of values from a thesaurus, I don't like to create fixed
subproperties.
In this "article" I propose the range of P141 to be "Property" (like the
domain of Pnn.1 is "Property")
and I outline 3 alternatives for implementing it in RDF:
http://personal.sirma.bg/vladimir/crm/art/PropertyTypesAndAnnotations.html
http://personal.sirma.bg/vladimir/crm/art/PropertyTypesAndAnnotations.pdf
We ended up using the RDF Reification vocabulary: rdf:Statement,
rdf:subject, rdf:property, rdf:object.
This has the benefit of more flexibility:
- omitting rdf:object talks about that role in general (e.g. to propose a
new creator)
- including rdf:object talks about the specific individual in that role
Following the OAC annotation ontology, we map this to BOTH oac:Target and
rdf:Statement
and connect it to the root of the work's data using dcterms:isPartOf (so we
can find all annotations about the work)
<annot> a oac:Annotation;
oac:hasBody<annot/body>;
oac:hasTarget<annot/target>.
<annot/target> a oac:Target, rdf:Statement;
dcterms:isPartOf<obj/2926>;
rdf:subject<obj/2926/part/1/production>;
rdf:property crm:P14_carried_out_by;
rdf:object rkd-artist:Rembrandt;
<annot/body> a oac:Body;
rso:P2_annotation_status rst-annotation-status:original;
dcterms:title "attribution comment";
crm:P2_has_type rkd-qlfc_attr:circle-of;
dcterms:creator rkd-person:Bredius;
dcterms:created "1935"^^xsd:gYear.
<#find-location-attribute-assignment> a crm:E13_Attribute_Assignment ;
crm:P140_assigned_attribute_to<#find> ;
crm:P141_assigned<#ankara> ;
ex:was_performed_with_surety false ;
ex:attribute_that_was_assigned crm:P7_took_place_at .
What the stuff in ex: should be, I don't know.
I'd do it this way
<#find-location-attribute-assignment> a rdf:Statement;
rdf:subject<#find> ;
rdf:property crm:P7_took_place_at;
rdf:object<#ankara> .
As for ex:was_performed_with_surety, CRM doesn't define a notion of
uncertainty, but:
- I think there was some discussion on the mlist. Search like this:
https://www.google.com/search?q=site%3Alists.ics.forth.gr+uncertainty
- I'd search for an existing ontology about uncertainty
Relatedly, we have some data that gives locations as e.g. "near Ankara"
I'd map these with a qualification attached to rdf:Statement, while still
stating the direct statement. E.g.:
<#find> crm:P7_took_place_at<#ankara>.
<#find-location-statement> a rdf:Statement
rdf:subject<#find> ;
rdf:property crm:P7_took_place_at;
rdf:object<#ankara> ;
ex:location-qualification ex-thesaurus-location-qualification:near.
and "between Mut and Balat"
Multi-valued properties are not a problem:
<#find> crm:P7_took_place_at<#Mut>,<#Balat>.
<#find-location-statement> a rdf:Statement
rdf:subject<#find> ;
rdf:property crm:P7_took_place_at;
rdf:object<#Mut>,<#Balat> ;
ex:location-qualification ex-thesaurus-location-qualification:between.
Best regards, Vladimir
_______________________________________________
Crm-sig mailing list
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
--------------------------------------------------------------
Dr. Martin Doerr | Vox:+30(2810)391625 |
Research Director | Fax:+30(2810)391638 |
| Email: [email protected] |
|
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 |
|
Web-site: http://www.ics.forth.gr/isl |
--------------------------------------------------------------
