isolating shapes in named graphs

* Holger Knublauch <holger@topquadrant.com> [2014-11-19 09:19+1000]
> On 11/19/2014 9:12, Eric Prud'hommeaux wrote:
> >* Holger Knublauch <holger@topquadrant.com> [2014-11-06 09:42+1000]
> >>Hi Arthur,
> >>
> >>I am looking forward to seeing this worked out as a specific
> >>example. Currently I don't see why named graphs would not cover your
> >>use cases.
> >I suspect that by "named graphs" you mean using named graphs as a way
> >to perform course-grained instantiation and revocation. In Arthur's
> >example, this would mean when dealing with project A, load a named
> >graph that provides some constraints for an object. When dealing with
> >project B, throw away that first named graph and load another with
> >constraints for the same object. How does one deal with both at the
> >same time?
> 
> To deal with both contexts, just keep the named graphs separate at
> execution time. In Arthurs example, project A calls the
> CreationFactory servlet with one context, while project B calls it
> with another context. The CreationFactory assembles the graph that
> it needs *for this transaction* while the other transaction uses a
> different configuration of graphs by creating different union graphs
> and import closures. Why should they merge both graphs together?
> Transaction A would not even know anything about Transaction B.
> These are controlled environments, not "The (global) Semantic Web".

This is a critical architectural issue. If we weave mutually
inconsistent data into the shapes architecture, we over-constrain its
use in ways that will have long-term consequences. We could do the
same with e.g. FOAF where everyone uses the same Person URL:

GRAPH <HolgersGraph> {
 <http://example.org/ThePerson> foaf:name "Holger" ;
   foaf:mbox mailto:holger@topquadrant.com .
}
GRAPH <EricsGraph> {
 <http://example.org/ThePerson> foaf:name "Eric" ;
   foaf:mbox mailto:eric@w3.org .
}

I can work with that, but it's a pain and I won't e.g. be able to
combine FOAF profiles in an aggregator, use OWL inferencing over the
union, do a "CONSTRUCT WHERE { TriplesTemplate? }" query, etc.

This is the sort of problem that modelers studiously avoid by not
eliminating functional properties. For example, in a database, tuples
would include the interface or whatever was required to describe where
the shape applied.


> Holger
> 
> 
> 
> >
> >
> >
> >>This topic is crucial to discuss exhaustively because it sits at the
> >>very foundation of the differences between ShEx/Resource Shapes and
> >>OWL/SPIN.
> >>
> >>Holger
> >>
> >>
> >>On 11/6/2014 7:47, Arthur Ryman wrote:
> >>>There are a few motivations for decoupling shapes and classes. One is that
> >>>the creation shape may be different than the update shape. Another has to
> >>>do with custom properties. I'll write up the following in the wiki.
> >>>
> >>>OSLC supports an open content model for resources. It is common for tools
> >>>to add their own custom properties, and for projects within a tool to have
> >>>different user-defined properties. For example, consider a bug tracking
> >>>tool. Project A may add a custom property foo and project B may add bar.
> >>>All projects use the same RDF type for bug resources, e.g.
> >>>oslc_cm:ChangeRequest. However, the shape for resources in project A
> >>>differs for the shape for project B.
> >>>_________________________________________________________
> >>>Arthur Ryman
> >>>Chief Data Officer
> >>>SWG | Rational
> >>>905.413.3077 (phone) | 416.939.5063 (cell)
> >>>IBM InterConnect 2015
> >>>
> >>>
> >>
> 
> 

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Wednesday, 19 November 2014 11:14:37 UTC