- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Wed, 8 Feb 2017 21:24:20 -0800
- To: Kerry Taylor <kerry.taylor@anu.edu.au>, "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, Armin Haller <armin.haller@anu.edu.au>, "maxime.lefrancois@emse.fr" <maxime.lefrancois@emse.fr>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
- Message-ID: <630ce14a-96dc-e81b-78ef-765a3c04f8be@ucsb.edu>
> *(8) *texttt{sosa:sensor}: *Such a corner use case in an academic
> presentation? (and not an argument I have ever met before!)
> Irrelevant in most cases because the term means the same thing
> whichever ontology URI you find it in, by design.*
Corner use case, irrelevant? I read papers every single day that do that
and some of them are authored by you. [Also, why use offensive terms
such as irrelevant when discussing positions and concerns?]
On 02/08/2017 09:14 PM, Kerry Taylor wrote:
>
> *Responding to Simon’s question:*
>
> >What exactly is the objection to two namespace URIs? We wouldn’t be the
> first to go this direction for a core and extensions: Dublin Core,
> SKOS both have them, and it is a standard tool for both re-use and
> modularization. Is it essentially around branding?
>
> *Not necessarily in any order:*
>
> *(0): Are you sure about SKOS having multiple namespaces? – I don’t
> think so http://www.w3.org/2004/02/skos/core#*
>
> *(1): Well DC is not exactly a practice we would like to follow. –
> the multiple namespaces are shockingly confusing (my view).*
>
> *(2) PROV, otoh would have greatly benefited from some modularity in
> practice that supported the modularity it claims in documentation.
> We can do better.*
>
> *(3) We have the opportunity here to get “modularisation” right – I
> think it was Josh that expressed his hope to have it as the most
> important outcome of the group!*
>
> *(4) We know a scalable way to have as many separate ontology
> modules/graphs/files interacting as we wish --- great design for
> “modularity”. By using the term-at-a time rewrites to map each term
> to the ontology module that introduces it in its most simple form.
> We can direct the term resolving to the “easiest” place.*
>
> *(5) By this method sosa users will get **exactly the behaviour the
> practitioners are used to.** You can get the sosa ontology from a sosa
> uri. You can resolve any sosa term in the namespace in the usual way –
> and get straight back to the sosa ontology (or the namespace doc , as
> convention dictates).*
>
> *(6) Only more sophisticated ssn users would see any difference to the
> norm. If you are looking at the ssn ontology and you resolve a term
> that is not in sosa then you get the ssn full ontology – standard
> expected behaviour, surely! But if you resolve a term that is first
> introduced in sosa you get the sosa core –this is the only case that
> might be surprising – but it is a case for those who know what they
> are doing and looking for.*
>
> *(7) Branding? Not an issue as far as I know. “ *i.e., a clear
> signal that SOSA is usable on its own. “ . *Conflating matters. A
> “clear signal that sosa is usable on its own” is much more clearly
> sent in other ways *
>
> *(8) *texttt{sosa:sensor}: *Such a corner use case in an academic
> presentation? (and not an argument I have ever met before!)
> Irrelevant in most cases because the term means the same thing
> whichever ontology URI you find it in, by design.*
>
> -Kerry
>
> *From:*Krzysztof Janowicz [mailto:janowicz@ucsb.edu]
> *Sent:* Thursday, 9 February 2017 2:49 PM
> *To:* Simon.Cox@csiro.au; Armin Haller <armin.haller@anu.edu.au>;
> maxime.lefrancois@emse.fr; Kerry Taylor <kerry.taylor@anu.edu.au>;
> public-sdw-wg@w3.org
> *Subject:* Re: Different or same Namespace for SOSA/SSN
>
> Thanks Simon, I fully support and agree with everything what you said.
>
> Let me just add two more aspects.
>
> One is the branding, i.e., a clear signal that SOSA is usable on its own.
>
> Secondly, and more importantly, what about academic papers,
> documentations, slides, source code fragments, and so forth. Clearly,
> if I have a code snippet, slides, or a text fragment in a paper (such
> as "Lorem ipsum dolor sit amet, consectetur adipiscing elit
> \texttt{sosa:sensor} Duis sed sollicitudin metus, eu vulputate
> magna.") then two namespaces are easier to use while a one namespace
> solution suddenly becomes a problem if I would like to immediately
> know which of the two ontologies are being used.
>
> Best,
> Jano
>
>
>
> On 02/08/2017 04:52 PM, Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>
> wrote:
>
> On ISSUE-80 and
> https://www.w3.org/2015/spatial/wiki/index.php?title=NamespaceIssue
>
> I can see that the http knitting described by Maxime is a very
> clever technical solution which might allow use of a single
> namespace.
>
> But I am very concerned that it deviates significantly from
> conventional expectations.
>
> The goals of the SDW working group are primarily to make spatial
> data more visible on the web.
>
> In my opinion we should be very cautious about using techniques
> which, while technically and theoretically defensible, would
> surprise time-strapped/lazy web developers and users, and lead
> them to just go somewhere else.
>
> SSN has had enormous impact in the research community, is cited in
> a lot of journal papers, but very little outside that milieu.
>
> SOSA is carefully pitched at a broader community, which we
> generally characterize as the ‘schema.org’ community.
>
> It includes a limited subset of the classes and properties that
> are required for the whole story, but is still consistent with (a
> slightly revised version of) SSN, with the expectation that it can
> therefore serve as its core.
>
> We anticipate use by people who don’t know or care about semantics
> and entailments and property-chain axioms and the like, but would
> be happy to tag data using URIs from a coherent set with a
> coherent identity.
>
> The theory says that namespace != file != ontology != graph
>
> But the practice and common usage and expectations don’t follow
> the theory, and frankly it is folly to imagine the world is going
> to change to suit our refined needs.
>
> We know for starters that a separate URI is needed for each graph,
> and in practice these are expected to also correspond with an
> ontology URI and then for practical reasons to the namespace for
> individual items originally defined within the ontology.
>
> I really don’t think a single namespace URI for two different
> products passes the Pareto principle, even if one builds on the
> other.
>
> And certainly not the laugh-test.
>
> What exactly is the objection to two namespace URIs? We wouldn’t
> be the first to go this direction for a core and extensions:
> Dublin Core, SKOS both have them, and it is a standard tool for
> both re-use and modularization. Is it essentially around branding?
>
> Simon
>
> *From:*Armin Haller [mailto:armin.haller@anu.edu.au]
> *Sent:* Thursday, 9 February, 2017 10:47
> *To:* Maxime Lefrançois <maxime.lefrancois@emse.fr>
> <mailto:maxime.lefrancois@emse.fr>; janowicz@ucsb.edu
> <mailto:janowicz@ucsb.edu>; Kerry Taylor <kerry.taylor@anu.edu.au>
> <mailto:kerry.taylor@anu.edu.au>; public-sdw-wg@w3.org
> <mailto:public-sdw-wg@w3.org>
> *Subject:* Re: Different or same Namespace for SOSA/SSN
>
> ISSUE-80 is specifically addressed towards the namespace issue.
> The two proposals are very similar, but have been a point of
> contention for some. Whatever we chose, does not impact further
> integration issues, mainly the unresolved issue if we either reuse
> URIs only (and narrow their semantics) or use
> equivalence/sub-class relations in SSN.
>
> We were working through Kerry’s architecture proposal in our telco
> on the 31^st of January
> https://www.w3.org/2017/01/31-sdwssn-minutes where we got stuck
> on the URIs, the ontology file (which has been resolved since) and
> the namespace. If we have a consensus in our next meeting, I will
> propose to close ISSUE-80. We still have the more general
> integration issues pending, i.e.
> https://www.w3.org/2015/spatial/track/issues/115 and
> https://www.w3.org/2015/spatial/track/issues/139.
>
> *From: *Maxime Lefrançois <maxime.lefrancois@emse.fr
> <mailto:maxime.lefrancois@emse.fr>>
> *Date: *Wednesday, 8 February 2017 at 9:16 pm
> *To: *Armin Haller <armin.haller@anu.edu.au
> <mailto:armin.haller@anu.edu.au>>, "janowicz@ucsb.edu
> <mailto:janowicz@ucsb.edu>" <janowicz@ucsb.edu
> <mailto:janowicz@ucsb.edu>>, Kerry Taylor <kerry.taylor@anu.edu.au
> <mailto:kerry.taylor@anu.edu.au>>, "public-sdw-wg@w3.org
> <mailto:public-sdw-wg@w3.org>" <public-sdw-wg@w3.org
> <mailto:public-sdw-wg@w3.org>>
> *Subject: *Re: Different or same Namespace for SOSA/SSN
>
> Please, I would like us to wait and keep ISSUE-80 open for until
> the integration process is complete,
>
> As you may have noticed, these two proposals are very, very
> similar technically.
>
> It would be quite easy to swap from one to another.
>
> So would I suggest we keep using two different namespaces for now,
> and discuss *once the integration process is complete* the pro and
> cons of these different solutions.
>
> I don't think most of the participants get the full picture and
> implications of one or the other solutions anyways, for now.
>
> Kind regards,
>
> Maxime
>
> Le mer. 8 févr. 2017 à 04:44, Armin Haller
> <armin.haller@anu.edu.au <mailto:armin.haller@anu.edu.au>> a écrit :
>
> Thanks Maxime for the additions to the Wiki!
>
> I think this is now very detailed and we can proceed to vote
> on the last part of the issue embedded in ISSUE-80
> https://www.w3.org/2015/spatial/track/issues/80. Are we using
> one unifying namespace or are we using different namespaces in
> our next telco.
>
> *From: *Maxime Lefrançois <maxime.lefrancois@emse.fr
> <mailto:maxime.lefrancois@emse.fr>>
> *Date: *Wednesday, 8 February 2017 at 3:52 am
> *To: *"janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>"
> <janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>>, Kerry Taylor
> <kerry.taylor@anu.edu.au <mailto:kerry.taylor@anu.edu.au>>,
> Armin Haller <armin.haller@anu.edu.au
> <mailto:armin.haller@anu.edu.au>>, "public-sdw-wg@w3.org
> <mailto:public-sdw-wg@w3.org>" <public-sdw-wg@w3.org
> <mailto:public-sdw-wg@w3.org>>
> *Subject: *Re: Different or same Namespace for SOSA/SSN
>
> Sure !
>
> I think we agreed on this before ...
>
> Le mar. 7 févr. 2017 à 17:45, Krzysztof Janowicz
> <janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>> a écrit :
>
> Just to make sure, in all cases we assume that there are
> two separate files and two separate URLs.
>
>
>
> On 02/07/2017 06:58 AM, Kerry Taylor wrote:
>
> Sanity-checked!
>
> *From:*Armin Haller [mailto:armin.haller@anu.edu.au]
> *Sent:* Tuesday, 7 February 2017 3:09 PM
> *To:* public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>
> *Subject:* Different or same Namespace for SOSA/SSN
>
> Hi,
>
> I have made an attempt to showcase the implementation
> of using different or the same namespace for SOSA and
> SSN on a new wiki page:
>
> **
>
> https://www.w3.org/2015/spatial/wiki/NamespaceIssue
>
> Currently we have an implementation that follows the
> two namespace proposal.
>
> Can I ask, in particular, the advocates of only having
> one namespace for SOSA/SSN to sanity-check the
> implementation option on the Wiki. As this is rather
> unusual ontology design, I don’t know if I have
> captured the intention correctly.
>
> Kind regards,
>
> Armin
>
> --
>
> Krzysztof Janowicz
>
> Geography Department, University of California, Santa Barbara
>
> 4830 Ellison Hall, Santa Barbara, CA 93106-4060
>
> Email: jano@geog.ucsb.edu <mailto:jano@geog.ucsb.edu>
>
> Webpage: http://geog.ucsb.edu/~jano/
> <http://geog.ucsb.edu/%7Ejano/>
>
> Semantic Web Journal: http://www.semantic-web-journal.net
>
> --
> Krzysztof Janowicz
> Geography Department, University of California, Santa Barbara
> 4830 Ellison Hall, Santa Barbara, CA 93106-4060
> Email:jano@geog.ucsb.edu <mailto:jano@geog.ucsb.edu>
> Webpage:http://geog.ucsb.edu/~jano/ <http://geog.ucsb.edu/%7Ejano/>
> Semantic Web Journal:http://www.semantic-web-journal.net
--
Krzysztof Janowicz
Geography Department, University of California, Santa Barbara
4830 Ellison Hall, Santa Barbara, CA 93106-4060
Email: jano@geog.ucsb.edu
Webpage: http://geog.ucsb.edu/~jano/
Semantic Web Journal: http://www.semantic-web-journal.net
Received on Thursday, 9 February 2017 05:24:59 UTC