Namespace for new built-ins

doerthe commented 5 years ago

Related to #11 and #18

If we decide to define our own built-ins, we need to agree on a namespace for that.

Here we discussed several questions:

Should we use the original namespace (https://www.w3.org/2000/10/swap/) or agree on a new one?

If we want to use the first, we need to find out who is responsible for that and ask permission, if we use the new one, we need to find the best prefix. Does anyone have experiences here? What did other groups do in similar situations?

If we agree on a new namespace, should we then also move the most important existing N3 predicates to this new namespace or keep them separated?

The main argument for one single name space is that it would be less confusing for the developer. But on the other hand it is never a really good idea to change namespaces for predicates which are already existing. What is your opinion here?

william-vw commented 5 years ago

My two cents:

Introducing a new namespace vs. keeping the SWAP namespace: in light of the new standardization effort, as well as the fact that the current (SWAP) namespace contains the date when it was defined (well, at least some date of significance), one could argue that introducing a freshly minted namespace could be suitable.

But, note that RDF, RDFS and OWL namespaces also contain dates and are still in use, and OWL2 even re-used the OWL namespace that was dated back at 2002. This is likely to avoid killing the application ecosystem by updating namespaces in case of major changes - this would require re-coding all existing applications with the updated namespaces.

Personally I see 3 options here:

Introduce a (1) new namespace for (2) all N3 builtins standardized by this CG (targeting the standardization of all existing builtins, and perhaps introduce new ones). This would require re-coding all applications that rely on N3 input, i.e., for processing the new IDs of existing built-ins.
Introduce a (1) new namespace for (2) only newly defined built-ins (i.e., introduced by this working group). This would introduce a grouping of builtins not along functionality (i.e., math, log, string, ..) but based on when they were defined (they will be functionally similar to existing builtins and also defined by a W3C effort). This seems artificial and adds unneeded hassle for developers to code N3 documents.
Re-use the (1) existing namespace for all built-ins. Personally this carries my favour since it does not require re-coding existing applications (they would simply be oblivious of newly defined builtins) and does not require developers to declare and use multiple namespaces for functionally similar N3 builtins.

gkellogg commented 5 years ago

Practice for both Working Groups and Community Groups, lately, has been to use http://www.w3.org/ns/, so the namespace http://www.w3.org/ns/n3# would be in keeping with that, and would be a natural place for people to work. Typically, this is where a namespace document, in a variety of different formats (HTML, TTL/N3) would go.

For example, see the following:

RubenVerborgh commented 5 years ago

Looping in @timbl: I suspect that you might have input regarding what namespace should be used for forthcoming N3 built-ins, and also how the write permissions to the existing https://www.w3.org/2000/10/swap/ should be regulated.

timbl commented 5 years ago

Yes... that is currently in CVS , but its history is captured in git on github. So one can use changed to linkeddata/swap to fix things. IOt could be picked up by a W3C group of some sort. Note IIRC theer were separate namespaces used for different sets of functions, like time, strings, etc

One could keep those namespaces fo those groups but make a new one fo completely different groups of predicates.

william-vw commented 3 years ago

@RubenVerborgh @timbl Would it be possible to get access to the CVS in order to update the namespace files?

timbl commented 3 years ago

True the current cwm namespaces contain the date -20 years ago - that was the style then so you didn't't have to ask permission and manage /ns .. but people found ns nice for later vocabs. We can update either with new terms -- they are all under the same W3C CVS system There is a copy for the swap space in github ... probably easier just to do a PR to the SWAP space and then get that mapped into the CVS

Happy to make a new ns/n3# space for new stuff.

timbl commented 3 years ago

I propose we create a directory in this rep w3c/N3/ns with in it w3c/N3/ns/n3.ttl

william-vw commented 3 years ago

@timbl thanks a lot for this. We have an N3 ns/ folder in our repo with the current namespace documents (log, math, etc.), adapted from their prior versions.

We have weekly Skype meetings on Monday - hopefully we can finally land on what namespaces to use. (I believe we agreed on re-using the old SWAP namespace - but I could be misremembering just because I favored that option :-)

william-vw commented 3 years ago

@timbl We have landed on using the prior SWAP namespaces for consistency and usability sake. Could you point towards the github repo with the swap space - that way we can do a PR with any updated NS documents when needed

gkellogg commented 3 years ago

I think it's here: https://github.com/linkeddata/swap

w3c / N3

Namespace for new built-ins #20