* Peter F. Patel-Schneider <pfpschneider@gmail.com> [2014-11-25 16:20-0800]
> On 11/25/2014 02:14 PM, Eric Prud'hommeaux wrote:
> >* Holger Knublauch <holger@topquadrant.com> [2014-11-19 22:36+1000]
> >
> >> For the majority of use cases
> >>you would end up with Shape objects that are mirroring classes,
> >
> >I disagree that the majority of shapes would be global invariants.
> >But regardless, the fact that we don't want to write off the other use
> >cases implies that we must not require a model which forces one to
> >retract one schema when looking at another when both should be associated
> >with particular interfaces.
>
> What does "global invariant" mean here?
>
> There is no way that constraints can be truly global, i.e., that
> every use of RDF has to include them all. I don't see anyone
> arguing that the mere use of a class requires the use of all
> constraints associated with that class, which perhaps could be
> considered to be akin to a global invariant. All other setups for
> constraints appear to be situational, i.e., not global.
Three messages "up" in this thread, I was arguing just that. See
<http://www.w3.org/mid/20141119111430.GB24640@w3.org> (attached).
I agree re "situational". As a counter example, the FOAF ontology
*could* say that foaf:mbox had a cardinality of one, but that would
needlessly restrict its usage. (At TPAC, Tantek beat me up about
having cardinalities attached to vocabulary definitions. After a sound
drubbing, I managed to explain that he was beating up the wrong guy.)
> peter
--
-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.
Forwarded message 1
* 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.