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:
Referencing the value of a property for later use, like the "exv:relationshipType" value.
Using a referenced value as a property, like the value of "exv:relationshipType" used as the property of the "exv:source" value.
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)?
}]
}
RESOLVED: Defer framing #73 to future version, as new feature after the proposal window is closedView the transcript
Reframing relationships
Rob Sanderson: https://github.com/w3c/json-ld-framing/issues/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
I have the following data structure:
I would like to restructure it as:
In other words, the structure can be viewed as reifed data where:
and I need to instantiate its triple:
ex:actor-23456 -- exv:created --> ex:event-34567
Some framing issues are:
Then, I can validate some pattern while framing. The framing could be:
to produce:
Yeah, I hate it too. It looks ugly, but I currently don't see a way around it.