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

We faced this issue of course when we cached these things - which versions
should we cache?  When should we revisit them?    Should we modify them?

We face similar issues on a different schedule with our data, as well.
When do we fetch NAICS codes?  Do we cache them?  Do we modify them?  NAICS
has a set schedule of publication, but other things (geonames?) don't.

One of the nice things about RDF is that it is easy to extend one of these
things without modifying it, which standards like SKOS encourage.  This
mediates the problem in many settings.  But what if we actually want to
change something?  Should we be allowed?  Technically, it is possible,
after all, we now have that file behind our firewall.

My felling is that we should not - what does it mean to call something a
NAICS code, if you change some of them?   That holds even more so for
things like SKOS and PROV.



Dean





On Fri, Dec 5, 2014 at 5:38 AM, Arthur Ryman <ryman@ca.ibm.com> wrote:

> +1 to Dean's Bank scenario.
>
> In Rational we make IDEs (many are based on Eclipse, which is what
> TopBraid Composer uses) and many of our customers use the IDEs in locked
> down environment where external network access is restricted. We first hit
> this problem with XML schema and XML documents being validated. We had to
> provide a mechanism (aka the catalog) for shipping local copies with the
> IDE. The same probably will occur with vocabularies, shapes, etc. However,
> this is really just a form of caching.
>
> That being said, the question remains, Where did the cached copy come
> from? and Did you modify it? If you are using your IDE because you want to
> develop an app that is going to be deployed into some environment that is
> going to enforce some standards (e.g. JEE), then clearly you want your
> local copies to come from the authoritative source for those standards,
> and you better not modify them, otherwise your app may fail when you
> deploy it.
>
> So whether or not you cache something, the key question is: Do you require
> interoperability of the artifacts you are developing with some other
> system? I don't believe that semantic technology is significantly
> different from HTML, CS, JS, JEE, XML, etc. in this respect.
> _________________________________________________________
> Arthur Ryman
> Chief Data Officer
> SWG | Rational
> 905.413.3077 (phone) | 416.939.5063 (cell)
> IBM InterConnect 2015
>
>
>
>
> From:   Dean Allemang <dallemang@workingontologist.com>
> To:     Holger Knublauch <holger@topquadrant.com>
> Cc:     "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
> Date:   11/26/2014 08:43 PM
> Subject:        Re: interoperability (was Re: isolating shapes in named
> graphs)
> Sent by:        deanallemang@gmail.com
>
>
>
> 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
>
>
>
>
>
>