[CONSTRAINT] RDF Resource Constraints

[Vladimir Alexiev]

In the ResearchSpace project (http://www.researchspace.org) we represent art research facts and suppositions using the CIDOC CRM ontology. Eg this simple chain of properties says that "Badende Susanna" is a painting that has a main part (painting) that was created in a Production event that was carried out by Rembrandt.

We need to annotate RDF statements or partial statements. For example:

• To record that Bredius (1935) said that Rembrandt was the painter, we need an Annotation that targets URIs 3,4,5 (i.e. a complete rdf:Statement)
• To dispute that claim, we again need an Annotation to target URIs 3,4,5 (complete rdf:Statement) plus some extra "disposition" to express disagreement
  
• To propose an extra painter, we need an Annotation to target URIs 3,4 (partial rdf:Statement) and propose a new object

The target can be neither 3 (that node has multiple business properties), nor 5 (that node is shared by many top-level subjects, and even by several properties of the same subject). See http://personal.sirma.bg/vladimir/crm/art/PropertyTypesAndAnnotations.html for details.

Because of the need for partial statements (5 can be present or not), our current design is to use the RDF Reification vocabulary instead of Named Graphs.

Therefore I'd like to propose a new section for http://www.openannotation.org/spec/beta/constraints.html:

RDF Resource Constraints

RDF Resource Constraints are used to point to RDF statements. They match the framework of Data Model Guide section 3.7.3.2 and are attached to the Constraint (node C-1 on Figure 7.3.2). They reuse the RDF Reification vocabulary.

Ontology

Classes Defined Elsewhere: 

rdf:Statement 

Signifies that the constraint is about an RDF statement. The statement conceptually "belongs" to the target T-1 (the object of oac:constrains).

Relationships Defined Elsewhere: 

rdf:subject

Subject of the statement being annotated, required. May coincide with the target T-1.

rdf:predicate

Property being annotated, required.

rdf:object

Object of the statement being annotated, optional. If missing, the annotation is about all statements with the given subject and predicate, and none of them in particular.

[Robert Sanderson]

Have you looked at section 3.9 about structured bodies?
    http://www.openannotation.org/spec/beta/#DM_Structured

Does this not solve your problem? You can make all the statements you want in the body, about the different targets and their segments.

Rob

[Vladimir Alexiev]

I have looked at it, but IMHO that way has two problems:

• It doesn't standardize the properties of Body. I think that annotating an RDF property-instance is a common use case that should be standardized (that's the intention of my proposal). 
• It mandates that the Body URI should be resolvable. This is a good practice for linked data, but not always implementable (eg while you're working on a test server). The spec doesn't mandate resolvability of Annotation and Target URIs, so it shouldn't do so for Body

Annotating an RDF property-instance maps cleanly to Constraint, since the annotation is about part of the Target data.
As in Principle 7: "Many Annotations involve parts of resources"

[Robert Sanderson]

On Wed, Feb 8, 2012 at 1:16 AM, Vladimir Alexiev <vlad...@sirma.bg> wrote:

> It doesn't standardize the properties of Body. I think that annotating an
> RDF property-instance is a common use case that should be standardized
> (that's the intention of my proposal).

> Annotating an RDF property-instance maps cleanly to Constraint, since the
> annotation is about part of the Target data.
> As in Principle 7: "Many Annotations involve parts of resources"

Sorry, I think I misunderstood your question!

Do you have an existing document in RDF, and you want to select
triples from it to form either the Body or the Target of an
Annotation? And thus you need a Constraint to select which triples?
Perhaps a SparqlConstraint?

If so, it would be great to discuss this further -- if you could write
up a description of the use case and the constraint that would solve
it would be perfect.

> It mandates that the Body URI should be resolvable. This is a good practice
> for linked data, but not always implementable (eg while you're working on a
> test server). The spec doesn't mandate resolvability of Annotation and
> Target URIs, so it shouldn't do so for Body

Can you point to me where the spec says that a Body must be
resolvable, because that's a typo!
As a case in point, the spec explicitly allows embedding the body
within the Annotation document.

In Figure 9, it shows the retrieval of a resolvable body, but then in
Figure 9.1 please note that this doesn't occur -- the data is embedded
within the Annotation directly. So a resolvable body is possible, but
certainly not mandatory!

Hope that helps,

Rob

[Vladimir Alexiev]

Hi Rob!

Do you have an existing document in RDF?  And thus you need a Constraint to select which triples?

I have some triples, and I want to annotate a particular triple. 
More precisely, a particular property-instance (who painted "Badende Susana"), with or without the object (Rembrandt).

 

Perhaps a SparqlConstraint?

Since I need to address a particular property-instance, it'd be easier to use rdf:subject and rdf:property

BTW, where is SparqlConstraint described? I can't find it in http://www.openannotation.org/spec/beta/constraints.html. I doubt that'd work for my case, since I'm not sure I can address the original graph with sparql (SELECT returns a flat resultset, and CONSTRUCT makes a new graph)

 

write up a description of the use case and the constraint that would solve

I have a description of the case in the first email of this thread, but maybe its not sufficient?

 

Can you point to me where the spec says that a Body must be resolvable, because that's a typo! In Figure 9, it shows the retrieval of a resolvable body, but then in Figure 9.1 please note that this doesn't occur -- the data is embedded

Sorry, "mandates" is a wrong word, I meant that Fig 9 shows a HTTP GET. 
In my case I need "embedded" but don't want "encoded" as Fig 9.1 shows (and we have this whole separate discussion about "encoded"). 
So my proposal is to standardize one particular case of pointing "inside" an RDF resource, and I think ConstrainedTarget is a good way for that.