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

Hi Rob,

We just voted for using both owl:class and rdfs:class (and for using
owl:inverseOf).

Best,
Krzysztof


On Tue, Nov 15, 2016 at 1:11 PM, Rob Atkinson <rob@metalinkage.com.au>
wrote:

>
> I though perhaps we had put this to bed (or sleep) - but there does seem
> to be a nuance here - the difference between reasoning within SOSA, and the
> use of SOSA within a domain where some form of reasoning is expected.
>
> I would have thought that the rationale for _including_ RDFS (irrespective
> of whether we model in OWL) would be to allow a user community to define
> specialised classes of sensors, actuators etc and user RDFS class based
> reasoning. I think all they need is for the rdfs:Class and rdf:Property etc
> typing to be explicit, and this is a low burden. I think the OMG there's
> OWL (OTO) factor can be addressed by including appropriate comments in the
> metadata for the ontology itself.
>
> Leaving us free to have owl based semantics embedded (effectively as
> documentation for many users) and an extra OWL module that imports these
> where we say to people - if you want to reason with OWL use all this extra
> stuff. The OWL can be part of the normative specification, but not
> necessary to refer to the SOSA concepts.
>
> Rob
>
>
>
>
> On Wed, 16 Nov 2016 at 07:14 Krzysztof Janowicz <jano@geog.ucsb.edu>
> wrote:
>
>> I see your point, but 'expectations' are best handled by providing clear
>> documentation and examples, not by some kind of 'preemptive obedience'
>> (assuming this is a good translation for the German 'Vorauseilender
>> Gehorsam').
>>
>> Best,
>> Krzysztof
>>
>> On Sat, Nov 12, 2016 at 9:46 PM, Kerry Taylor <kerry.taylor@anu.edu.au>
>> wrote:
>>
>> 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]
>> *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
>>
>>
>>