W3C home > Mailing lists > Public > public-sdw-wg@w3.org > January 2017

Re: State of SSN

From: Krzysztof Janowicz <janowicz@ucsb.edu>
Date: Tue, 31 Jan 2017 08:28:54 -0800
To: Kerry Taylor <kerry.taylor@anu.edu.au>, Armin Haller <armin.haller@anu.edu.au>, "Cox, Simon (CESRE, Kensington)" <Simon.Cox@csiro.au>, SDW WG Public List <public-sdw-wg@w3.org>, Scott Simmons <ssimmons@opengeospatial.org>, "fd@w3.org" <fd@w3.org>
Message-ID: <b44778e2-ca2b-cd1c-10a1-84b82ee1b61e@ucsb.edu>
Hi Kerry,

Okay, Thanks. This needs more discussion. We already have 2 different 
namespaces set up by the W3C. You also objected to using imports before 
and also to using SOSA concepts directly within the SSN, so I am 
confused whether you changed your mind or whether I am misunderstanding 
what you are saying. I also discussed with OWL folks about the direct 
usage of classes instead of extending them as I believe that will lead 
to conflicts and they agreed. Maybe we can discuss this during our telco 
today.

Jano

On 01/30/2017 11:07 PM, Kerry Taylor wrote:
>
> Krzysztof ,
>
> I meant by that to separate the issue of namespace from the rest of 
> the design. It can work just the same with  either 1 or 2 namespaces. 
> That cryptic comment was saying that I do not mean my example to be 
> interpreted as proposing that there needs to be 2 namespaces.   I 
> worked the example on the 2 namespace case. If you prefer, you can 
> s/sosa:/ssn:/g throughout the example and the design is maintained. I 
> copied the “lightweight” axiomitisation of sosa from contemporary 
> github – and modified that or the purpose of the example. Same 
> treatment for ssn. Re import—I am not sure what you mean but I don’t 
> think it matters anyway. (please rephrase and ask again if it  really 
> does matter). In any case any good architectural/modularity design 
> needs to take multiple factors into account and some positive aspects 
> may well be traded off against others for a “best” result. I hope you 
> can see that in my proposal.
>
> Notwithstanding, some interesting and useful contributions on the 
> namespace issue have been put out today by others. Digesting while 
> continuing on the day job…
>
> Kerry
>
> *From:*Krzysztof Janowicz [mailto:janowicz@ucsb.edu]
> *Sent:* Tuesday, 31 January 2017 5:32 PM
> *To:* Kerry Taylor <kerry.taylor@anu.edu.au>; Armin Haller 
> <armin.haller@anu.edu.au>; Cox, Simon (CESRE, Kensington) 
> <Simon.Cox@csiro.au>
> *Subject:* Re: State of SSN
>
> Sorry Kerry, I do not understand what ' In particular I am NOT 
> suggesting that sosa:Platform exists at all. On the contrary, it 
> should always be ssn:Platform. ' means as all the code below is about 
> sosa:Platform. It also does entirely away with the lightweight 
> axiomatization we agreed on for SOSA. It also states that SSN imports 
> SOSA but you rejected this before. In your example,  SOSA also used 
> SSN classes but SOSA does not know about SSN, right? What am I 
> missing? I am a bit confused.
>
>
> On 01/30/2017 10:22 PM, Kerry Taylor wrote:
>
>     Krzysztof ,
>
>     Sure – please see the worked example around the Platform class
>     Iinked below in this email to which you replied.
>     https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Compromise_Proposal_6_made_by_Kerry_January_2017
>
>     I am sorry that it took a while to develop the example --- it
>     would have made sense to do this much sooner.
>
>     -Kerry
>
>     *From:*Krzysztof Janowicz [mailto:janowicz@ucsb.edu]
>     *Sent:* Tuesday, 31 January 2017 3:30 AM
>     *To:* Kerry Taylor <kerry.taylor@anu.edu.au>
>     <mailto:kerry.taylor@anu.edu.au>; Rob Atkinson
>     <rob@metalinkage.com.au> <mailto:rob@metalinkage.com.au>; Armin
>     Haller <armin.haller@anu.edu.au> <mailto:armin.haller@anu.edu.au>;
>     Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>; phila@w3.org
>     <mailto:phila@w3.org>; public-sdw-wg@w3.org
>     <mailto:public-sdw-wg@w3.org>
>     *Cc:* ssimmons@opengeospatial.org
>     <mailto:ssimmons@opengeospatial.org>; fd@w3.org <mailto:fd@w3.org>
>     *Subject:* Re: State of SSN
>
>         Ø) Where SSN needs to create specialisations it can subclass
>         as required, in a new namespace - which can resolve to the
>         SSN-2 graph
>
>         No. And  this may be the nub. SSN should only ever extend sosa
>         concepts , never subclass.  We should standardise the name and
>         meaning of a core term (by its rdfs:comment) in the core and
>         add deeper axiomatic semantics in extended ssn (acknowledgment
>         to Raul for this).
>
>
>     Okay, Kerry, so please show us the OWL axiom by which an SSN
>     concept 'extends' an SOSA concept without subclassing it? :-)
>
>
>     On 01/30/2017 06:35 AM, Kerry Taylor wrote:
>
>         Thankyou Rob,
>
>         I am really grateful that you summarised one possible
>         architecture package. And as far as I can make out it
>         accurately reflects one coherent option being proposed
>         (although it missed perhaps the rdfs’comments part).
>
>         I would like to comment on these 1 by 1 wrt the architecture I
>         have proposed over emails and have jst now documented on the wiki.
>
>         https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Compromise_Proposal_6_made_by_Kerry_January_2017
>
>         Ø1) Regardless of what we call it there will be a new namespace
>
>         Not accepted by me and some others.  There might be a new
>         namespace, but this is highly dependent on architecture as I
>         see it.
>
>         Ø2) SOSA contains the broad, inclusive, definitions for things
>         we care about - i.e. it will be what lives behind that
>         namespace URL and require no specific reasoning on the client
>         side ("lightweight" to use)
>
>         Agreed (with caveat on “that namespace”)
>
>         Ø3) SSN-2 can import and reference these SOSA entities and add
>         additonal axioms (in a flavour of OWL with a specific
>         expressivity which we should document the intent). (richer
>         semantics but more demanding to use)
>
>         Agreed (with important caveats about how that richer semantics
>         is related  to the sosa entities ). Also, unless we have
>         strong arguments to the contrary, ssn has existed and been
>         widely used for 5+ years (legacy) and we should only change
>         what we need to change – ie for which a good argument is made
>         and agreed. There is no carte blanche for ssn.
>
>         Ø) Where SSN needs to create specialisations it can subclass
>         as required, in a new namespace - which can resolve to the
>         SSN-2 graph
>
>         No. And  this may be the nub. SSN should only ever extend sosa
>         concepts , never subclass.  We should standardise the name and
>         meaning of a core term (by its rdfs:comment) in the core and
>         add deeper axiomatic semantics in extended ssn (acknowledgment
>         to Raul for this).
>
>         . 5) informative "Alignments" help others use and understand -
>         but dont affect SOSA or SSN semantics - alignments with DUL
>         and iso-19150 flavour O&M
>
>         The alignment with dul has been removed from ssn as you know,
>         but it does affect semantics in that it is implicit in all ssn
>         concepts and, if not, requires bigger changes to ssn than I am
>         willing to make (remember legacy). So it is “otpional” you
>         don’t have to use it but, just as for sosa terms, the
>         descriptions of ssn terms (rdfs:comment) should be consistent
>         with using the dul alignment.
>
>         As for o&M alignment (repeating myself) I believe we need an
>         alignment with O&M the OGC standard (which, yes is uml, but
>          we can use the “terms” as defined in the standard – and  old
>         ssn already did that for us anyway!)). I am wary of an
>         iso-19150 flavour alignment because it might suggest that we
>         think it should or even could be used, and I don’t think we do
>         believe that, following the discussion at the last meeting.
>         FWIW, I don’t believe that based on personal experience.
>
>         > My naive understanding is if we publish an alignment using
>         strong axioms (equivalence or subclass?) then we are able to
>         use original SSN deployments as evidence of implementation ...
>         of the subset of semantics  - but we'd still need IMHO to
>         demonstrate the broader sense and any new concepts. So its not
>         trivial and we'd need a plan anyway - maybe its easier just to
>         get someone to upgrade their legacy SSN to the new SOSA scope
>         and namespace and show the broader definitions are usable
>         directly.
>
>         Phil has advised us to be wary of being driven by the
>         implementation demands. However, as the implementation
>         requirements and goals to serve our legacy users align well ,
>         I believe we should be able to use implelementation evidence
>         from the old terms. If we follow the architecture I propose
>         then this **could** carry over to sosa terms as well, I think
>         – but that is my untested theory and is only happenstance.  In
>         any case, as you saty we do need the evidence for any new
>         concepts.
>
>         -Kerry
>
>         *From:*Rob Atkinson [mailto:rob@metalinkage.com.au]
>         *Sent:* Monday, 30 January 2017 11:59 AM
>         *To:* Kerry Taylor <kerry.taylor@anu.edu.au>
>         <mailto:kerry.taylor@anu.edu.au>; janowicz@ucsb.edu
>         <mailto:janowicz@ucsb.edu>; Armin Haller
>         <armin.haller@anu.edu.au> <mailto:armin.haller@anu.edu.au>;
>         Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>; phila@w3.org
>         <mailto:phila@w3.org>; public-sdw-wg@w3.org
>         <mailto:public-sdw-wg@w3.org>
>         *Cc:* ssimmons@opengeospatial.org
>         <mailto:ssimmons@opengeospatial.org>; fd@w3.org <mailto:fd@w3.org>
>         *Subject:* Re: State of SSN
>
>         I think Kerry is correct to say we need to get on the same
>         page with the "architecture" - and until we do that its hard
>         to actually understand everybody's positions. Perhaps we focus
>         on what that architecture means for users and the process?
>
>         Here's my understanding of that architecture:
>
>         1) Regardless of what we call it there will be a new namespace
>
>         2) SOSA contains the broad, inclusive, definitions for things
>         we care about - i.e. it will be what lives behind that
>         namespace URL and require no specific reasoning on the client
>         side ("lightweight" to use)
>
>         3) SSN-2 can import and reference these SOSA entities and add
>         additonal axioms (in a flavour of OWL with a specific
>         expressivity which we should document the intent). (richer
>         semantics but more demanding to use)
>
>         4) Where SSN needs to create specialisations it can subclass
>         as required, in a new namespace - which can resolve to the
>         SSN-2 graph
>
>         5) informative "Alignments" help others use and understand -
>         but dont affect SOSA or SSN semantics - alignments with DUL
>         and iso-19150 flavour O&M
>
>         All this is pretty straightforward IMHO until we hit the
>         "legacy SSN" case
>
>         My naive understanding is if we publish an alignment using
>         strong axioms (equivalence or subclass?) then we are able to
>         use original SSN deployments as evidence of implementation ...
>         of the subset of semantics  - but we'd still need IMHO to
>         demonstrate the broader sense and any new concepts. So its not
>         trivial and we'd need a plan anyway - maybe its easier just to
>         get someone to upgrade their legacy SSN to the new SOSA scope
>         and namespace and show the broader definitions are usable
>         directly.
>
>         Rob
>
>         On Mon, 30 Jan 2017 at 10:53 Kerry Taylor
>         <kerry.taylor@anu.edu.au <mailto:kerry.taylor@anu.edu.au>> wrote:
>
>         _>Option 2: SSN new imports SOSA *and* “extends”
>         classes/properties from SOSA: _In this option both ontologies
>         use a separate namespace, but /SSN new/ extends >SOSA, meaning
>         /SSN new/ uses the SOSA namespace for concepts/properties that
>         are shared between SOSA and /SSN new/ and “extends” (narrows)
>         them with >stronger OWL axiomatizations.
>
>         This is close, but not an accurate representation of my
>         position. Please see the multiply-posted comments under the
>         topic of  issue-88 , including but by no means limited to :
>         https://lists.w3.org/Archives/Public/public-sdw-wg/2017Jan/0099.html
>
>         I will endeavour to write it up again on the wiki --- with a
>         worked example if I can for the next  ssn meeting, although I
>          cannot promise to complete in time.
>
>         I would like to add that I don’t see how these things can be
>         solved term by term  or comment-by-comment as is currently
>         proposed by the Chair.  The architecture of modularisation has
>         been questioned for a **very** long time  (and there are
>         multiple unresolved issues on the tracker on this topic e.g.
>         issue-37, issue-115, issue-120, issue-139) yet has failed to
>         be fully articulated ---- so it seems we all  have,
>         unsurprisingly, different interpretations of the intention.
>         The fact that sosa , as the “core” module of ssn, was
>         developed quite independently of ssn and with apparent
>         disregard of these modularisation/architecture questions is
>         rather unfortunate --- but nothing that can not  be fixed.
>
>         And, for the record, I do not accept that that any alignment
>         between ssn or sosa is either useful or necessary.  It is
>         frankly absurd that an ontology needs to be  ”aligned” with
>         it’s own core! The alignment  proposed in the past week is
>         also highly faulty – I need to put this opinion on  the record
>          only because I am  wary of  being told  again that “we all
>         agreed” with something that has  simply been posted to github
>          by surprise. However, because I believe it is neither useful
>         nor necessary I will not go into details of the faults here.
>
>         --Kerry
>
>         *From:*Krzysztof Janowicz [mailto:janowicz@ucsb.edu
>         <mailto:janowicz@ucsb.edu>]
>         *Sent:* Thursday, 26 January 2017 2:09 PM
>         *To:* Armin Haller <armin.haller@anu.edu.au
>         <mailto:armin.haller@anu.edu.au>>; Simon.Cox@csiro.au
>         <mailto:Simon.Cox@csiro.au>; phila@w3.org
>         <mailto:phila@w3.org>; public-sdw-wg@w3.org
>         <mailto:public-sdw-wg@w3.org>
>         *Cc:* ssimmons@opengeospatial.org
>         <mailto:ssimmons@opengeospatial.org>; fd@w3.org <mailto:fd@w3.org>
>
>
>         *Subject:* Re: State of SSN
>
>         Hi All,
>
>
>
>         Thanks Armin for the nice summary!
>
>         Please note however that option 3 would contradict our own
>         figures and draft as pointed out by Phil and this figure (and
>         text) has been around for a year now.
>
>         Options 1 and 2 are what we need and as SSN imports SOSA
>         anyway, 2 may be easier solution.
>
>         Wrt to the comments, I agree with the idea in general (and
>         proposed it myself before) but think we need to be very, very
>         careful here. *Abstract* comments are almost never a good idea
>         and may actually hurt SOSA *and* SSN. Again, just to be clear
>         about this, ideally we would have the same comment but this
>         comment has to be on a level that is directly understandable
>         and usable, i.e., not too abstract.
>
>         Frankly speaking, I am not so happy with having them reworked
>         all at a time by a single person and then presented. Why don't
>         we use the next 2-3 telco's to do this together class by
>         class  as a group so that we do not have to re-discuss them
>         afterwards over and over again to find a compromise. We are
>         really running late by now :-)
>
>         Cheers and thanks again!
>         Jano
>
>         P.s. Let us also please switch back to a mode where everybody
>         participates regularly and does not merely jump in a few times
>         per year to revisit decisions taken months ago, and let us
>         also all work in a constructive and supportive atmosphere. We
>         have a great and impactful product and we are all interested
>         in getting it in the best possible shape.
>
>
>
>         On 01/25/2017 03:36 PM, Armin Haller wrote:
>
>             Hi Phil,
>
>             Thanks for raising these points. I had a longer F2F
>             conversation with Kerry yesterday to discuss her concerns
>             around the SOSA/SSN alignment and the more general issue
>             she raised with
>             https://www.w3.org/2015/spatial/track/issues/139. I think
>             I now understand her preference, which I will outline in
>             this email. Before, I want to more clearly outline the
>             options we have in terms of alignment between SOSA and
>             /SSN new /as of Point 6 from Phil below, seeing SOSA as
>             the core as already outlined in the first working draft.
>
>             _Option 1: SSN new imports SOSA *and*
>             equivalence/subclass/subproperty relations are defined in
>             SSN_: In this option both ontologies use a separate
>             namespace and /SSN ne/w introduces its own
>             classes/properties (in its own namespace) even for
>             concepts/properties that are common to both ontologies,
>             while doing so asserting equivalence and
>             subclass/subproperty relations for those classes that are
>             common and where appropriate.
>
>             _Option 2: SSN new imports SOSA *and* “extends”
>             classes/properties from SOSA: _In this option both
>             ontologies use a separate namespace, but /SSN new/ extends
>             SOSA, meaning /SSN new/ uses the SOSA namespace for
>             concepts/properties that are shared between SOSA and /SSN
>             new/ and “extends” (narrows) them with stronger OWL
>             axiomatizations.
>
>             _Option 3: SSN does not import SOSA *and* alignment
>             between SOSA and SSN is defined in a separate
>             file/namespace:_ This approach is similar to how we align
>             /SSN new/ to DULCE, i.e. the alignment is in a separate
>             file with its separate namespace.
>
>             Although my personal preference from the beginning was on
>             Option 2, my belief was that some group members are
>             against this option, in particular, Kerry, and I was under
>             the working assumption that at best we will achieve Option
>             3. In my discussion with Kerry yesterday she made it very
>             clear that she prefers _direct usage of SOSA
>             classes/properties in SSN new_. This includes the
>             introduction of properties in /SSN new/ that are defined
>             in SOSA for simplicity (traversing a property path of SSN
>             new) while adding axioms to ensure the equivalence of
>             these simplified properties to a property path. This also
>             means that rdfs:comments will be shared between SOSA and
>             /SSN new/. Since neither of the rdfs:comments in our
>             mapping table on the wiki
>             (https://www.w3.org/2015/spatial/wiki/Mapping_Table)
>             <https://www.w3.org/2015/spatial/wiki/Mapping_Table%29>
>             are yet particularly suited for this purpose, the proposal
>             was:
>
>             -To create one very abstract description for each shared
>             concept that _DOES NOT_ refer to classes/properties (i.e.
>             using capital letters or camel casing), but uses English
>             natural language. This rdfs:comment can then be
>             _supplemented by annotation properties_ in the two
>             respective namespaces of SOSA and SSN new. These
>             annotation properties can add examples, refer to classes
>             and properties in the respective namespace using capital
>             letters and describe the stronger semantics as required by
>             /SSN new/.
>
>             *If there is no objection from the group, I have
>             volunteered to start with such an abstract description for
>             the rdfs:comments in the mapping table. *I cannot
>             guarantee to finish by our meeting next week, but I will
>             attempt to at least finish some of those.
>
>             Beyond that, the agreement with Kerry was that we continue
>             (in the phone calls) with addressing the issues that have
>             been already identified (by her) in the issue tracker in
>             the alignment between SOSA and /SSN new/.
>
>             Kind regards,
>
>             Armin
>
>             On 25/1/17, 11:28 pm, "Simon.Cox@csiro.au"
>             <mailto:Simon.Cox@csiro.au> <Simon.Cox@csiro.au>
>             <mailto:Simon.Cox@csiro.au> wrote:
>
>                 Thanks Phil -
>
>                 Just want to comment on your item 2.
>
>                 SOSA is not 'inspired by O&M' any more than it is by
>             any of the other prior work. It was an attempt to define a
>             core with lightweight semantics for an audience interested
>             in describing observations, actuation or sampling. The
>             hope was that it could also serve as a core for more
>             semantically rich vocabularies, along the lines proposed
>             by Jano (aka vertical and horizontal modularization). So
>             the scope of SOSA is broad but it is axiomatically shallow
>             - deliberately not much more than schema-org style.
>             Certainly it picks up some ideas from O&M, in particular
>             the notion of Samples, but it also picks up ideas from IoT
>             (Actuators) and SSN (Platform, properties of Sensors).
>             SOSA is definitely not something that has just come from
>             the O&M camp.
>
>                 Simon
>
>                 -----Original Message-----
>
>                 From: Phil Archer [mailto:phila@w3.org]
>
>                 Sent: Wednesday, 25 January, 2017 20:41
>
>                 To: SDW WG Public List <public-sdw-wg@w3.org>
>             <mailto:public-sdw-wg@w3.org>
>
>                 Cc: Scott Simmons <ssimmons@opengeospatial.org>
>             <mailto:ssimmons@opengeospatial.org>; Francois Daoust
>             <fd@w3.org> <mailto:fd@w3.org>
>
>                 Subject: State of SSN
>
>                 Dear all,
>
>                 As team contact for the WG, my role is not necessarily
>             to get involved in every aspect of each of our
>             deliverables. As is abundantly clear from our discussions
>             over the last couple of years, the WG members are the
>             domain experts, not me. But, all is not well in the state
>             of SSN and so I feel that I need to take a more active
>             position. My mail on Monday [1] is part of that.
>
>                 My understanding of the current situation is likely to
>             be less than 100% accurate - I know that - but what I see is:
>
>                 1. There is a lot of prior work that predates the WG:
>             SSN, O&M, Dolce.
>
>                 2. There is SOSA, which is, I think I'm right in
>             saying, largely inspired by the work to represent O&M in
>             OWL and create a simple version for wider use.
>
>                 3. There is a very understandable desire to see this
>             work become a formal standard - that's what we're
>             chartered to do. This entails gathering evidence of usage.
>             But the problem is that the evidence that exists is from
>             earlier work. What's being done now might be too new and
>             we may not be able to gather that implementation evidence.
>             That would be a pity but it's better than a bad design
>             driven by process. SSN has a reputation for being too
>             complicated so let's not hesitate to simplify it.
>
>                 4. The published document states clearly that SOSA is
>             the core and that SSN is an outer ring, with O&M and Dolce
>             Ultra Lite alignments outside both.
>
>                 5. There is a debate about whether the alignments,
>             especially with O&M, should be normative. In favour: O&M
>             is a formal standard and it feels right to me that it
>             should be but I'm open to persuasion either way.
>
>                 6. There is a debate about whether the SOSA-SSN
>             relationship should be couched as sub classes/properties
>             or whether one should be an extension of the other. That's
>             a legitimate technical argument. Over to you to sort it -
>             but as a design principle, please don't have the same
>             property/class names in the two namespaces with different
>             semantics (ssn:Platform and sosa:Platform, for example).
>             My instinct is to prefer direct usage over sub classes but
>             that's a generalist's view.
>
>                 7. There is work going on concerning the SOSA-SSN
>             alignment that is being shared piecemeal, issue by issue.
>             That is not right. Put it on the wiki or GH, argue about
>             it, edit it in front of everyone. The idea of "we'll share
>             it when it's finished" is not the way we should work.
>
>                 8. There is a lot of unhappiness in the SSN group at
>             the moment, which is unfortunate and needs to be fixed
>             before everyone walks away.
>
>                 9. If the group so wishes, we can easily arrange a one
>             off long telco.
>
>                 Phil.
>
>                 [1]
>             https://lists.w3.org/Archives/Public/public-sdw-wg/2017Jan/0096.html
>
>                 --
>
>                 Phil Archer
>
>                 Data Strategist, W3C
>
>             http://www.w3.org/
>
>             http://philarcher.org
>
>             +44 (0)7887 767755 <tel:+44%207887%20767755>
>
>             @philarcher1
>
>         -- 
>
>         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 <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 Tuesday, 31 January 2017 16:30:00 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:28 UTC