Re: interoperability (was Re: isolating shapes in named graphs)

To take this one step further - in a high-security situation (like a bank),
this sort of architecture isn't "nice" or "optional" it is mandatory.  The
Bank is not willing to fetch e.g. skos.rdf from the W3C website and load
that in to our production (or even dev, for that matter) server.  What
happens if the W3C site was hacked?  Or there was a man-in-the-middle?  Now
we have arbitrary malicious stuff in the models in the production system.

No, my Managing Director absolutely insists that we have our own copies of
SKOS, PROV, and even RDFS and OWL inside our own firewall.



On Thu, Nov 27, 2014 at 11:49 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

> On 11/27/2014 10:32, Peter F. Patel-Schneider wrote:
>
>> I think that the relevance of this part of the thread is whether
>> associating constraints/shapes with ontologies commits one to using those
>> shapes.  The argument against committing appears to be that one would then
>> lose interoperability.
>>
>
> What we do in TopBraid is that people can have local copies of remote
> files in their local "workspace". If an owl:import is found, it first looks
> if a local copy of that graph URI exists. That local copy may have
> different definitions, drop constraints or whatever, if the particular
> application wants to do that. I believe this is straight-forward
> architecture that other systems use too. Yet, there is value in publishing
> the original constraints in the master copy of an ontology, on the network.
> Specifications such as SKOS, PROV and other user stories in our list would
> arguably have done that if there had been a standard.
>
> Holger
>
>
>