Reframing Relationships

[AtesComp]

I have the following data structure:

{
  "@context": {
    "ex": "http://example.org/",
    "exv": "http://example.org/vocab#",
    "exv:source": {"@type": "@id"},
    "exv:target": {"@type": "@id"}
  },
  "@graph": [
  { "@id": "ex:relationship-12345",
    "@type": "exv:Relationship",
    "exv:relationshipType": {"@id": "exv:created"},
    "exv:source": {
      "@id": "ex:actor-23456",
      "@type": "exv:Actor",
      "exv:description": "Some odd actor."
    },
    "exv:target": {
      "@id": "ex:event-34567",
      "@type": "exv:Event",
      "exv:description": "Some odd event."
    }
  }]
}

I would like to restructure it as:

{
  "@context": {
    "ex": "http://example.org/",
    "exv": "http://example.org/vocab#",
    "exv:source": {"@type": "@id"},
    "exv:target": {"@type": "@id"}
  },
  "@graph": [
  { "@id": "ex:actor-23456",
    "@type": "exv:Actor",
    "exv:description": "Some odd actor.",
    "exv:created": {
      "@id": "ex:event-34567",
      "@type": "exv:Event",
      "exv:description": "Some odd event."
    }
  },
  { "@id": "ex:relationship-12345",
    "@type": "exv:Relationship",
    "exv:source": "ex:actor-23456",
    "exv:relationshipType": {"@id": "exv:created"},
    "exv:target": "ex:event-34567"
  }]
}

In other words, the structure can be viewed as reifed data where:

exv:Relationship subclass of rdf:Statement
exv:source subproperty of rdf:subject
exv:relationshipType subproperty of rdf:predicate
exv:target subproperty of rdf:object

and I need to instantiate its triple:
ex:actor-23456 -- exv:created --> ex:event-34567

Some framing issues are:

1. Referencing the value of a property for later use, like the "exv:relationshipType" value.
2. Using a referenced value as a property, like the value of "exv:relationshipType" used as the property of the "exv:source" value.
3. Matching node patterns like "ex:relationship-" + variable info
   It seems wildcard matching is an all or nothing affair: match specific IRIs, everything {}, or nothing [], but not generic string matching. It would be useful for the frame matching to use regex patterns like "ex:relationship-.+". This is helpful when I don't have @type, but can create type based on the @id match.

Then, I can validate some pattern while framing. The framing could be:

{
  "@context": {
    "ex": "http://example.org/",
    "exv": "http://example.org/vocab#",
    "exv:source": {"@type": "@id"},
    "exv:target": {"@type": "@id"}
  },
  "@graph": [
  { "@requireAll": true,
    "@id": {"@regex": "ex:relationship-.+"},      <-- verifies a proper string match for a Relationship
    "@type": {"@default": "exv:Relationship"},    <-- new type if it doesn't exist
    "exv:relationshipType": {"@id": ?prop},       <-- reference for property
    "exv:source": {
      ?prop: {"@default": {"@id": ?obj}}          <-- new key-value pair
    },
    "exv:target": {"@id": ?obj},                  <-- reference for value, will order matter (target before source)?
  }]
}

to produce:

{
  "@context": {
    "ex": "http://example.org/",
    "exv": "http://example.org/vocab#",
    "exv:source": {"@type": "@id"},
    "exv:target": {"@type": "@id"}
  },
  "@graph": [
  { "@id": "ex:relationship-12345",
    "@type": "exv:Relationship",
    "exv:relationshipType": {"@id": "exv:created"},
    "exv:source": {
      "@id": "ex:actor-23456",
      "@type": "exv:Actor",
      "exv:description": "Some odd actor.",
      "exv:created": "ex:event-34567"             <------ new key-value pair 
    },
    "exv:target": {
      "@id": "ex:event-34567",
      "@type": "exv:Event",
      "exv:description": "Some odd event."
    }
  }]
}

Yeah, I hate it too. It looks ugly, but I currently don't see a way around it.

[iherman]

This issue was discussed in a meeting.

• RESOLVED: Defer framing #73 to future version, as new feature after the proposal window is closed

View the transcript

Reframing relationships
Rob Sanderson: #73
Rob Sanderson: There’s a graph in the first example, and they want to restructure it so that the actor created has an event. But they can not do everything they want. This looks like a new feature, so we should defer this to the next version, or wontfix.
Gregg Kellogg: It begs the question: what is the purpose of framing?
… You could keep adding features to lead to a complex construct language.
… We should understand the boundaries of what framing is intended to do.
… best practices might describe how you can do more advanced things using sparql constructs.
Dave Longley: I would mark this as defer, for future discussion in a future version. We may not want to say outright that we don’t want this as a framing feature.
Rob Sanderson: We would likely say no, but agreed.
Proposed resolution: Defer framing #73 to future version, as new feature after the proposal window is closed (Rob Sanderson)
Dave Longley: +1
Rob Sanderson: +1
Ruben Taelman: +1
Gregg Kellogg: +1
Jeff Mixter: +1
Ivan Herman: +1
David I. Lehn: +1
Pierre-Antoine Champin: +1
Resolution #5: Defer framing #73 to future version, as new feature after the proposal window is closed