Re: rdfs:class versus owl:class in SOSA-Core & JSON

Not sure "as  JSON-LD only" makes much sense to me - JSON-LD is more
appropriate for instance document using SOSA-core than conveying the
definitions. And its not dependent on the definitions themselves published
in JSON.  Maybe I'm missing something here,

Rob



On Mon, 14 Nov 2016 at 09:31 Kerry Taylor <kerry.taylor@anu.edu.au> wrote:

> Danh,
>
>
>
> I have not performed the analysis that you have, but I want to say that I
> would be very happy if indeed there was no need or reason  for RDFS
> reasoning  on sosa-core.  Recall Josh’s remark about how people might use
> sosa-core (having nothing at all to do with rdfs).
>
>
>
> So, to answer your question
>
> Ø  Are there any useful features/benefits on enabling RDF reasoners for
> the data annotated with the SSN/SOSA core ontology?”.
>
>
>
> I would like very much  to say NO!  And I would like to design sosa-core
> accordingly, but it may be too surprising to hide the rdf/rdfs entirely.
>
>
>
> A strong vote from me would be to publish the core as  JSON-LD only. And
> to only say things as they are said in JSON-LD and not to attempt to say
> anything else. And if this also means we are saying nothing stronger than
> schema.org does then that would be good too. Can we find sufficient
> JSON-LD expertise in the group to confidently do this?
>
>
>
> --Kerry
>
>
>
>
>
> *From:* Le Phuoc, Danh [mailto:danh.lephuoc@tu-berlin.de]
> *Sent:* Monday, 14 November 2016 12:44 AM
> *To:* Kerry Taylor <kerry.taylor@anu.edu.au>; janowicz@ucsb.edu; Rob
> Atkinson <rob@metalinkage.com.au>; Simon.Cox@csiro.au;
> antoine.zimmermann@emse.fr; Armin Haller <armin.haller@anu.edu.au>;
> jano@geog.ucsb.edu; jlieberman@tumblingwalls.com
>
>
> *Cc:* public-sdw-wg@w3.org
> *Subject:* Re: rdfs:class versus owl:class in SOSA-Core & JSON
>
>
>
> Hi Kerry and Krzysztof and all,
>
>
>
> I would like to divert the discussion on “trying to support RDF reasoners
> or only consider RDFS reasoning” in the SSN-core/SOSA(-core) to the
> question “Are there any useful features/benefits on enabling RDF reasoners
> for the data annotated with the SSN/SOSA core ontology?”.
>
>
>
> Corresponding to the RDFS interpretation rules of RDF1.1 semantics [1], I
> can find only *one single statement. i.e.* “sosa-core:resultTime
> rdfs:range xsd:dateTime” in current version of SOSA-core[2] that can
> trigger the RDFS reasoning. In practice, RDFS reasoner can only infers more
> interesting data if the common RDFS axioms with rdfs:range, rdfs:domain,
> rdfs:subClassOf, rdfs:subPropertyOf  are combined in the ontology.
>
>
>
> So, I would say we would get nothing or very little useful RDFS-entailed
> data from sensor/observation data annotated with it. That means RDFS
> reasoning is out of the picture when using only current version of SSN/SOSA
> core[1]. Please correct me if I’m wrong here.
>
>
>
>
>
> Best regards,
>
>
>
> Danh
>
>
>
> [1]  https://www.w3.org/TR/rdf11-mt/#rdfs-interpretations
>
> [2] https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/sosa.ttl
>
>
>
>
>
> *From: *Kerry Taylor <kerry.taylor@anu.edu.au>
> *Date: *Sunday 13 November 2016 at 06:46
> *To: *"janowicz@ucsb.edu" <janowicz@ucsb.edu>, Rob Atkinson <
> rob@metalinkage.com.au>, "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, "
> antoine.zimmermann@emse.fr" <antoine.zimmermann@emse.fr>, Armin Haller <
> armin.haller@anu.edu.au>, "jano@geog.ucsb.edu" <jano@geog.ucsb.edu>, "
> jlieberman@tumblingwalls.com" <jlieberman@tumblingwalls.com>
> *Cc: *"public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
> *Subject: *RE: rdfs:class versus owl:class in SOSA-Core & JSON
> *Resent-From: *<public-sdw-wg@w3.org>
> *Resent-Date: *Sunday 13 November 2016 at 06:47
>
>
>
> Krzysztof,
>
> We are all trying to build a core that will be used, and specifically in
> the context of recognising that SSN is too complicated for some people. So
> we need SOSA to be *not* too complicated.
>
> This is the single most important goal of our charter wrt to SSN ( ok,
> second only to developing SSN to formal  recommendation).
>
>
>
> Quoting: The WG will work with the members of the former Semantic Sensor
> Network Incubator Group <http://www.w3.org/2005/Incubator/ssn/> to
> develop its ontology <http://www.w3.org/2005/Incubator/ssn/ssnx/ssn> into
> a formal Recommendation, noting the work to split the ontology into
> smaller sections
> <http://lists.w3.org/Archives/Public/public-ssn-cg/2012Jun/0000.html> to
> offer simplified access.
>
>
>
> Whether something in particular, e.g. Actuation, is covered or not is well
> down the priority list.
>
>
>
> We all know that owl:xxx constructs of any kind do not cause problems for
> RDFS reasoners computing RDFS entailment. I think I’ll scream next time
> somebody repeats that. But they do create (a) expectations of some
> semantics being implemented somewhere and (b) expectations of various tools
> doing things or not, and (c) expectations of casual ontology readers and
> users  that they know what those things mean.
>
>
>
> All these aspects very significantly affect “simplified access”. Owl:class
> is probably the very least important such owl term, but it does provide a
> convenient test point for owl terms in general.
>
>
>
> --Kerry
>
>
>
>
>
> *From:* Krzysztof Janowicz [mailto:janowicz@ucsb.edu <janowicz@ucsb.edu>]
> *Sent:* Sunday, 13 November 2016 2:33 AM
> *To:* Rob Atkinson <rob@metalinkage.com.au>; Kerry Taylor <
> kerry.taylor@anu.edu.au>; Simon.Cox@csiro.au; antoine.zimmermann@emse.fr;
> Armin Haller <armin.haller@anu.edu.au>; jano@geog.ucsb.edu;
> jlieberman@tumblingwalls.com
> *Cc:* public-sdw-wg@w3.org
> *Subject:* Re: rdfs:class versus owl:class in SOSA-Core & JSON
>
>
>
> IMHO its still a significant choice as to whether we include RDFS than can
> be inferred from OWL or ask users to perform OWL reasoning if they want to
> understand it as RDFS classes.
>
>
> Agreed. But Antoine already confirmed what we said before. Using owl:class
> will not cause any problems for RDFS reasoners. If we want to be extra sure
> we will declare owl:class and rdfs:class at the same time.
>
> The same is true for inverse properties, they do not cause any harm from
> an RDFS-only perspective. This leaves us the domainincludes and
> rangeincludes properties that we already know will not cause harm and this
> is basically it. At least for what we have modeled so far.
>
>
> +1 to putting this to bed and working on the content
>
>
> Fantastic! I think (and hope) that we are all more or less on the same
> page as far as contents are concerned as those have been online since the
> spring. Our next steps should be to polish what we have, clarify the
> outstanding issues that remain, and then make sure we can get those
> implementations that we will need for the rectrack.
>
> Looking forward to the next steps.
> Krzysztof
>
>
>
> On 11/11/2016 11:33 PM, Rob Atkinson wrote:
>
> +1 to putting this to bed and working on the content - but until we are
> all on the same page it is proving a distraction - hence my attempt to lay
> out the options so i at least understand the differeng points of view and
> assumptions I am detecting.
>
>
>
> IMHO its still a significant choice as to whether we include RDFS than can
> be inferred from OWL or ask users to perform OWL reasoning if they want to
> understand it as RDFS classes.  Because we get sidetracked by whether we
> are going to allow or disallow stuff we keep failing to reach a consensus
> on this very simple matter. Yes its only packaging for some of us, but if
> you are not operating in an OWL tools environment I think you will face an
> unnecessary barrier.
>
>
>
> Whether to put owl semantics in a separate module which imports the base
> is another matter - this shouldnt affect OWL tools.  We can also use
> content-negotiation so if you ask for OWL you get the OWL package, but if
> you ask for RDF you get the core, with some sort of link (rdfs:seeAlso?) to
> the OWL. I'm agnostic about this, but suspect if we want to have different
> flavours of OWL (RL, DL etc) we'll need to analyse the requirement some
> more.
>
>
>
> Rob
>
>
>
>
>
> On Sat, 12 Nov 2016 at 16:34 Krzysztof Janowicz <janowicz@ucsb.edu> wrote:
>
> Hi,
>
> I am not sure what this all means, but I have to say that I wonder why we
> are turning something that is really simple into an unbelievable
> complicated issue.
>
> Why, for instance, would we want to restrict SOSA-Core to barely using
> RDFS? We already have many, many people that voiced their support for
> explicitly declaring inverse relations?
>
> We should be talking about whether we agree on the concepts and their
> interpretations in SOSA-core.
>
> Best,
> Krzysztof
>
>
>
>
> On 11/11/2016 09:20 PM, Kerry Taylor wrote:
>
> I think Rob’s (2) below is the only thing that makes any sense, especially
> in the context of the decision at the F2f in Lisbon two have exactly 2
> modules – core and ssn-minus-dul. (with the dul alignment also available,
> but not part of it).
>
>
>
> I rather like Rob’s(1)  but it is much too late to get there from here. I
> can live with Rob’s(3).
>
>
>
>
>
> But I am not sure I understand this:
>
>
>
> Ø  Note also that if we publish two modules: sosa.OWL-DL and  sosa.RDFS,
>   and the RDFS is generated from the OWL, then the fact that RDFS does not
> have an import makes option that nearly equivalent to option #2 (the OWL
> does not need to import the RDFS, although it could do so)
>
>
>
> Issue-72
>
>
>
> *From:* Krzysztof Janowicz [mailto:janowicz@ucsb.edu <janowicz@ucsb.edu>]
> *Sent:* Thursday, 10 November 2016 3:34 PM
> *To:* Rob Atkinson <rob@metalinkage.com.au> <rob@metalinkage.com.au>;
> Kerry Taylor <kerry.taylor@anu.edu.au> <kerry.taylor@anu.edu.au>;
> Simon.Cox@csiro.au; antoine.zimmermann@emse.fr; Armin Haller
> <armin.haller@anu.edu.au> <armin.haller@anu.edu.au>; jano@geog.ucsb.edu;
> jlieberman@tumblingwalls.com
> *Cc:* public-sdw-wg@w3.org
> *Subject:* Re: rdfs:class versus owl:class in SOSA-Core
>
>
>
> Hi Rob,
>
> I think this goes back to the issue I raised here:
> https://lists.w3.org/Archives/Public/public-sdw-wg/2016Nov/0065.html .
> Lets discuss our modeling choices first and then decide about
> representational choices. The solution we have now is just fine and so far
> nobody was able to bring up any other argument that would point to any
> problem (assuming we add both owl:class and rdfs:class as extra level of
> safety).
>
> SOSA -core is supposed to be a conceptually simple, not based on a
> 'simple' representation language.
>
> Best,
> Krzysztof
>
>
>
> On 11/09/2016 08:03 PM, Rob Atkinson wrote:
>
>
>
> my opinion is that I'm happy to have owl constructs as long as the rdfs
> that would be entailed by OWL reasoning, but not RDFS reasoning, is
> materialised, and hence the user is not expected to use an OWL reasoner.
> There seems to be a consensus (or at least no counter-arguments to this
> specific policy ACAICT)
>
>
>
> I am therefore agnostic as whether all OWL is in a extension model which
> supports OWL-DL (?) reasoning - and is part of the normative semantics. I
> guess the question is whether there is a need for a subset of OWL semantics
> which imposes a low burden an OWL reasoner (a simple core). Others with
> more experience need to weigh in and document the subset and we can then
> vote if we are happy to include it in the core.
>
>
>
> Kerry has made the useful point that expectations are raised when a user
> finds OWL constructs. Perhaps that can be managed by clear enough
> documentation that all RDFS semantics implied by such OWL is materialised.
>
>
>
> There is a possible lower level of commitment - in that in the core terms
> are just defined using SKOS, without any form of class model - but I think
> we all feel that the world is used to simple RDFS models and we could use
> that as a moderately expressive baseline.
>
>
>
> So I see the choice is between:
>
> 1) something like SKOS Concepts to "reserve" resource names and attach
> documentation
>
> 2) RDFS only + OWL module that imports it
>
> 3) RDFS inc. "cheap to process OWL"  + OWL-DL module that imports it
>
> 4) OWL-DL only
>
> 5) OWL-DL with entailed RDFS
>
> 6) something I've missed :-)
>
>
>
> Note also that if we publish two modules:
>
> sosa.OWL-DL and  sosa.RDFS,   and the RDFS is generated from the OWL,
> then the fact that RDFS does not have an import makes option that nearly
> equivalent to option #2 (the OWL does not need to import the RDFS, although
> it could do so)
>
>
>
> I propose we get this list of options nailed down so we can identify which
> flavour we are talking about in future, and then if we cant get a consensus
> quickly document pros and cons, and specifically anything we might break
> for users. (As an example I personally think #4) (OWL-DL only) breaks it
> for RDFS-only based reasoning)
>
>
>
> Rob Atkinson
>
>
>
> On Thu, 10 Nov 2016 at 12:55 Kerry Taylor <kerry.taylor@anu.edu.au> wrote:
>
> And therein lies another dragon -- or   an elephant?
>
> In ssn  a ssn:MeasurementCapability   is not defined with domain/range.
> Instead it is defined via a local allvaluesfrom restriction on Sensor.  So
> certainly this following  holds:
>
> >   ?x :hasMeasurementCapability  ?y .
> >  I cannot conclude that ?y is a :MeasurementCapability
>
> One of the many promises of the "simple"  core is that it is simpler than
> full  ssn in the sense that   it makes weaker  ontological commitments (see
> the notion of "vertical modularisation" in the FPWD).
>
> So this automatically forbids rdfs:domain and rdfs:range in this case and
> similarly most others. Or otherwise it forbids one of many other broadly
> agreed goals.
>
>
> Having said that, which remains true in general, hasMeasurementCapability
> in particular is not currently  proposed to exist at all in sosa-core
> https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/sosa.ttl.  So there may
> be no issue there.
>
> However the same principle should indeed apply to observedProperty, for
> example, which does occur in the core.
>
> -----Original Message-----
> From: Simon.Cox@csiro.au [mailto:Simon.Cox@csiro.au]
> Sent: Thursday, 10 November 2016 12:19 PM
> To: antoine.zimmermann@emse.fr; janowicz@ucsb.edu; Armin Haller <
> armin.haller@anu.edu.au>; jano@geog.ucsb.edu; jlieberman@tumblingwalls.com;
> Kerry Taylor <kerry.taylor@anu.edu.au>
> Cc: public-sdw-wg@w3.org
> Subject: RE: rdfs:class versus owl:class in SOSA-Core
>
> > something really wrong in the name of the property!  Or, alternatively
> there ought to be a rdfs:range axiom.
>
> An owl:ObjectProperty without a rdfs:range axiom is usually be missing the
> most significant part of the semantics. I generally add these as a matter
> of course (not so for rdfs:domain). As Jano pointed out, semantics
> shouldn't depend on labels.
>
> Simon
>
> -----Original Message-----
> From: Antoine Zimmermann [mailto:antoine.zimmermann@emse.fr]
> Sent: Thursday, 10 November 2016 10:06 AM
> To: janowicz@ucsb.edu; Armin Haller <armin.haller@anu.edu.au>; Krzysztof
> Janowicz <jano@geog.ucsb.edu>; Joshua Lieberman <
> jlieberman@tumblingwalls.com>; Cox, Simon (L&W, Clayton)
> <Simon.Cox@csiro.au> <Simon.Cox@csiro.au>; Kerry Taylor <
> kerry.taylor@anu.edu.au>
> Cc: SDW WG Public List <public-sdw-wg@w3.org>
> Subject: Re: rdfs:class versus owl:class in SOSA-Core
>
> On 09/11/2016 23:46, Krzysztof Janowicz wrote:
> >>
>
> [...]
>
> >> -rdfs:domain and rdfs:range
> >>
> >> Please use these whenever relevant. [...]. You can't go wrong with them.
> >
> > This is the only part of your email where I would strongly disagree
> > (well, depending on what you mean by 'whenever relevant' :-)) for the
> > reasons we discussed here before and that others made when developing
> > other ontologies. This is not to say that using them is 'wrong' in
> > some sense but that they have to be handled with great care.
>
> On this, I know what you mean. I've read the arguments that were written
> at some point in the SSN draft. I know that it is wise to avoid systematic
> domains and ranges that could be too restrictive.
>
> But I think that this went too far with things like:
>
> :hasMeasurementCapability  a  owl:ObjectProperty .
> :MeasurementCapability  a  owl:Class .
>
> and no range for :hasMeasurementCapability. If, whenever I find:
>
>   ?x :hasMeasurementCapability  ?y .
>
>   I cannot conclude that ?y is a :MeasurementCapability, then there is
> something really wrong in the name of the property!  Or, alternatively
> there ought to be a rdfs:range axiom.
>
>
> --AZ
>
>
>
> >
> > Best,
> > Krzysztof
> >
> >
> >
> > On 11/09/2016 01:15 PM, Antoine Zimmermann wrote:
> >> On 09/11/2016 00:20, Armin Haller wrote:
> >>> Hi Krzysztof,
> >>>
> >>> Thanks for your detailed explanations below!
> >>>
> >>> Just to clarify, the intention in the meeting to go through a list
> >>> of what constructs should be in SOSA (as thankfully proposed by
> >>> Josh) was to be incremental. I was planning to incrementally go
> >>> through the list of constructs that are either already in our
> >>> current SOSA proposal or could be imagined to be in it and vote on
> >>> them. Some, of course have implications, if we decide on
> >>> owl:inverseOf in our next meeting, we will not be in RDFS entailment.
> >>
> >> I was not at the meeting, so I may have missed something, but what is
> >> the rationale for forbidding certain constructs?  If there is an
> >> owl:inverseOf in the ontology, the RDFS reasoners won't care. Nobody
> >> who's not using/interested in owl:inverseOf will care.
> >>
> >> However, in the case of owl:inverseOf, I don't think it is a question
> >> of whether we want to use the construct or not. It is a question of
> >> deciding whether we allow ourselves to define both a property and its
> >> inverse. If we have properties like ex:hasChild and ex:hasParent, it
> >> would be silly not to make explicit the inverse relationship. If the
> >> decision is about not having both a property and its inverse, then
> >> the need to use or not owl:inverseOf is only an inevitable
> >> consequence of the other decision.
> >>
> >>
> >>> If we are already in OWL, then of course it would make sense to use
> >>> owl:Class, although we do not have to. Therefore, again a vote on
> >>> owl:Class thereafter.
> >>
> >> I don't see a reason not to. Not having owl:Class declaration has
> >> noticeable consequences. For instance, it always troubles me that
> >> Protégé cannot display the Dublin Core properties and classes. It
> >> also troubles me that the DC terms cannot be imported with standard
> >> owl:imports, because of the lack of owl class, owl properties
> >> declarations.
> >>
> >>
> >>> I can think of the following list to vote on in our next meeting,
> >>> incrementally. And we stopped at owl:inverseOf this meeting I just
> >>> saw in the minutes.
> >>>
> >>> -rdfs:class
> >>
> >> see above and related emails.
> >>>
> >>> -owl:inverseOf
> >>
> >> see above.
> >>>
> >>> -owl:AnnotationProperty
> >>>
> >>> -           owl:ObjectProperty
> >>
> >> owl:AnnotationProperty, owl:ObjectProperty and owl:DatatypeProperty,
> >> like owl:Class, do not add expressiveness to the language. However,
> >> they help OWL tools figuring out what the terms are.
> >>
> >> FWIW, in OWL 2 RDF-based semantics, owl:ObjectProperty is equivalent
> >> to rdf:Property. owl:AnnotationProperty and owl:DatatypeProperty are
> >> both subClassOf rdf:Property.
> >>
> >>>
> >>> -owl:Class
> >>
> >> see above.
> >>
> >>>
> >>> -rdfs:domain and rdfs:range
> >>
> >> Please use these whenever relevant. When used with an atomic class,
> >> they are fully supported by RDFS, OWL 2 EL, OWL 2 QL, OWL 2 RL, OWL 2
> >> DL, OWL 2 Full, ter Horst semantics, RDFS++. You can't go wrong with
> >> them.
> >>
> >>>
> >>> -rdfs:subClassOf
> >>
> >> Come on! Do we need to vote on this one?
> >>
> >>>
> >>> -           owl:Restriction
> >>
> >> There are many forms of restrictions, each one should be considered
> >> individually. I don't see much reason to forbid ourselves to use any
> >> of them because anyone can just ignore those they don't like.
> >> However, they should be used sensibly because we should not prevent
> >> use cases that we have not foreseen. I'd prefer an ontology that has
> >> very little restrictions with precise documentation to prevent
> >> misusing the terms, rather than an overly restrictive one. Look at
> >> schema.org: painfully non-restrictive, delightfully useful.
> >>
> >>
> >> --AZ
> >>
> >>>
> >>> Please do think about these and if you think they should or should
> >>> not be in the core or if there is anything else we desperately would
> need.
> >>>
> >>> Kind regards,
> >>> Armin
> >>>
> >>> *From: *Krzysztof Janowicz <jano@geog.ucsb.edu>
> >>> *Date: *Wednesday, 9 November 2016 at 10:01 am
> >>> *To: *Joshua Lieberman <jlieberman@tumblingwalls.com>, Simon Cox
> >>> <Simon.Cox@csiro.au> <Simon.Cox@csiro.au>, Kerry Taylor <
> kerry.taylor@anu.edu.au>, Armin
> >>> Haller <armin.haller@anu.edu.au>
> >>> *Cc: *SDW WG Public List <public-sdw-wg@w3.org>
> >>> *Subject: *rdfs:class versus owl:class in SOSA-Core
> >>>
> >>> Hi,
> >>>
> >>> Sorry for being so picky about this during our meeting but I do not
> >>> want us to take decisions that have consequences that we can not yet
> foresee.
> >>>
> >>> To the best of my knowledge (and please correct me if I am wrong):
> >>>
> >>> Under the semantics of OWL1, rdfs:class and owl:class are only
> >>> equivalent for OWL-Full. For OWL-DL (and OWL-Lite) owl:class is a
> >>> subclass of rdfs:class.
> >>>
> >>> This means that every valid document in OWL will be a valid document
> >>> in RDFS, however *not* every rdfs:class is an owl:class. I do not
> >>> want us to end up in OWL-Full because of this.
> >>>
> >>> For OWL2, I found this: 'owl:Class rdfs:subClassOf rdfs:Class . "
> >>> (https://www.w3.org/TR/owl2-rdf-based-semantics/). Things may be
> >>> more complicated here due to OWL2 punning and they may well turn out
> >>> to be equivalent, I will check this later.
> >>>
> >>> If we decide to restrict ourself to only using RDFS for SOSA-core,
> >>> and I am not in favor of this, then we may have to go with rdfs:class.
> >>> However, we have not yet taken this decision and have also not
> >>> discussed which axioms and language to use for SSN. As Sosa-core and
> >>> SSN will be aligned, this may have more consequences that we should
> >>> consider. It also seems like many of us are in favor of using
> >>> inverseOf, so we would be using OWL (and its formal semantics)
> >>> anyway. Note that this does not do any harm to an RDFS-only
> >>> tool/user as for those the inverseOf axiom will simply have no
> >>> formal semantics. Still all other triples that use both relations will
> still be just fine.
> >>>
> >>> Given the subclasssing, I do not see any problems using owl:class,
> >>> but we may accidentally end up in OWL-full or with being
> >>> incompatible to the standards if we opt for rdfs:class. Again, I am
> happy to be corrected.
> >>> At least, I do not see harm in simply using owl:class.
> >>>
> >>> Finally, and from very pragmatic point of view: ontologies that are
> >>> under very heavy use such as the DBpedia ontology simply use
> >>> owl:class and I have not yet seen any issues or complaints about that.
> See, for
> >>> example, http://dbpedia.org/ontology/City "dbo:City    rdf:type
> >>> owl:Class ." The same is true for the goodrelations ontology and so
> >>> forth (but I admit that this is due to the more complex
> >>> axiomatization they use).
> >>>
> >>> I hope this will start a productive discussion.
> >>>
> >>> Thanks for reading,
> >>>
> >>> Krzysztof
> >>>
> >>
> >
> >
>
>
>
>
>
> --
>
> 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
>
>
>
>
>
> --
>
> 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
>
>
>
>
>
> --
>
> 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
>
>