Subgraphs have been a core concept in the RDF semantics since version 1.0-
see e.g.

Triples accepted into one's knowledge graph are axioms (and thus must be
consistent on pain of contradiction).

RDF texts are _speech acts_, which, if asserting a proposition, may be
believed or disbelieved,  and granted different weight based on the
speaker,  the content,  and other evidentiary criteria.

Reification and named graphs are two tools for approaching this issue.  The
semantics of graph names are deliberately under-specified,  with a variety
of possible interpretations available.

On Jun 27, 2014 11:04 AM, "Murray, Ronald" <[log in to unmask]> wrote:

> Subgraphs are to graphs as subsets are to sets.
> If RDF and RDA mavens really intended to treat resource descriptions as
> graphs, they would have known that the ability to define subgraphs is a
> key element of graph theory. (In the first textbook on the topic, Dènes
> König did so nearly immediately after defining the mathematical object
> known as a graph.)
> If graph theory really was the mathematical idea that animated RDF, the
> ability to define resource description subgraphs should(!) have been
> implemented in RDF and propagated to RDA and to BIBFRAME.
> Specialized profiles of the type mentioned below can then be understood as
> subgraphs of more comprehensive (though not necessarily ever directly
> encountered) resource description graphs.
> The need for resource description subgraphs might be understood as a
> function of the "resolution" to which a resource is "viewed" by a
> describing community. Small wonder that our community has such a need -
> look at our previous implementations. No surprise that many other,
> technically influential, describing communities do not.
> Ron Murray
> On 6/26/14 5:24 PM, "J. McRee Elrod" <[log in to unmask]> wrote:
> >Karen said:
> >
> >
> >>This is an interesting vision from the cataloger perspective. If I read
> >>you correctly, in a distributed network, for the same item there could
> >>be "records" (profiles or graphs of data) that are suitable for public
> >>libraries, ones that are suitable to specialized libraries, others
> >>suitable to national libraries, or archives, etc.
> >
> >What would a vendor do who has clients in all of the categories above?
> >What does a vendor do who can afford to have only one version of data
> >per manifestation in its files for all clients?
> >
> >Our bottom line depends on the reuse of records.
> >
> >We already have this problem with phrases in different languages (if
> >one does not use the ISBD abbreviations as codes).  This would be even
> >more difficult.   Perhaps I will just have to shut up shop?  There
> >seems to be no place for such services as SLC in this brave new
> >bibliographic world.
> >
> >It has been said that only the needs of larger libraries with inhouse
> >IT ability are being served.  That may be correct.  I don't see how a
> >small library with no professional staff would be able to function in
> >such an environment.
> >
> >
> >   __       __   J. McRee (Mac) Elrod ([log in to unmask])
> >  {__  |   /     Special Libraries Cataloguing   HTTP://
> >  ___} |__ \__________________________________________________________