Re: State of SSN: comment on namespaces and urls

A couple of nit picks - not sure they change anything - but:

1) if a namespace  http://beer.org/ns# is resolved, the IRI that resolves
is actually http://beer.org/ns <http://beer.org/ns#> (because the # is
invisible the to web - its a client side instruction to look inside the
"file"
2) http://beer.org/ns <http://beer.org/ns#>/  as a namespace may have an
ontology called anything, do we want http://beer.org/ns
<http://beer.org/ns#> http://beer.org/ns <http://beer.org/ns#>/ or
http://beer.org/ns <http://beer.org/ns#>/Ontology1 - I havent seen a good
argument for or against these, except that http://beer.org/ns
<http://beer.org/ns#>/Ontology1 allows for multiple ontologies
3) we can expect tools to try to resolve the namespace in the absence of
clues - IMHO we need to either make statement that the rdfs:isDefinedBy
must be followed or ensure such namespaces should _redirect_ to the
ontology - not be the IRI of the ontology file, in a specific serialisation
(i.e never import http://beer.org/ns <http://beer.org/ns#>.owl only
http://beer.org/ns <http://beer.org/ns#>)
4) "term IRIs" are not related to the file/ontology at all - they are
declared explicitly as a IRI (and locally abbreviated using a namespace)

IMHO the conclusions are:
1) OWL files must use explicit import statements and OWL tools must use
explicit content-negotiation
2) for everything else the client needs to follow rdfs:isDefinedBy
3) We should redirect all three possible patterns (namespace, namespace
stripped of trailing separator and explicitly names ontology IRI) to
appropriate resources.
4) The "lightweight" requirement means that clients asking for RDF model
(not the OWL model) - get the fully entailed minimal vocabulary with RDFS
model (this is the "list of entities in the simplest model we offer...)
5) so choice of Ontology IRI isnt much of an issue if we have sensible
content disposition


And the elephant left in the room is not the ontology IRI, is the term IRI
and what happens if you add axioms:

I think we need two patterns:

given some RDFS SOSA like:l
[sosa.rdf:]

sosa:Blob a rdfs:Class
rdfs:comment "a Blob is an entity with a measurable blobbiness"

sosa:blobbiness a rdfs:Property
meta:domainIncludes sosa:Blob
meta:rangeIncludes sosa:BlobbinessMeasure

sosa:BlobbinessMeasure a rdfs:Class .
sosa:Sensor a rdfs:Class .
sosa:sensedBy a rdfs:Property.

then
pattern 1) axioms consistent with SOSA definition


[ssn.owl:]
sosa:Blob
rdfs:subClass [ owl:onProperty sosa:blobbiness ;  owl:someValuesFrom
sosa:BlobbinessMeasure ]

(I dont think anyone has any issues with this pattern - where scope is
identical?)

2) axioms narrower that SOSA defintions

2a) the "Profile" pattern
[ssn.owl]
sosa:Blob
rdfs:subClass [ owl:onProperty sosa:blobbiness ;  owl:someValuesFrom
ssn:SensedBlobbiness ]

ssn:SensedBlobbiness a owl:Class;
    rdfs:sibClassOf sosa:BlobbinessMeasure;
    rdfs:subClass [ owl:onProperty sosa:sensedBy ;  owl:someValuesFrom
sosa:Sensor ]

2b) the "specialised pattern"
[ssn.owl]
ssn:Blob rdfs:subClassOf sosa:Blob ;
rdfs:subClass [ owl:onProperty sosa:blobbiness ;  owl:someValuesFrom
ssn:SensedBlobbiness ] .

ssn:SensedBlobbiness a owl:Class;
    rdfs:sibClassOf sosa:BlobbinessMeasure;
    rdfs:subClass [ owl:onProperty sosa:sensedBy ;  owl:someValuesFrom
sosa:Sensor ]

I for one think we are arguing about this choice, and I'm not sure we yet
have a cogent argument for or against each - instead we have conflated the
problem into (and hopefully now untangled) the issue of namespace and
subclassing mechanisms.

I'm sure there are implications for both models.

I would note, that prima facie:
* Option 2b allows renaming SOSA terms to keep the original SSN names, if
this is important
* Option 2b allows a single system to support multiple profiles, as they
will live in distinct namespaces
* Option 2a allows lightweight SOSA implementations to be treated as SSN
resources provided they stay within the SSN profile constraints. I think a
client could ingest a bunch of data and infer its compliance with SSN using
Option 2, but my feeling is that is not practical for large amounts of
data, and stops the exploitation of any SSN semantics at the service end.

Happy to be educated about what these choices really imply :-)

Rob

On Thu, 2 Feb 2017 at 03:18 Joshua Lieberman <jlieberman@tumblingwalls.com>
wrote:

Once we accept  that inclusion in a file or document is one of the few
means we have to indicate ontology membership for axioms, then a page at a
URL is one way to give that document more stability and authority. Using
the namespace of an RDF vocabulary as a URL to reference that vocabulary is
one approach, though that assigns meaning to the namespace that it doesn’t
originally possess. It would be clearer to use the IRI / URL of an RDF
dataset / named graph containing that vocabulary. Established practices, of
course, don’t need to make sense, so we should probably take both measures
(dataset and namespace) just to be accommodating and helpful.

—Josh

> On Feb 1, 2017, at 10:57 AM, Francois Daoust <fd@w3.org> wrote:
>
> Hi Kerry,
>
> Le 01/02/2017 à 03:11, Kerry Taylor a écrit :
> [...]
>> I believe the W3C often has no ontology sitting at a namespace uri, but
>> instead a list of entities in the namespace and some documentation. Can
>> Francois comment?
>
> I'm not sure what you call "a list of entities in the namespace and some
documentation". In the linked data era we're now in, people expect to be
able to dereference namespace uris and get meaningful information, meaning
an HTML page for humans, some RDF serialization for machines.
>
> That was not the case some years ago, but I think we typically publish
ontology files at namespace uris nowadays, possibly using content
negotiation so that people may see an HTML page, a Turtle serialization of
the ontology, etc. depending on the Accept HTTP header. That is the case
for the RDF, RDF Schema, OWL, Prov namespace URIs for instance.
>
> Francois.
>
>