search

covjson / specification

CoverageJSON specification
https://covjson.org/spec/
45 stars 6 forks source link

Decide on covjson.org namespaces #69

Closed letmaik closed 8 years ago

letmaik commented 8 years ago

Since we have covjson.org now, we should finalize the namespace URLs that we want to use.

Some things to consider:

What namespaces do we need?

jonblower commented 8 years ago

Regarding the difference between core# and core/#, I really don't know. I also think that core# would follow common practice more. Maybe the SDWWG could offer advice?

That looks like a reasonable set of namespaces. How many items will there be in each namespace? I have seen small vocabularies (and even some large ones) served from a single namespace, which could possibly be refactored. There is probably a balance between logical refactoring and not having too many namespaces that could be confused.

letmaik commented 8 years ago

Hmm, I guess the way we want to use it in one covjson document (where each term is unique as identifier within that document) it could make sense to group core, dataTypes, and domainTypes into a single namespace. But then that would mean that the dataTypes also have to be lowercase in their URIs which they currently are not. so there's http://covjson.org/def/dataTypes#Polygon and http://covjson.org/def/domainTypes#Polygon where the former is aliased as "polygon" in the covjson. Not sure if lowercase rdf terms are popular for non-property terms. In this case it would be the object of the subject-predicate-object triple. On the other hand, there's the primitive xsd data types which are lower case, but they are a bit different since those are the actual data types of an rdf string.

jonblower commented 8 years ago

Do you think that "dataTypes#Polygon" is sort of semantically equivalent to an RDF data type (e.g. "[[..][..]]"^^covjson:polygon)? If so maybe lower case is fine, and consistent with RDF practice. Not sure.

letmaik commented 8 years ago

Interesting thought, given that the nested array structure for a polygon would have to be transformed to a string anyway when converting it to RDF, like a WKT encoding or similar as in GeoDCAT-AP. So from that point of view you could regard it as an RDF data type. If there's a common practice to have these lower case, probably not. I just found rdf:PlainLiteral as a counter example. I think typically lower-case is meant for predicates.

I think a solution to this would be to group core, dataTypes, and profiles into the main namespace, and have domainTypes as separate one. I think this makes most sense since domain types are always optional and clients can still understand most of the document if they are generic enough, whereas if they don't understand a given data type, then they are lost. And introducing new data types should happen very very rarely, compared to the domain types, where the latter would then live in an open registry and will be easier to extend.

So, how about:

http://covjson.org/def/core# containing:

http://covjson.org/def/domainTypes# containing:

Reused from external vocabularies:

where...

jonblower commented 8 years ago

Yes, that plan sounds reasonable.

letmaik commented 8 years ago

I was just integrating the namespaces into the JS library and found it very inconvenient to have the axis data types with different casing between the URI and JSON version. I think we should unify that so that clients can be written simpler and don't have to include those explicit mappings (but just adding one of two namespace URIs in front of the names). So, I think making the URI version lower-case as well doesn't really hurt.

letmaik commented 8 years ago

By the way, I found out that it is actually possibly to serve URLs without trailing slashes via GitHub Pages. So the namespace URLs we defined above would not need to redirect to /def/core/ from /def/core etc. (Hint: don't use permalink in the frontmatter in Jekyll)