[Crm-sig] Uncertainty in the location at which an activity took place

martin martin at ics.forth.gr
Thu Mar 8 13:19:34 EET 2012


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
> Crm-sig at ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>


-- 

--------------------------------------------------------------
  Dr. Martin Doerr              |  Vox:+30(2810)391625        |
  Research Director             |  Fax:+30(2810)391638        |
                                |  Email: martin at ics.forth.gr |
                                                              |
                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           |
--------------------------------------------------------------



More information about the Crm-sig mailing list