Warning:
This wiki has been archived and is now read-only.

NamespaceIssue

From Spatial Data on the Web Working Group
Jump to: navigation, search

Back to Semantic_Sensor_Network_Ontology.

The discussion on this page has been superseded by Integration_Issue

Clarification for different/same Namespaces for SOSA/SSN

We have, in the subgroup, already decided on using two ontology files, one for SOSA and one for SSN each with its own IRI and a separate storage location (URL). That is just common practice on the Linked Data Web. Both options assume that. What we now need to decide on is the use of one (common) namespace or (at least two) different namespaces for SOSA and SSN. Using one (common) namespace would be a relatively new approach on the Linked Data Web, but it can be justified by our approach to modularizing the SSN ontology. How each of the two options work technically is also outlined below.

Three options in a nutshell

Let be the namespaces: 

@Prefix sosa: <http://www.w3.org/ns/sosa/> .
@Prefix ssn: <http://www.w3.org/ns/ssn/> .

We have three main options here:

  1. Two names and namespaces: SOSA and SSN.
    1. SOSA has IRI and location <http://www.w3.org/ns/sosa/>, and defines terms under the namespace sosa: .
    2. SSN has IRI and location <http://www.w3.org/ns/ssn/>. It imports SOSA, adds axioms to sosa: terms, and defines new terms under the namespace ssn:.
    3. Looking up the URI of a term redirects to the ontology where this term is defined, i.e., SOSA if the term is in the sosa: namespace, and SSN if the term is in the SSN namespace.
  2. One unified name and namespace: SOSA.
    1. SOSA-Core has IRI and location <http://www.w3.org/ns/sosa/CoreVocabulary>, and defines terms under the namespace sosa: .
    2. SOSA-Full has IRI and location <http://www.w3.org/ns/sosa/FullOntology>. It imports sosa:CoreVocabulary, adds axioms to sosa: terms, and defines new terms under the same namespace sosa:.
    3. Looking up the URI of a term redirects to the ontology where this term is defined, i.e., sosa:CoreVocabulary if the term is defined there, sosa:FullOntology otherwise.
  3. One unified name and namespace: SSN.
    1. SSN-Core has IRI and location <http://www.w3.org/ns/ssn/CoreVocabulary>, and defines terms under the namespace ssn: .
    2. SSN-Full has IRI and location <http://www.w3.org/ns/ssn/FullOntology>. It imports ssn:CoreVocabulary, adds axioms to ssn: terms, and defines new terms under the same namespace ssn:.
    3. Looking up the URI of a term redirects to the ontology where this term is defined, i.e., ssn:CoreVocabulary if the term is defined there, ssn:FullOntology otherwise.

Pro and cons

Selected arguments in the List Tread:

  1. Maxime, https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0450.html : If some of us are confused once or twice with these two different namespaces, how often do you think our end users will be confused  ? We are defining terms in one or the other namespace following some logic that the lambda users will not grab at first. This is the main reason why I strongly encourage the choice of a unique namespace, may it be SOSA or SSN. To me, semantics and redirection issues should be put aside for now, as

they are tiny technical questions with respect to the aforementioned usability issue.

  1. Simon, https://lists.w3.org/Archives/Public/public-sdw-wg/2016Nov/0051.html  : It always struck me that the 'N' part of SSN got left behind in what was delivered. And if we are now including samples and actuators, then the product will have drifted even further from the original intention. So it comes down to branding. I agree that SSN is a strong brand in the semantic web community. Mind you, O&M is a strong brand in the geospatial community, and in lots of operational services (though not as an 'ontology'). Since this is a joint OGC/W3C project, there is an opportunity to align the name with the product. That was why we chose one that reflected the contents, and did not preference either of the precedents. SO I would vote SOSA.
  2. Maxime, https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0055.html : a single namespace and a single name ("SSN or SOSA") demonstrates that the group is unified, whereas 2+ namespaces and 2+ names (SSN and SOSA) demonstrates the group is split in two. This is my impression and could the the impression of other people exterior to the group.
    1. Krzysztof, https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0066.html : I think this is really a misunderstanding of namespaces. The SDW will also use different namespaces and nobody would argue that we are not unified simply because TIME and SSN do not share a common namespace.
      1. Maxime, https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0070.html : TIME and SSN talk about different domains. They where introduced in different documents, by different people. That's a historic difference.
  3. Maxime Name-wise, as a user of the SSN ontology, I actually expect that the outcome of this group is a simplified SSN. The name "SSN" is known to me. So when I see there is now SOSA *and* SSN, I think the outcome of the group is twice as complex that it was before. This is discouraging.
    1. Krzysztof, https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0066.html : I absolutely disagree with this statement and I cannot follow your argumentation. The SOSA is something new, this has nothing to do with SSN being known. We are not taking SSN away in any. That said, the new SSN is going to be pretty different from the old SSN so maybe it is good to make this very clear in all possible ways we can.
  4. Maxime: Namespace-wise, as a user of the SSN ontology, I don't want to need to check whether a term uses the ssn prefix or the sosa prefix. Just think of how the OWL vocabulary works for a second. If you use owl:unionOf, then your ontology cannot be in OWL Lite. Yet, there is a single "owl" namespace. Would you have voted in favour of multiple "owl" namespaces such as "owl-lite:", "owl-dl", "owl-full" ? If that was the case, one would need to know the precise prefix for each term in the OWL vocabulary, which is very against usability.
  5. Maxime, https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0070.html : SSN and SOSA talk about the same domain. I strongly believe that using two different namespaces brings more confusion, and less usability, contrary to what has been said before. Let me just point to a recent email on this list [1]: "- Phil: What's the difference between sosa:hosts and sosa:attachedSystem ? Do we need both? - Jano: SOSA should not have an attachedSystem relation. Do you mean SSN?" If choosing what prefix should be used for ***:attachedSystem is even unclear to WG members that are highly involved such as Phil, how do you expect the lambda user not to be confused ?!?
  6. Phil, https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0085.html : Personally, [+1 for different namespaces]. This makes the distinction clear for anyone looking at instance data. If instance data only uses SOSA, there's no need to look at/consider SSN axioms. If there's just one namespace, you won't know from the instance data whether it was created with or without knowledge/use of the extra semantics.
  7. Maxime, https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0086.html : Suppose we use two namespaces sosa: and ssn:. You suggested to delete terms from ssn that already exist in sosa. This means there would not exist ssn:Sensor, but there would be a sosa:Sensor. Suppose there is a document somewhere with the following content: `ex:mysensor a sosa:Sensor` As the consumer of the instance data, how do I know if the publisher wanted to use the SOSA or the SSN-new entailment regime? ssn:Sensor does not exist anyways.
  8. Phil, https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0088.html : In the absence of any import statements in the instance data, if a dataset only uses SOSA, you know it *can* be interpreted without SSN axioms. If a dataset does use SSN terms, without declaring the import, that's a hint that the publisher is using the richer semantics.
  9. Krzysztof, https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0099.html : We anticipate a large user base for SOSA (substantially larger than (full) SSN). We want SOSA to be a recognizable product and end users will assume that they can refer to it by its own namespace, look up the namespace at prefix.cc., and so on (see also Josh's argument).
  10. Kerry, https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0102.html : Just to repeat myself, I would prefer divorce (ie failure) to doing ssn:Sensor subclassOf sosa: Sensor. And certainly should we agree they cannot be integrated, then I would totally support the idea of 2 namespaces as a hint that they have nothing to do with each other. E.g. ssn:Sensor and sosa: Sensor are truly independent concepts emerging from the same WD.
  11. Maxime, https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0105.html : given SSN will import SOSA, then it *will also* talk about actuators and sampling. Furthermore, because SSN adds axioms to e.g., sensors, and for completeness reasons, I would vote for SSN to include axioms for actuators and sampling. Hence I agree that SSN as a name might become too restrictive for an ontology where actuators and sampling became so much important. So to make it clear, I am still in favor of a single name and namespace. I could live with any mention of SSN being renamed "SOSA Full", and: (1) the new ssn namespace being dropped, (2) the old ssn namespace redirect to an ontology document that imports SSN full and defines alignment with sosa terms.
  12. Rob, https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0111.html : I think we are fine to have a namespace for SSN, and still use SOSA namespace in SSN, and add OWL axioms to reinfoirce SOSA descriptions. The distinct SSN namespace allows SSN to introduce addition terms (to handle name equivalence, actual subclass specialisations, terms not covered in SOSA). if we find a sosa: thing in instance data, we should know its consistent with SOSA semantics, and if we are fully aware we can use SSN axioms to validate it.
  13. Danh, https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0149.html : the publisher only can provide the potential semantics of the ontology or the data annotated with the ontologies, then, it’s up to the consumer to choose which semantics they would like to interpret the data. [...] the ontology can provide possible semantics (RDFS, OWL..), but, we have to take into consideration all possible interpretations in data consuming/data annotation phases (probably, best practices are needed for each scenarios of use). And don’t underestimate the community (Web developers or IoT developers) that assume simple semantics like RDF or RDFS, that’s why schema.org is so success.
  14. Krzysztof, https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0152.html : One key issue here is that there are certain things, like the selected reasoning capabilities, that are outside of our control. I guess the best way to address this is by providing as much detail as possible in the documentation and the ontology to make clear what our underlying assumptions were when we created SOSA/SSN.
  15. Kerry, https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0101.html : In my proposal https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Compromise_Proposal_6_made_by_Kerry_January_2017 *if there is just one namespace* you know exactly what semantics apply. As BOTH are simultaneously correct. That is because the semantics of the core, as defined descriptively , Is totally consistent with the semantics of full ssn, as defined axiomatically. If you want the "extra" semantics axiomatically (and also if you want more expressive ways of saying things) then you can import ssn and use some of the terms that are in extended ssn. If you have some instance data that was defined only via the core module then you can rdfs-reason with it as much as you like , or owl reason with it, and you won't get any problems. Every one of the owl entailments done with core semantics remains true when you transition to the full semantics as long as your instance data follows the descriptive semantics.
  16. Armin, https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0283.html : with one namespace, texttt{sosa:sensor} (assuming the sosa prefix refers to http://www.w3.org/ns/unify) would actually resolve to the SOSA URI. The problem arises only if in your paper you would want to refer to texttt{ssn:sensor} as it would always resolve to the SOSA URI (as the concept is introduced in the core). This can only be solved by reintroducing the Sensor concept in SSN and asserting equivalence to the Sensor concept in the unified namespace.
  17. Maxime, https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0240.html : 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, anddiscuss *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.
  18. Simon, https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0269.html : 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?
    1. Krzysztof, https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0272.html : [+1, add branding], i.e., a clear signal that SOSA is usable on its own.
    2. Krzysztof, https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0272.html : 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.
      1. Maxime : this reverses the problem. I we use two namespaces and I talk about sosa:Sensor, then I will not be able to immediately know that I am using the SSN semantics.
  19. Kerry, https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0278.html :
    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.

Implementation Options for different/same Namespaces for SOSA/SSN

Below clarifies the technicalities in using different namespaces or using the same namespace for SOSA and SSN.

Aspects to consider (these are separate, and but related through implementation choices): 1) Namespace 2) Ontology 3) MIME/content-type (serialisation)

The Internet Media Type / MIME Type for the OWL XML Serialization is application/owl+xml. (https://www.w3.org/TR/owl2-xml-serialization/) but previous recommendations were to use RDF.

Note that the namespace is not necessarily the same as the ontology URI and resolving the namespace to the ontology requires a redirection to allow the client to know if its the same response as directly resolving an import.


Option 1: Different namespaces (current implementation)

Namespaces are assumed to be: 

@Prefix sosa: <http://www.w3.org/ns/sosa/> .
@Prefix ssn: <http://www.w3.org/ns/ssn/> .


SOSA ontology

Ontology IRI: http://www.w3.org/ns/sosa/

If you type the IRI http://www.w3.org/ns/sosa/ in your browser: 

Req:
GET /ns/sosa/
Host: www.w3.org
Accept: text/html

Res:
some documentation, or redirection to a global documentation ?

If you request text/turtle: 

Req:
GET /ns/sosa/
Host: www.w3.org
Accept: text/turle

Res:
200 OK (potentially 406 Not Acceptable depending on the Accept request header)
Content-Type: text/turtle
Content-Disposition: filename= downloadedSOSAFileName.ttl;

### content of sosa.ttl
@prefix sosa: <http://www.w3.org/ns/sosa/> .
 ... 

sosa: rdf:type owl:Ontology ;
  ...

sosa:Platform rdf:type owl:Class ;
  ...

If you request application/rdf+xml: 

Req:
GET /ns/sosa/
Host: www.w3.org
Accept: application/rdf+xml

Res:
200 OK (potentially 406 Not Acceptable depending on the Accept request header)
Content-Type: application/rdf+xml
Content-Disposition: filename= downloadedSOSAFileName.rdf;

Payload: RDF/XML equivalent of sosa.ttl

HTTP Response Header Content-Disposition is a hint for the browser on how to name the file in case it needs to download it: downloadedSOSAFileName.ttl or downloadedSOSAFileName.rdf. In the absence of this Response Header, the downloaded file name usually resolves to the last bit of the path in the URI --> empty string in http://www.w3.org/ns/sosa/.


SSN ontology

Ontology IRI: http://www.w3.org/ns/ssn/

If you type the IRI http://www.w3.org/ns/ssn/ in your browser: 

Req:
GET /ns/ssn/
Host: www.w3.org
Accept: text/html

Res:
some documentation, or redirection to a global documentation ?

If you request text/turtle: 

Req:
GET /ns/ssn/
Host: www.w3.org
Accept: text/turle

Res:
200 OK (potentially 406 Not Acceptable depending on the Accept request header)
Content-Type: text/turtle
Content-Disposition: filename= downloadedSSNFileName.ttl;

### content of ssn.ttl
@prefix ssn: <http://www.w3.org/ns/ssn/> .
@prefix sosa: <http://www.w3.org/ns/sosa/> .

ssn: rdf:type owl:Ontology ;
  owl:imports sosa: ;
  ...

sosa:Platform rdf:type owl:Class ;
  rdfs:subClassOf [ rdf:type owl:Restriction ;
  owl:onProperty sosa:hosts ;
  owl:allValuesFrom ssn:System
 ], ...

ssn:System rdf:type owl:Class ;
...

If you request application/rdf+xml: 

Req:
GET /ns/ssn/
Host: www.w3.org
Accept: application/rdf+xml

Res:
200 OK (potentially 406 Not Acceptable depending on the Accept request header)
Content-Type: application/rdf+xml
Content-Disposition: filename= downloadedSSNFileName.rdf;

Payload: RDF/XML equivalent of ssn.ttl

HTTP Response Header Content-Disposition is a hint for the browser on how to name the file in case it needs to download it: downloadedSOSAFileName.ttl or downloadedSOSAFileName.rdf. In the absence of this Response Header, the downloaded file name usually resolves to the last bit of the path in the URI --> empty string in http://www.w3.org/ns/ssn/.


Terms

If you directly access http://www.w3.org/ns/sosa/Platform, or any of the terms defined under the sosa namespace: 

Req:
GET /ns/sosa/Platform
Host: www.w3.org
Accept: */*

Res:
303 See Other
Location: http://www.w3.org/ns/sosa/

If you directly access http://www.w3.org/ns/ssn/System, or any of the terms defined under the ssn namespace: 

Req:
GET /ns/ssn/System
Host: www.w3.org
Accept: */*

Res:
303 See Other
Location: http://www.w3.org/ns/ssn/


Option 2: One namespace

This approach has been proposed in:

Maxime Lefrançois, Jarmo Kalaoja, Takoua Ghariani, Antoine Zimmermann, The SEAS Knowledge Model, ITEA2 12004 Smart Energy Aware Systems Deliverable 2.2, Jan 2017.

COMMENT: (Kerry) The explanation below is a little over-complex. We do not need 3 prefixes. To simplify - the key point is that you can have 2 different ontologies at 2 different URIs both using the same namespace for terms in each and yet each term gets resolved to the 1 ontology to which it belongs.

Namespace is assumed to be: 

@Prefix unify: <http://www.w3.org/ns/unify/> .

with unify equal to ssn or sosa.

SOSA ontology

Ontology IRI: http://www.w3.org/ns/unify/localSosaOntologyName

If you type the IRI http://www.w3.org/ns/unify/localSosaOntologyName in your browser: 

Req:
GET /ns/unify/localSosaOntologyName
Host: www.w3.org
Accept: text/html

Res:
some documentation, or redirection to a global documentation ?


If you request text/turtle: 

Req:
GET /ns/unify/localSosaOntologyName
Host: www.w3.org
Accept: text/turle

Res:
200 OK (potentially 406 Not Acceptable depending on the Accept request header)
Content-Type: text/turtle
Content-Disposition: filename= downloadedSOSAFileName.ttl;

### content of sosa.ttl
@Prefix unify: <http://www.w3.org/ns/unify/> .
...

unify:localSosaOntologyName rdf:type owl:Ontology ;
  ...

unify:Platform rdf:type owl:Class ;
  ...

If you request application/rdf+xml: 

Req:
GET /ns/unify/localSosaOntologyName
Host: www.w3.org
Accept: application/rdf+xml

Res:
200 OK (potentially 406 Not Acceptable depending on the Accept request header)
Content-Type: application/rdf+xml
Content-Disposition: filename= downloadedSOSAFileName.rdf;

Payload: RDF/XML equivalent of sosa.ttl

HTTP Response Header Content-Disposition is a hint for the browser on how to name the file in case it needs to download it: downloadedSOSAFileName.ttl or downloadedSOSAFileName.rdf. In the absence of this Response Header, the downloaded file name usually resolves to the last bit of the path in the URI --> just "localSosaOntologyName".


SSN ontology


Ontology IRI: http://www.w3.org/ns/unify/localSSNOntologyName

If you type the IRI http://www.w3.org/ns/unify/localSSNOntologyName in your browser: 

Req:
GET /ns/unify/localSSNOntologyName
Host: www.w3.org
Accept: text/html

Res:
some documentation, or redirection to a global documentation ?

If you request text/turtle: 

Req:
GET /ns/unify/localSSNOntologyName
Host: www.w3.org
Accept: text/turle

Res:
200 OK (potentially 406 Not Acceptable depending on the Accept request header)
Content-Type: text/turtle
Content-Disposition: filename= downloadedSSNFileName.ttl;

### content of ssn.ttl
@prefix unify: <http://www.w3.org/ns/unify/> .

unify:localSSNOntologyName rdf:type owl:Ontology ;
  owl:imports unify:localSosaOntologyName ;
  ...

unify:Platform 
  rdfs:subClassOf [ rdf:type owl:Restriction ;
  owl:onProperty unify:hosts ;
  owl:allValuesFrom unify:System
 ], ...

unify:System rdf:type owl:Class ;
...

If you request application/rdf+xml: 

Req:
GET /ns/unify/localSSNOntologyName
Host: www.w3.org
Accept: application/rdf+xml

Res:
200 OK (potentially 406 Not Acceptable depending on the Accept request header)
Content-Type: application/rdf+xml
Content-Disposition: filename= downloadedSSNFileName.rdf;

Payload: RDF/XML equivalent of ssn.ttl

HTTP Response Header Content-Disposition is a hint for the browser on how to name the file in case it needs to download it: downloadedSSNFileName.ttl or downloadedSSNFileName.rdf. In the absence of this Response Header, the downloaded file name usually resolves to the last bit of the path in the URI --> just "localSSNOntologyName".


Terms

If you directly access http://www.w3.org/ns/unify/Platform, or any of the terms defined defined in the sosa ontology: 

Req:
GET /ns/unify/Platform
Host: www.w3.org
Accept: */*

Res:
303 See Also
Location: http://www.w3.org/ns/unify/localSosaOntologyName

If you directly access http://www.w3.org/ns/unify/System, or any of the terms defined defined in the ssn ontology: 

Req:
GET /ns/unify/System
Host: www.w3.org
Accept: */*

Res:
303 See Also
Location: http://www.w3.org/ns/unify/localSSNOntologyName

Retrieved from "https://www.w3.org/2015/spatial/wiki/index.php?title=NamespaceIssue&oldid=3627"