URL persistence vs modularisation
VladimirAlexiev opened this issue · comments
Modularisation of NIF moved a bunch of elements from the nif: namespace to the nif-ann: namespace. See "deprecated" in https://github.com/NLP2RDF/ontologies/blob/nif2.1/nif-core/nif-core.ttl.
Modularization is all nice, but have you considered the tons (megatons!) of NIF data already in existence? Is the word persistence in http://persistence.uni-leipzig.org/nlp2rdf/ontologies/nif-core# merely a charade?
I think this one change will prevent us in Multisensor from using NIF 2.1. I think that an overriding prioriy in NIF 2.1 must be backward compatibility.
Note: backward compatibility only starts with URL permanence. Other issues to consider are the consequences of making sub-classes and sub-properties. Economy of representation (number of triples) is an important consideration to keep NLP as RDF a feasible idea, and NIF 2 thought carefully about that. Injudicious use of sub-classes and sub-properties will force NIF users to abandon RDFS... or NIF itself.
Hi @VladimirAlexiev,
there was not so much renaming going on actually. Most of them are new properties and classes, so backwardscompatibility is not an issue. However, for the OLIA/pos tag/stem properties you are right. I talked to @neradis today and we came up with the following design:
- move most of nif-ann: properties and classes to nif-core again (the extra ontology file unneccessarily complicates things)
- create a module file for each NLP use case / layer:
https://github.com/NLP2RDF/ontologies/tree/nif2.1/nif-module
These are just drafts, I hope you get the main message. nif-pos.ttl is an exception in that it uses the nif-core namespace. - All other extensions, e.g. for sentiment should use a new namespace, e.g. nif-sent:opinion rdfs:range marl:Opinion
Do you agree with this?
Other issues to consider are the consequences of making sub-classes and sub-properties. Economy of representation (number of triples) is an important consideration to keep NLP as RDF a feasible idea, and NIF 2 thought carefully about that. Injudicious use of sub-classes and sub-properties will force NIF users to abandon RDFS... or NIF itself.
This issue is solved as well with the above-mentioned fix right?
Frankly, I'd prefer if you keep everything in a single namespace nif:
- what is the chance of prop/class name clashes across the modules? I think it's small because they're all developed by a compact community (coordinated), and speak about different things
- if you have multiple namespaces, users can easily be confused which one to use for a specific prop, unless they read it from a reference
- you can't register nif-ann: or nif-sent: on prefix.cc as it only takes lowercase letters
Can we take this as acid test: do you have some examples of prop name clashes across the proposed new namespaces?
As a minimum, keep the old props where they were (i.e. move all old annotation props where they were).
Eg in Multisensor we've already used nif:opinion
(though that's a small & unimportant part of our annotations, so we could switch to nif-sent:opinion
if need be). (BTW, there's NLP2RDF/specification#1 about nif:opinion
)
Sub-props and sub-classes is separate: #17
ok, valid arguments. see the solution proposed for #17
Do you also agree to merge nifs:Annotation from https://github.com/NLP2RDF/ontologies/blob/master/nif-core/nif-stanbol.ttl#L78 into nif-core and rename it AnnotationUnit ?
We really need the feature to express basic alternative annotations.
I've split this last question into #19.