Profile part 1

Author: Dexagod

spec.bs

@@ -14,129 +14,139 @@ Markup Shorthands: markdown yes, css no
 
 <!-- Abstract: The RDF Context Association specification provides instructions for clients to interpret associations of contextual data to a closed set of target statements in RDF. It defines how closed sets of statements can be modeled in RDF as Named Graphs with Blank Node name identifiers (Blank Node Graphs) and the modeling of sets of Blank Node Graphs that can be interpreted as a single closed set of quad statements. -->
 
+<!-- useful sources? -->
+<!-- [Semantics of RDF Datasets](https://www.w3.org/TR/rdf11-datasets/) -->
+<!-- [Blank Node Relabeling](https://www.w3.org/TR/rdf11-mt/#shared-blank-nodes-unions-and-merges) -->
+<!-- [Skolemization](https://www.w3.org/TR/rdf11-mt/#skolemization-informative) -->
+
+
+
 Introduction {#intro}
 =====================
 
 Issue: define namespace `ca` as `https://w3id.org/contextassociations#`, 
 
-Issue: discuss naming over the whole document!
+Issue: discuss the used names over the whole document!
 
+`RDF Context Associations` are a modeling approach associations of information to a closed set of 
+RDF statements that remain unambiguous under storage, merging and processing operations in the RDF stack.
+As current specifications for policies, provenance and signatures in RDF do not define specific
+semantics requirements for their targets except for defining the target as a URI,
+the processing of the associated set of statements to this contextual information in the RDF stack
+is left up to interpretation.
 
-`RDF Context Associations` is a modeling approach to define relations to a set or a collection of sets of RDF statements 
-that remains unambiguous under storage, merging and processing operations in the RDF stack.
-As many specification for policies, provenance and signature do not provide specific semantics in RDF
-in how to process their associated sets of statements, as these are abstracted as a URI, 
-they do not provide a stable basis for building Semantic Web stacks that incorporate the contextual
-information that is present throughout networks.
+The goal of this specification is to provide a modeling approach that enables the definition of 
+a closed set of statements (or collection of sets of statements) in RDF that when targeted by contextual
+information remains unambiguous when processed throughout the network in which they are exchanged
+and the RDF stack in which they are processed.
 
-This specification aims to define a modeling approach that follows a set of rules that enables the 
-modeling of associations of contextual information with unambiguous sets of target statements that
-remains unambiguous throughout the network  when exchanging, storing and processing the data. 
+This raises the following set of requirements that have to be fulfilled:
+(i) the unambiguity of the referenced set of statements, 
+(ii) the ability to unambiguously reference the union of multiple such sets of statements, 
+(iii) the interpretation of the target should not influence the contextual information model,
+(iv) the data model used for the associations should remain compatible with the core RDF specification
+and (v) that any set of RDF quads can be converted to a valid target for such a context association.
 
-The requirements for a succesful model are 
-(i) the unambiguity of a referenced set of statements, 
-(ii) the referencing of mutliple distinct sets of statements as a union, 
-(iii) the restriction the modeling approach to RDF 1.1 and 
-(iv) the ability to model contextual information over any set of existing RDF 1.1 data including quads.
+Issue: rephrase this baseuri presentation
 
 The base URI for RDF Context Association is https://w3id.org/ca#, and the preferred prefix is `ca`:. Other prefixes are used following [prefix.cc](prefix.cc).
 
+
+
+
 Blank Node Graphs {#blank_node_graphs}
 ======================================
 
-The basis of the Context Association model in RDF is the
-use of Named Graphs to define sets of statements that
-can be targeted. 
-However, to make the interpretation of these context associations
-consistent and unambiguous throughout the network, both the semantic
-interpretation and syntactic expression of these Named Graphs need to 
-be defined.
+Issue: We have a choice here to either provide specific predicates / types to indicate a required interpretation OR an RDF profile.
+The choice for using a profile is much more interesting in terms of reusability, as agreeing on graph interpretation is a broader issue to solve.
+Additionally, the use of predicates and classes has 2 problems: 
+1. if the identifying type is not present, interpretation changes, which should not be possible under RDF
+2. if the type is present but no graph uses that identifier, we have an inconsistency.
+Hence the choice we make will be for a profile.
+
+The main requirement for the target approach to model context associations in RDF is 
+the ability to define contextual information over a closed set of targe statements that
+remain unambiguous under storage, exchange and processing throughout the network.
+The RDF core specification provides three approaches to modeling statements about statements
+in the use of reification, named graphs and triple terms.
+As named graphs is the only modeling approach that can target sets of statements, 
+we use this as the baseline for the modeling approach to define context associations.
+
+The use of Named Graphs in RDF requires the addition of concrete rules for definition
+and interpretation of the context association model, that are enforced through the use 
+of the following RDF profile: 
+```
+    <Content-Type>;profile=https://w3id.org/ca/graph_occurence
+```
+
+## Enforcing semantic interpretation of named graphs
 
-## Semantic interpretation of Named Graphs
 <!-- we need to enforce a specific interpretation -->
-Where the DF 1.1 specification does not define a concrete 
-semantic interpretation of Named Graphs, the modeling of 
-Context Associations requires that: 
-(i) the name identifier of a Named Graph in the target of 
-a context association MUST serve as the reference for its
-associated RDF Graph in the Named Graph pair.
 
-This MUST be expressed explicitly by defining the the RDF type
-`ca:GraphIdentifier` on the target graph name identifier.
+To define context associations using named graphs in RDF,
+the following interpretation is be enforced within the profile:
+```
+Te Named Graph identifies a pair of a name identifier and a graph term where:
+(i) the name identifier MUST be interpreted as the referent for the associated graph term and
+(ii) the graph term MUST be interpreted as the occurrence of that graph term denoted by the name identifier. 
+```
+Concretely, this defines that all references to the name identifier of a Named Graph
+MUST be interpreted as referencing the associated Graph term and its contained set of triple statements.
+Additionally, the semantic inferences of the contents of the associated Graph Term are contained to the graph boundary.
+
+Issue: define this for all inferences EXCEPT basic inference (e.g. blank node co-referencing)
+
+Issue: can we align this anywhere? The RDF 1.2 SPARQL entailment and semantics and ... specs are not yet done.
+
+Issue:  OOOOR we define only the reference part BUT NOT the interpretation of the graph semantics part?
+Unsure what the downsides are of leaving the interpretation of the graph up to the implementer, 
+and in essence it might not be the requirement of the context association to define the interpretation of the trust value of the contained triples?
 
-Issue: Is this a MAY or a MUST? Do things break if this is not explicitly specified?
 
 <figure id="my-code" class="listing">
-```turtle
-@prefix ca: <https://w3id.org/contextassociations#>;
+```
+> Content-Type: text/trig;profile=https://w3id.org/ca/graph_occurence
+
+@prefix : <http://example.org/ns>;
+_:signature :target _:graphName;
 _:graphName { :a :b :c . }
-_:graphName a ca:GraphIdentifier .
 ```
 <figcaption markdown="block">
-Defining a Named Graph name value as a Graph Identifier, 
-indicating that all references to that identifier reference
-the set of triples contained in the associated graph.
+The profile interpretation enforces the Signature target to 
+be exactly the set of quads for which the graph term equals `_:graphName`,
+which in this case is `:a :b :c _:graphName`.
 </figcaption>
 </figure>
 
-The definition of the class `ca:GraphIdentifier` on an identifier
-that is NOT used as a graph name SHOULD be considered as an inconsistency.
-
-<!-- [Semantics of RDF Datasets](https://www.w3.org/TR/rdf11-datasets/) -->
-<!-- [Blank Node Relabeling](https://www.w3.org/TR/rdf11-mt/#shared-blank-nodes-unions-and-merges) -->
-<!-- [Skolemization](https://www.w3.org/TR/rdf11-mt/#skolemization-informative) -->
-
-Issue: Should it?
-
-With regards to the semantic interpretation of the trust value of 
-the triple statements contained by the RDF Graph of a Named Graph,
-we make no claim as to how these should be enforced. 
-A sensible default however is to NOT evaluate the Graph contents
-of a referenced Named Graph before the associated contextual 
-information has been evaluated, as these might help strategize the
-interpretation of the referenced graph content.
-
 
-Issue: Either we do the above and say nothing explicitly, as nothing
-is specced, otherwise we would need an RDF profile to indicate interpretation.\
-Such a profile might be able to alleviate other things such as the explicit GraphIdentifier class however.
+## Preventing ambiguity using Blank Nodes identifiers
 
-<!-- 
-To alert consumers of this interpretation, a context association 
-targeting a set of statements defined in a graph `A`
-MUST define this graph with the `rdf:type` of `ca:GraphIdentifier`. 
-Any relation that references an identifier with associated type 
-`ca:GraphIdentifier` MUST be interpreted as a referencing the 
-associated RDF Graph defined by the Named Graph corresponding
-to that identifier. -->
+Issue: is blank nodes a SHOULD or a MUST (even if you can guarantee uniqueness of the graph name URIs?)
 
+In addition to semantic interpretation, the syntactic expression of context associations
+using named graphs must also remain unambiguous throughout its use in the network.
+The RDF specification defines that merging different sources of RDF data requires 
+their named graphs to be combined using the `merge` or `union` operation on their contained graphs.
+Because of this, named graphs sharing the same name identifiers in different sources 
+are combined into a single named graph when combining RDF from different sources.
+To prevent this behavior invalidating context associations when merging data,
+the use of blank nodes as name identifiers for named graphs is advised when uniqueness of graph names cannot be guaranteed.
 
-## Preventing ambiguity using Blank Node Graphs
+Defining the target set of triple statements of a context association in RDF SHOULD 
+make use of a blank node as the name identifier of the named graph that contains the 
+target set of triple statements. 
+If cases where the target set of statements needs to be referenced by external sources,
+the use of [Skolemized identifiers](https://www.w3.org/TR/rdf11-mt/#skolemization-informative)
+guarantees tge unique generation of name identifiers, while remaining referenceable outside the local RDF scope.
 
-<!-- 2. we need to enforce unambiguity - by restricting to the local scope to achieve graph closure -->
-Merging RDF data from different sources that include Named Graphs, 
-the RDF specification defines that graphs sharing an identical name value
-must be merged using the `merge` or `union` operation of their RDF Graphs.
-To prevent unwanted merging of context associations when merging data,
-a guarantee is required that the graph name values will never clash.
 
-<!-- open world assumption? -> [Found this link](https://www.w3.org/TR/rdf-mt/#:~:text=RDF%20is%20an%20assertional%20logic%2C%20in%20which%20each%20triple%20expresses%20a%20simple%20proposition.%20This%20imposes%20a%20fairly%20strict%20monotonic%20discipline%20on%20the%20language%2C%20so%20that%20it%20cannot%20express%20closed%2Dworld%20assumptions%2C%20local%20default%20preferences%2C%20and%20several%20other%20commonly%20used%20non%2Dmonotonic%20constructs.) -->
 
-Issue: is blank nodes a SHOULD or a MUST (if you can guarantee URI uniqueness?)
+Multiple Graph Associations {#multiple_graphs}
+==============================================
 
-The use of Blank Node identifiers for the name value of any Named Graphs
-prevents the occurrence of multiple Named Graphs with the same name value.
-As Blank Node identifiers MUST be relabeled when merging RDF from different sources, 
-this guarantees the uniqueness of the name identifiers.
-If extenral referencability of the Named Graphs is required, 
-the use of [Skolemized identifiers](https://www.w3.org/TR/rdf11-mt/#skolemization-informative)
-guarantees uniqueness in the generation of the name identifier, 
-while retaining referencability outside the local scope.
 
-Issue: Do we test for the precense of named node identifiers as graph identifiers? 
+// Todo:: continue read through from here
 
-Multiple Graph Associations {#multiple_graphs}
-==============================================
 
 Issue: Should the includes be a list for ensuring closure? 
 E.g. if we lose a targets link, the list breaks and we can see the policy is incomplete?
@@ -180,11 +190,15 @@ Issue: testing compliance - how?
 Including Source Quads {#quads}
 ===============================
 
-Issue: Make sure to make explicit in the example that "LOCAL KNOWLEDGE of what the graph means (origin) is made explicit as provenance"
-
-Issue: Make sure to make explicit that the choice of which graph name identifiers should be relabeled is undecidable and should be taken case by case.
-
-Issue: Show that based on the above 2 choices, roundtripping can be done based on the knowledge of the above 2 parameters
+Issue: We need to make sure we are clear in the communication here: 
+the use of context associations is to help EXPLICITIZE implicit assumptions stored in a graph name identifier. 
+So (i) we need to make sure to indicate how to convert explicit "LOCAL KNOWLEDGE of what the graph means 
+(e.g. origin) can be made explicit as provenance"
+Additionally (ii) we need to convey that the choice of how graph name identifiers 
+should be relabeled inside the triple statements is undecidable and should be taken case by case.
+(e.g. if the graph name is meant as a graph reference, it should be relabeled to a blank node. 
+If it indicates something specific such as source, existing references to that source URI should be kept as is.)
+(ii) Show that based on the above 2 choices, roundtripping can be done based on the knowledge of the above 2 parameters? Maybe?
 
 Including source data when defining contextual information, 
 the named graphs in the source data will need to be processed