Use of RDF: what a client can expect concerning http resources, RDF resources, RDF graphs, and triples

[ndjc]

In current OSLC resource shapes, we define oslc:representation and oslc:valueType to describe how RDF resources might map to http resources - how in some cases we require a server to return more than one RDF resources in a single http response.

However, there's a bigger aspect to this topic. One oft-quoted feature of RDF is anyone can see anything about anything - to quote from Resource Description Framework (RDF): Concepts and Abstract Data Model:

2.2.6 Anyone can say anything about anything

To facilitate operation at Internet scale, RDF is an open-world framework that allows anyone to say anything about anything. In general, it is not assumed that all information about any topic is available. A consequence of this is that RDF cannot prevent anyone from making nonsensical or inconsistent assertions, and applications that build upon RDF must find ways to deal with conflicting sources of information. (This is where RDF departs from the XML approach to data representation, which is generally quite prescriptive and aims to present an application with information that is well-formed and complete for the application's needs.)

In particular, RDF does not guarantee that all the triples with a given subject are in any way correlated in terms of their graphs or http resources in they may have been read.

Nonetheless, to have any value to the oslc:representation and oslc:valueType properties, we should consider guidelines and/or best practices for OSLC. OSLC Configuration Management already places some requirements on graphs and resources for versioned artifacts.

[ndjc]

This topic came up as a comment or suggestion about the term oslc:impactType in the Core 3.0 vocabulary. @DavidJHoney commented that there seemed to be no requirement about where triples assessing this property should reside, and that there should be such a requirement, otherwise clients could not determine if an impact type existed or not.

Nick investigated the use of oslc:impactType, and found:

• The property was defined for, and only intended for use in, OSLC vocabularies. It should be applied to a term that defines an rdf:property in that vocabulary, where that property is used for a link, and the vocabulary wants to define the impact (dependency) established by a link of that type. No meaning is assigned to the use of oslc:linkType in other contexts, such as shapes or artifact instances. The existing Core 3.0 drafts are consistent with this.
• The property is rarely used. It is used in only one place in all of IBM's ELM product suite (for link validity statements, where it asserts that link validity statements do not themselves establish any dependencies.
• OSLC specifications do not say much about the structures of vocabularies themselves. We have our own conventions, but those are not described in the specs themselves. We recommend use of # URIs for terms, meaning that a GET on the URI of a vocabulary is likely to fetch all terms defined in that vocabulary (and this resolves the very specific issue raised by @DavidJHoney about oslc:impactType, though not the larger topic about finding properties of a resource(. Other standards, such as Dublin Core, use / URIs, where a separate GET may be required for each term.

[jamsden]

Nick, I don't think AAA applies to graphs - it applies to arbitrary assertions that a consumer might encounter. These could in multiple graphs, in the default graph, or no graph at all in the case of a triple store (vs. quad store).

But I think the guidance you are suggesting is appropriate for OSLC resources - which are represented as a specific set of assertions intended to represent something. In the case where those OSLC resources are represented by a graph, then this is also relevant.