NIF 1.0 in a nutshell

\r\n\t
1. Structural Interoperability : URI recipes are used to anchor annotations in documents with the help of fragment identifiers. The URI recipes are complemented by two ontologies (String Ontology and Structured Sentence Ontology), which are used to describe the basic types of these URIs (i.e. String, Document, Word, Sentence) as well as the relations between them (subString, superString, nextWord, previousWord, etc.).
\r\n\t
2. Conceptual Interoperability: The Structured Sentence Ontology (SSO) was especially developed to connect existing ontologies with the String Ontology and thus attach common annotations to the text fragment URIs. The NIF ontology can easily be extended and integrates several NLP ontologies such as OLiA for the morpho-syntactical NLP domains, the SCMS Vocabulary and DBpedia for entity linking, as well as the NERD Ontology (below for details on the ontologies).
\r\n\t
3. Access Interoperability: A REST interface description for NIF components and web services allows NLP tools to interact on a programmatic level.
\r\n

Architecture Overview

Structural Interoperability

NIF-1.0 URI Recipes

NIF specifies how to create an identifier for uniquely locating arbitrary substrings in a document.

General

\r\n\t
1. As NIF is designed to have a client server architecture, the client must be able to dictate the prefix to the server. All components must therefore have a parameter prefix which determines how the produced NIF URIs will start.
\r\n\t
2. The NIF-URIs should be produced by a concatenation of the prefix and the identifier.
\r\n\t
3. The NIF component must use the prefix of the client transparently without any corrections.
\r\n\t
4. (non-normative) For practical reasons, it is recommended that the client uses a prefix that ends on # or /
\r\n

\r\n\t
• Option 1: http://www.w3.org/DesignIssues/LinkedData.html/
\r\n\t
• Option 2: http://www.w3.org/DesignIssues/LinkedData.html#
\r\n

NIF Recipe: Offset-based URIs

NOTE: This recipe is compatible with the position and range definition of RFC 5147 (Especially Section 2.1.1 ) and builds upon it in terms of encoding and counting character positions. The syntax and everything else is different though. See the design choice section for a discussion.

\r\n\t
1. an identifier, in this case the string \"offset\"
\r\n\t
2. the begin index
\r\n\t
3. the end index (The indexes are counting the gaps between characters starting with 0)
\r\n\t
4. a human readable part consisting of the first 20 (or less, if the string is shorter) characters of the addressed string, urlencoded according to RFC 3986 (using '%20' instead of '+' for white space).
\r\n

\r\nString first20Chars =  (anchoredPart.length() < 20) ? anchoredPart.substring(0, 20) : anchoredPart ;\r\nString prefix = \"http://www.w3.org/DesignIssues/LinkedData.html#\"\r\nString uri;\r\n//variant A\r\nuri = prefix + URLEncoder.encode(first20Chars , \"UTF-8\").replaceAll(\"\\+\",\"%20\");\r\n//variant B\r\nURI uri = new URI(\"http\", \"www.w3.org\",\"/DesignIssues/LinkedData.html\",first20Chars);\r\nuri = uri.toASCIIString();\r\n

\r\n$prefix = \"http://www.w3.org/DesignIssues/LinkedData.html#\"\r\n$uri = $prefix.rawurlencode(substr($anchoredPart,0,20)\r\n

NIF Recipe: Context-Hash-based URIs

\r\n\t
1. an identifier, in this case the string \"hash\"
\r\n\t
2. the context length (number of character to the left and right used in the message for the hash-digest)
\r\n\t
3. the overall length of the addressed string
\r\n\t
4. the message digest, a 32 character HEXDIGIT md5 hash created of the string and the context. The message M consists of a certain number C of characters (see 2. context length above) to the left of the string, a bracket '(', the string itself, another bracket ')' and C characters to the right of the string: \"leftContext(String)rightContext\"
\r\n\t
5. a human readable part consisting of the first 20 (or less, if the string is shorter) characters of the addressed string, urlencoded according to RFC 3986 (using '%20' instead of '+' for white space).
\r\n

md5(\" it (Semantic Web).\r\n\r\nThe resulting URI is this:\r\nhttp://www.w3.org/DesignIssues/LinkedData.html#hash_4_12_79edde636fac847c006605f82d4c5c4d_Semantic%20Web\r\n\r\n\r\n\r\n\r\n
String Ontology
\r\nThe String Ontology is a vocabulary to describe Strings and builds the foundation for the NLP Interchange Format. It has a class String and a property anchorOf to anchor URIs in a given text and describe the relations between these string URIs. The ontology can be found here: http://nlp2rdf.lod2.eu/schema/string/\r\n\r\nThe available properties are descriptive. Only some properties are actually required for NIF, all others are optional and it is even discouraged to use them per default as they will cause quite a high amount of logical assertions (there are many transitive properties). Overall, only these terms are primarily important:\r\n
\r\n\t
http://nlp2rdf.lod2.eu/schema/string/OffsetBasedString
\r\n\t
http://nlp2rdf.lod2.eu/schema/string/ContextHashBasedString
\r\n\t
http://nlp2rdf.lod2.eu/schema/string/Document
\r\n\t
http://nlp2rdf.lod2.eu/schema/string/anchorOf
\r\n\t
http://nlp2rdf.lod2.eu/schema/string/subString
\r\n
\r\n\r\n
Structured Sentence Ontology
\r\nThe Structured Sentence Ontology (SSO) is built upon the String Ontology and additionally provides classes for three basic units: Sentences, Phrases and Words. Properties such as sso:nextWord and sso:previousWord can be used to express the relations between these units. Furthermore properties are provided for the most common annotations such as the  data type properties for stem, lemma, statistics, etc. The ontology can be found here: http://nlp2rdf.lod2.eu/schema/sso/\r\n\r\n
Normative requirements
\r\nThe URI recipes of NIF are designed to make it possible to have zero overhead and only use one triple per annotation, such as in the following example:\r\n
@prefix ld:  .\r\n@prefix str:  .\r\n@prefix revyu:  .\r\nld:offset_14406_14418_Semantic%20Web rev:hasComment \"Hey Tim, good idea that Semantic Web!\" . 
\r\n\r\nSome additional triples are added, however, to ease programmatic access. \r\n\r\n
1. All URIs created by the above-mentioned URI recipes should be typed with the respective OWL Class for the recipe (str:OffsetBasedString or str:ContextHashBasedString)
\r\nThis produces one additional triple per generated URI:\r\n\r\n
@prefix ld:  .\r\n@prefix str:  .\r\n@prefix revyu:  .\r\nld:offset_14406_14418_Semantic%20Web rev:hasComment \"Hey Tim, good idea that Semantic Web!\" . \r\nld:offset_14406_14418_Semantic%20web rdf:type str:OffsetBasedString . \r\n
\r\n\r\n
2. In each returned NIF model there should be at least one uri that relates to the document as a whole and either references the page with the property str:sourceUrl or includes the whole text of the document with str:sourceString
\r\nThe definition of Document in NIF is closely tied to the request issued to annotate it. So each piece of text that is sent to a service is treated as a document. This produces three additional triples per Document (or request).\r\n\r\n
@prefix ld:  .\r\n@prefix str:  .\r\nld:offset_0_25482_%3Chtml%20xmlns%3D%22http%3A%2F%2F rdf:type str:OffsetBasedString . \r\nld:offset_0_25482_%3Chtml%20xmlns%3D%22http%3A%2F%2F rdf:type str:Document . \r\nld:offset_0_25482_%3Chtml%20xmlns%3D%22http%3A%2F%2F str:sourceUrl  . \r\n
\r\n\r\n
3. For each document in a NIF model all other strings, that use NIF URIs should be reachable via the subStringTrans property by inference. Either str:subString must be used for this or a sub property thereof
\r\nProgramatically, it might be required to iterate over the strings contained in the document. This means that they have to be connected via a property. To achieve this requirement, either str:subString must be added between the URIs (where appropiate) or another property that is ardfs:subPropertyOf str:subString . Example of such sub properties are sso:word, sso:firstWord, sso:lastWord, sso:child.\r\n\r\n\r\n
@prefix ld:  .\r\n@prefix str:  .\r\nld:offset_0_25482_%3Chtml%20xmlns%3D%22http%3A%2F%2F rdf:type str:Document . \r\nld:offset_0_25482_%3Chtml%20xmlns%3D%22http%3A%2F%2F str:subString ld:offset_14406_14418_Semantic%20web \r\n
\r\n\r\n
Design Choices and Future Work
\r\nThis section explains the rationale behind the design choices of this section. Discussion and proposals are vital and possible via the comment section below or as written on the Get Involved page.\r\n
\r\n        
The additional brackets \"(\" and \")\" in the Context-Hash-based URIs were introduced to make the hash more distinguishable. If there is a sentence \"The dog barks.\" and the contxt size is too big, i.e. 10, then \"The\", \"dog\" and \"barks\" would have the same hash. Compare md5(\"The dog barks.\") vs. md5(\"The (dog) barks.\") vs. md5(\"The dog (barks).\")
\r\n        
Note that Context-Hash-based URIs are unique identifiers of a specific string only if the context size is chosen sufficiently large. If a, for example, complete sentence is repeated in the document, parts of the preceding and/or subsequent sentences are to be included to make the reference to the string unique. However, in many NLP applications, a unique reference to a specific strings is not necessary, but rather, all word forms within the same minimal context (e.g., one preceding and one following word) are required to be analysed in the same way. Then, a Context-Hash-based URI refers uniquely to a word class, not one specific string. Using a small context, a programmer can therefore refer to a whole class of words rather than an individual word, e.g., she can assign every occurring string \u00E2\u0080\u009Cthe\u00E2\u0080\u009C (with one preceding and one following white space as context) the part-of-speech tag \u00E2\u0080\u009CDT\u00E2\u0080\u009D: md5(\u00E2\u0080\u009C (the) \u00E2\u0080\u009C); The resulting URI is http://www.w3.org/DesignIssues/LinkedData.html#hash_md5_1_5_8dc0d6c8afa469c52ac4981011b3f582_the\u00E2\u0080\u009D
\r\n\t
The two ontologies should not be included into the NIF output per default (via owl:import). Some axioms will produce a lot of entailed triples, especially the transitive properties. It is generally better to just write some additional client code to add the required annotations, such as nextWordTrans or sub and superString than inferring them by a reasoner such as Pellet. SPARQL CONSTRUCT is the way to go in this case.\r\n
CONSTRUCT {?word1 sso:nextWordTrans ?word2} \r\nWHERE {?word1 sso:nextWord ?word2};
\r\nexecuted once and\r\n
CONSTRUCT {?word1 sso:nextWordTrans ?word2} \r\nWHERE {?word1 sso:nextWordTrans ?word2};
\r\nexecuted N-1 times (N is the number of words of the longest sentence) might just serve the same purpose and will be a lot faster.
\r\n\t
At the moment only two URI Recipes were included, which operate on text in general. Text is defined as either a sequence of characters or simply everything that can be opened in a text editor. This also entails that HTML, XML, Source Code, CSS and everything else (except e.g. binary formats) can be addressed with NIF-URIs. This is the most general use case and in the future more content-specific URI Recipes such as XPath/XPointer for XML might be included.
\r\n\t
The explicit typing of the URIs with the class OffsetBasedString is useful for determining the type of the URI and before parsing it. Of course, the explicit typing is redundant, because the information is already included in the URI. This redundancy might be removed in the future.
\r\n
The compatibility problem RFC 5147 originates in the dilemma that normally fragment ids of URIs are media-type specific. RFC 5147 is valid for plain text(i.e. text without markup), which is disjoint with html. Achieving full compatibility comes with additional (unnecessary) ballast, while providing hardly any advantages for NLP tools. See the full discussion here. Final email. 
\r\n
\r\n\r\n
Conceptual Interoperability
\r\nConceptual Interoperability is concerned with which ontologies and vocabularies are used to represent the actual annotations in RDF.  We divided the different output of tools into different NLP domains. For each domain a vocabulary was or will be chosen that serves the most common use cases and facilitates interoperability. In simple cases a property has been created in the Structured Sentence Ontology. In the more complex cases fully developed linguistic ontologies already existed and were reused.\r\nThis part of the specification is also extended on the fly, i.e. everything in this section is stable (backward-compatible), but additional NLP domains might be appended, any time. New NLP domains can be requested or proposed here.\r\n\r\n
Golden rule of conceptual interoperability
\r\nHere is the golden rule of interoperability with respect to a reference ontology:\r\n
Alongside the local annotations used by the tool, minimal information must be added to be able to disambiguate the local annotations with the help of a reference ontology for data integration and interoperability.
\r\n\r\n\r\n
NLP Domains
\r\n
Begin/end index and context
\r\nAdding extra triples for indexes and context produces redundant information as the begin and end index as well as the context can be calculated from the URI. Properties for describing context and begin and end index can be found in the String Ontology.\r\n
@prefix ld:  .\r\n@prefix str:  .\r\n@prefix xsd:  .\r\nld:offset_14406_14418_Semantic%20web str:beginIndex \"14406\"^^xsd:int  .\r\nld:offset_14406_14418_Semantic%20web str:endIndex \"14418\"^^xsd:int  .\r\nld:offset_14406_14418_Semantic%20web str:leftContext \" it \" .\r\nld:offset_14406_14418_Semantic%20web str:leftContext4 \" it \" .\r\nld:offset_14406_14418_Semantic%20web str:beginIndex \".\r\n
Lemmata, stems, stop words, etc. 
\r\nLemma and stem annotations are realized as simple data type properties in the Structured Sentence Ontology. \r\nA class is used for stopwords (sso:StopWord)\r\n
@prefix ld:  .\r\n@prefix sso:  .\r\nld:offset_14406_14414_Semantic sso:stem \"Semant\"  .\r\nld:offset_14406_14414_Semantic sso:lemma \"Semantic\"  .\r\nld:offset_14406_14414_Semantic a sso:StopWord  .\r\n
\r\n
Part of speech tags
\r\nAnnotations for part of speech tags must make use of  Ontologies of Linguistic Annotations (OLiA)  .\r\nOLiA connects local annotation tag sets with a global reference ontology. Therefore it allows to keep the specific part of speech tag at a fine granularity, while at the same time having a coarse grained reference model. The RDF output must contain the original tag as plain literal using the property sso:posTag as well as a link to the respective OLiA individual in the annotation model for the used tag set using the property sso:oliaLink. \r\n\r\nHere is an example using the Penn tag set:\r\n
@prefix ld:  .\r\n@prefix sso:  .\r\n@prefix penn:  .\r\nld:offset_14406_14414_Semantic sso:posTag \"JJ\"  .\r\nld:offset_14406_14414_Semantic sso:oliaLink penn:JJ  .\r\n
\r\n\r\nThe extended RDF output can additionally contain the following: 1. all classes of the OLiA reference ontology (especially from olia.owl and olia-top.owl) that belong to this individual can be copied and added to the str:String via rdf:type 2. the rdfs:subClassOf axioms between these classes must be copied as well.\r\nAll necessary information has to be copied for conciseness and self-containedness. If information is copied in this way it is unnecessary for the client to include the three OLiA reference ontologies: \r\nhttp://nachhalt.sfb632.uni-potsdam.de/owl/olia-top.owl, http://nachhalt.sfb632.uni-potsdam.de/owl/olia.owl, http://nachhalt.sfb632.uni-potsdam.de/owl/system.owl\r\nIn total, these three models amount to almost 1000 OWL classes.  An overview of OLiA can be found here. \r\n\r\n\r\nHere is an example of the extended output:\r\n
@prefix ld:  .\r\n@prefix sso:  .\r\n@prefix penn:  .\r\n@prefix olia-top:  .\r\n@prefix olia:  .\r\nld:offset_14406_14414_Semantic sso:posTag \"JJ\"  .\r\nld:offset_14406_14414_Semantic sso:oliaLink penn:JJ  .\r\nld:offset_14406_14414_Semantic rdf:type olia:Adjective .\r\nld:offset_14406_14414_Semantic rdf:type olia-top:MorphosyntacticCategory .\r\nld:offset_14406_14414_Semantic rdf:type olia-top:LinguisticConcept .\r\nolia:Adjective rdfs:subClassOf olia-top:MorphosyntacticCategory.\r\nolia-top:MorphosyntacticCategory rdfs:subClassOf olia-top:LinguisticConcept.\r\n
\r\n\r\n
Currently, there are some small disadvantages, which might be fixed in the next NIF version:\r\n
\r\n
The ontologies might still change a little now and then and are unversioned. In the next NIF version, we will provide stable releases.
\r\n
The semantics are not exactly modelled as instances of str:String are intuitively not instances of olia-top:LinguisticConcept. Normally you would model these classes as disjoint, but the amount of RDF triples is reduced the way it is currently done. Note that this saves an extra pattern in each SPARQL query. 
\r\n
Also for the sake of conciseness subClassOf axioms from OLiA are repeated. This might formally be considered as ontology highjacking. Again, it is more concise than importing 1000 OWL classes.
\r\n
\r\n 
\r\n \r\n
Syntax Analysis
\r\nin development\r\n\r\n
Topic Models
\r\nAn ontology draft for Topic models is available here:\r\nhttp://nlp2rdf.lod2.eu/schema/topic/\r\n
Named Entity Recognition and Entity Linking
\r\nFor describing Named Entity Recognition (NER),  NIF uses one property from the Semantic Content Management System (SCMS) EU project. \r\nFor entity linking, the property http://ns.aksw.org/scms/means must be used.\r\n
@prefix ld:  .\r\n@prefix scms:     .\r\n@prefix dbpedia:     .\r\nld:offset_22849_22852_W3C scms:means dbpedia:World_Wide_Web_Consortium .\r\n
\r\nFor entity typing the Named Entity Recognition and Disambiguation Ontology (http://nerd.eurecom.fr/ontology/) must be used alongside the local annotation types. \r\n\r\n\r\n\r\nHere are three examples for Spotlight, Zemanta and Extractiv to showcase how important a reference ontology is, even for such a trivial annotation as organization. Note the three different spellings \"Organisation\", \"organization\", \"ORGANIZATION\";\r\n\r\n
\r\n@prefix dbo:     .\r\n@prefix nerd:     .\r\nld:offset_22849_22852_W3C rdf:type dbo:Organisation .\r\nld:offset_22849_22852_W3C rdf:type nerd:Organization .\r\n
\r\n
\r\n@prefix zemanta:      .\r\n@prefix nerd:     .\r\nld:offset_22849_22852_W3C rdf:type zemanta:organization .\r\nld:offset_22849_22852_W3C rdf:type nerd:Organization .\r\n
\r\n
\r\n@prefix extractiv:     .\r\n@prefix nerd:     .\r\nld:offset_22849_22852_W3C rdf:type extractiv:ORGANIZATION .\r\nld:offset_22849_22852_W3C rdf:type nerd:Organization .\r\n
\r\n\r\n\r\n
Access Interoperability
\r\nMost aspects of access interoperability are already tackled by using the RDF standard. This section contains several smaller additions, which further improves interoperability and accessibility of NIF Components. They are normative, but play a minor importance compared to the Structural and Conceptual Interoperability. While the first two allow general interoperability, Access provides easier integration and off-the-shelf solutions.  \r\n\r\n
Workflow
\r\nNIF itself is a format, which can be used for import and export of data from and to  NLP tools. Therefore NIF enables to create ad-hoc workflows following a client-server model or the SOA principle. In this approach, the client is responsible for implementing the workflow. The diagram below shows the communication model. The client sends requests to the different tools either as text or RDF and then receives an answer in RDF. This RDF  can be aggregated into a local RDF model. Transparently, external data in RDF can also be requested and added without any additional formalism. For acquiring and merging external data from knowledge bases, the plentitude of existing RDF techniques (such as Linked Data or SPARQL) can be used.\r\n\r\n\r\n\r\n
Interfaces
\r\nCurrently the main interface is a wrapper that provides the NIF Web service. Other interfaces, such as CLI or a Java interface (using Jena) are easily possible and can be provided in addition to a Web service. The Web service must:\r\n
\r\n
be stateless
\r\n
treat POST and GET the same
\r\n
accept the parameters in the next section 
\r\n
\r\n\r\nThe component may have any number of additional parameters to configure and fine tune results. \r\n\r\n
Parameters
\r\nNote that to send the parameters to a Web service they must be url encoded first. \r\n\r\nThese parameters must be used for each request (required): \r\n
\r\n   
 input-type = \"text\" | \"nif-owl\"\r\nDetermines the content required for the next parameter input, either plain text or RDF/XML in NIF
\r\n   
input = text | rdf/xml\r\nEither the text or RDF in XML format in NIF 
\r\n
\r\n\r\nThese parameters can be used for each request (optional): \r\n
\r\n\t
 nif = \"true\" | \"nif-1.0\" \r\nIf the application already has a web service, use this parameter to enable NIF output (allows to develop NIF in parallel to existing output, legacy support). It is recommend for a client to always send this with each request.
\r\n\t
format = \"rdfxml\" | \"ntriples\" | \"turtle\" | \"n3\" |  \"json\" \r\nThe RDF serialisation format.  Standard RDF frameworks generally support all the different formats. 
\r\n\t
prefix = uriprefix \r\nA prefix, which is used to create any URIs. Therefore the client should ensure, that the prefix is valid, when used at the start of the uri, e.g. http://test.de/test#. If input-type=\"nif-owl\" was used, then the server must not change existing uris and only use the prefix when creating new URIs. It is recommended that the client matches the prefix to the previously used prefix.  If the parameter is missing it should be substituted by a sensible default (e.g. the web service uri). 
\r\n\t
urirecipe = \"offset\" | \"context-hash\" \r\nthe urirecipe that should be used (default is \"offset\")
\r\n    
context-length = integer \r\n     If the given uri recipe is context-hash, the client can determine the length of the context with it. The default must be 10. 
\r\n    
debug = \"true\" | \"false\"  This options determines, if additional debug messages and errors should be written within the RDF. See also the next Section.
\r\n\r\n
\r\n\r\n
Errors
\r\nFor easier debugging, errors and messages have to be written as RDF output. If a fatal error occurs (i.e. the component was unable to produce any output), the RDF output should contain a message using the underspecified error ontology provided by NLP2RDF: http://nlp2rdf.lod2.eu/schema/error/\r\nErrors can be given any URI or blank node, must be typed as error:Error, must specify whether they are fatal or not and must contain an error message. Here is an example:\r\n
\r\n@prefix error:     .\r\nld:error_1 rdf:type error:Error\r\nld:error_1 error:fatal \"1\"^^xsd:boolean .\r\nld:error_1 error:hasMessage  \"Wrong input parameter ..., could not parse ontology\" .\r\n
\r\n\r\nIf the debug parameter is set, the component is allowed to mix error messages with the RDF that contains the annotations:\r\n
\r\n@prefix error:     .\r\nld:error_1 rdf:type error:Error\r\nld:error_1 error:fatal \"0\"^^xsd:boolean .\r\nld:error_1 error:hasMessage  \" Sentence 5 and 6 had a low confidence value for sentence splitting. \" .\r\nld:error_2 rdf:type error:Error\r\nld:error_2 error:fatal \"0\"^^xsd:boolean .\r\nld:error_2 error:hasMessage  \"Could not add extended output for OLiA.\" .\r\n
\r\n\r\n\r\n\r\n" .
 "title" "Tutorials & Challenges" .
 "content" "The tutorials for NLP2RDF and NIF come in two flavours. The first tutorial type are simple code snippets and functional help (such as how to use NIF Webservices with Jena). The second tutorial types are called Tutorial Challenges. This means that at first they are NLP challenges posed by the community, but as soon as somebody provides a solution as a blog post, they will become tutorials, as the post should describe how the challenge has been solved.\r\n\r\nIf you think you can provide an interesting task and want to see how others are solving it, you can submit it to this page and then see how other people solved the problem.\r\nPlease have a look at the Get Involved page  to see how submission works.\r\n\r\n
Code Snippets
\r\n
\r\n\t
Tutorial: How to call a NIF web service with your favorite SemWeb library
\r\n
\r\n\r\n\r\n
Current unsolved challenges
\r\n
\r\n\t
Tutorial Challenge: Semantic Search
\r\n
Tutorial Challenge: Multilingual Part-Of-Speech Tagger
\r\n
Tutorial Challenge: Semantic Yellow Pages
\r\n
" .
 "title" "Get Involved" .
 "content" "The easiest way to get questions answered or to exchange ideas is the NLP2RDF mailing list. Please send an email to  (, subscribe per browser, archives). All feedback is welcome. The mailing list should also keep you in the loop about current discussions. The blog also has an RSS feed for all posts and also for each category.\r\n\r\nNormally, mailing list discussions contain a lot of useful information and thoughts, which are then lost in the mailing archives. This is why, we have a wiki at http://wiki.nlp2rdf.org, where we try to document and collect all important information. If you want to add something to the wiki please sign up. Registration is open." .
 "title" "Involved People" .
 "content" "This page lists the involved people and their contributions in the creation and adoption of NIF (this list is never complete, please email , if you are missing).\r\n
\r\n\t
Markus Ackermann created the Topic Ontology for Mallet
\r\n\t
S\u00F6ren Auer, LOD2
\r\n\t
Christian Chiarcos maintains the Ontologies of Linguistic Annotation
\r\n\t
Philipp Cimiano maintains lemon
\r\n\t
Key-Sun Choi,\u00A0 LOD2
\r\n\t
Sebastian Hellmann coordinates the project and implementation efforts
\r\n\t
Konrad H\u00F6ffner contributed a Tutorial Challenge: Semantic Yellow Pages
\r\n\t
Ali Khalili contributed a use case and maintains RDFaCE
\r\n\t
Artjom Klein implemented NIF wrappers for the bio domain
\r\n\t
Maxime Lefran\u00E7ois helps to develop the ITS2NIF2ITS brigde to ITS 2.0\u00A0
\r\n\t
Jens Lehmann, LOD2
\r\n\t
Pablo Mendes maintains DBpedia Spotlight
\r\n\t
John McCrae maintains lemon
\r\n\t
Axel Ngonga maintains FOX (demo)
\r\n\t
Mart\u00EDn Rezk
\r\n\t
Giuseppe Rizzo maintains the NERD Ontology
\r\n\t
Felix Sasaki helps to develop the ITS2NIF2ITS brigde to ITS 2.0 
\r\n\t
Tadej Stajner maintains Enrycher and helps to develop the ITS2NIF2ITS brigde to ITS 2.0 
\r\n\t
Raphael Troncy maintains the NERD Ontology
\r\n\t
Mateja Verlic, Zemanta
\r\n\t
Thanh Nghia Lam maintains the WiktionaryFirstSense
\r\n
\r\nWe especially thank all participants in the field test of NIF 1.0:\r\n
\r\n\t
Markus Ackermann\u00A0 for Mallet
\r\n\t
Martin Br\u00FCmmer for OpenNLP and for  UIMA 
\r\n\t
Didier Cherix for  Gate Annie 
\r\n\t
Marcus Nitzschke for MontyLingua (Python)
\r\n\t
Robert Schulze for DBpedia Spotlight (node-js)
\r\n
\r\nWe are adding all other people soon (LOD2, etc)" .
 "title" "Publications" .
 "content" "
Publications
\r\n
\r\n\t
Sebastian Hellmann and Claus Stadler and Jens Lehmann: The German DBpedia: A Sense Repository for Linking Entities - Linked Data in Linguistics in 2012. PDF
\r\n\t
Sebastian Hellmann and Jens Lehmann and S\u00C3\u00B6ren Auer: Linked-Data Aware URI Schemes for Referencing Text Fragments. - EKAW 2012 PDF
\r\n\t
S\u00C3\u00B6ren Auer and Sebastian Hellmann: The Web of Data: Decentralized, collaborative, interlinked and interoperable. - LREC, European Language Resources Association, 2012. PDF
\r\n\t
Giuseppe Rizzo and Rapha\u00C3\u00ABl Troncy and Sebastian Hellmann and Martin Bruemmer: NERD meets NIF: Lifting NLP extraction results to the linked data cloud. - LDOW, 5th Workshop on Linked Data on the Web, April 16, 2012, Lyon, France. PDF
\r\n\t
Christian Chiarcos and Sebastian Hellmann and Sebastian Nordhoff: Towards a linguistic\u00C2\u00A0 linked open data cloud: The open linguistics working group. -\u00C2\u00A0 Traitement automatique des langues (to appear). PDF
\r\n\t
Christian Chiarcos: A Generic Formalism to Represent Linguistic Corpora in RDF and OWL/DL. - 8th International Conference on Language Resources and Evaluation (LREC-2012). Istanbul, Turkey, May 2012. PDF
\r\n\t
Christian Chiarcos:\u00C2\u00A0Ontologies of linguistic annotation: Survey and perspectives.\u00C2\u00A0 - LREC, European Language Resources Association, 2012.\u00C2\u00A0 PDF
\r\n
\r\nPublications mentioning NLP2RDF and NIF are collected in the Wiki\r\n
Presentation and Slides
\r\nMissing:\r\nkeynote LREC 2012 by S\u00C3\u00B6ren, http://www.lrec-conf.org/lrec2012/?Keynote-Speeches-and-Invited-Talk\r\nLDOW2012 Giuseppe Rizzo http://events.linkeddata.org/ldow2012/\r\n
\r\n\t
June 2012, Sebastian Hellmann, at The Multilingual Web \u00E2\u0080\u0093 Linked Open Data and MultilingualWeb-LT Requirements, link to\u00C2\u00A0 slides
\r\n\t
May 2012, Sebastian Hellmann and S\u00C3\u00B6ren Auer, at Keynote Speeches and Invited Talk
\r\n\t
April 2012, Sebastian Hellmann , Giuseppe Rizzo, Raphael Troncy , Martin Bruemmer, at LDOW2012 Workshop, link to slides
\r\n\t
October 2011, Sebastian Hellmann, at Invited Talk at the Multilingual Semantic Web Workshop, ISWC 2012, link to slides
\r\n\t
September 2011, Sebastian Hellmann, at W3C Workshop Program: A Local Focus for the Multilingual Web, Limerick, link to slides
\r\n\t
September 2011, Sebastian Hellmann, at Indian-summer school on Linked Data, link to slides
\r\n\t
August 2011, Sebastian Hellmann, at Korea-Germany Joint Workshop for LOD2 Development and Application, link to slides
\r\n\t
June 2011, Christian Chiarcos: Modelling linguistic corpora and their annotations with OWL/DL , link to slides
\r\n
\r\n
EU Deliverables
\r\n
\r\n\t
\u00C2\u00A0Sebastian Hellmann 2011, LOD2 EU Deliverable D 3.2.1 - NLP2RDF
\r\n
\r\n" .
 "title" "Demo & Development" .
 "content" "This page links to all available documentation and demos. The \r\n\r\n\r\n
Links
\r\n
\r\n
There is a web demo and validator available (currently under development)
\t\r\n
A blog post (with Linked Data) about each known implementation can be found under the Category Implementations. Each implementation normally has a demo web service. For example the full Stanford Core NLP NIF output can be seen here:\r\n\"My favorite actress is Natalie Portman!\"
\r\n\t
Tutorials(for clients) can be found on this page, on the Tutorials & Challenges page. 
\r\n\t
Reusable Java code is available as open source in the . A readme file in the repository is explaining the basics.  
\r\n\t\r\n\r\n\r\n
\r\n\r\n\r\n\r\n\r\n
Checklist
\r\nThe checklist is separated in three parts. The first part states the minimal requirements, which allow basic interoperability. This allows for an initial low-effort integration. Then there is a further list for all requirements of NIF components. Note that there is a third list with things that are optional. Developers should look at this list especially, because it can help them to save some time. This list includes things, which might be provided by a central component or which just produce unnecessary triples.\r\n\r\n
Minimal requirements
\r\nThe NIF wrapper ...\r\n
\t\r\n   
takes text as input over some interface (CLI, Web Service, API )
 \r\n   
has implemented the parameter prefix
\r\n   
produces well-formed RDF output (no syntax errors, N3 or RDF/XML recommended)
\r\n   
produces RDF with Offset Based URIs
\r\n   
fulfils the normative requirements in the  Specification
\r\n   
fulfills the golden rule of conceptual interoperability
\r\n\r\n
\r\n\r\n
Remaining requirements
\r\nThe NIF wrapper ...\r\n
\r\n \t
provides a web service and complies to the Web service requirements and parameters
\r\n\t
has implemented the Context-hash Based URI recipe 
\r\n\t
can read NIF and load it into the internal data structure of the tool (e.g. read tokens for POS-Taggers or read POS-Tags from NIF for NER tools.)
\r\n
\r\n\r\n
Optional additions
\r\n
\r\n\t
the properties sso:nextWord, sso:nextSentence are just necessary for some use cases and should be omitted. The next/previous properties infer transitive properties, which increase reasoner work load. 
\r\n\t
 the properties str:beginIndex, str:leftContext duplicate the information contained in the uris and can be included for easier search.
\r\n\t
OLiA Classes and the hierarchy is copied as specified and included in the ourput. 
\r\n\r\n\r\n
\r\n\r\n\r\n
Maven
\r\n
Maven Dependencies
\r\nThe Maven archiva with the libraries. (Currently 1.1-SNAPSHOT is recommended)\r\nNIF Library and Ontology Bindings\r\nWeb Service\r\n\r\n
Maven Repository
\r\n
\r\n\r\n   maven.aksw.internal\r\n   University Leipzig, AKSW Maven2 Repository\r\n   http://maven.aksw.org/repository/internal\r\n\r\n\r\n   maven.aksw.snapshots\r\n   University Leipzig, AKSW Maven2 Repository\r\n   http://maven.aksw.org/repository/snapshots\r\n\r\n
\r\n\r\n
Validation of NIF Models
\r\n
OWL Validation
\r\nThe basic OWL syntax can be validated efficiently with these standard tools:\r\n
\r\n        
The OWL Validator
\r\n\t
The other OWL Validator
\r\n\t
Raptor RDF Syntax Library: for Ubuntu use sudo apt-get install libraptor2-0 and then rapper -i rdfxml myfile.owl 
\r\n\t
Load the file in Protege and look at it
\r\n\r\n
\r\n\r\n\r\n\r\n\r\n" .
 "title" "NIF 2.0 Draft" .
 "content" "Improvements upon NIF 1.0 will be collected and incorporated in NIF 2.0.\r\nPlease have a look at the Wiki, where we currently collect and discuss all issues:\r\nhttp://wiki.nlp2rdf.org/wiki/Category:Issues\r\n\r\nIf you want to Get Involved, sign up on the mailing list here:\r\nhttp://nlp2rdf.org/get-involved/\r\n\r\n " .
   .
  "implements some features of NIF-1.0, but: GET is missing, 'input-type' is 'type'" .
   .
   .
   .
  "Entity Linking" .
 "title" "FOX" .
 "content" "FOX participated in the initial field test before NIF 1.0 and has not yet been updated.\r\nIt is best to try the online demo of FOX at http://fox.aksw.org\r\n\r\nCurrently, FOX only allows POST so the API can not be called within the browser but only with curl:\r\n\r\ncurl\u00A0 http://139.18.2.164:4444/api -d \"type=TEXT&nif=TRUE&task=NER&output=TURTLE&text=My%20favorite%20actress%20is%20Natalie%20Portman!\"\r\n\r\n" .
   .
  "Reference Implementation for NIF 1.0 ." .
  "Other languages are available with: stemmer=PorterStemmer or stemmer=HungarianStemmer and others from:\u00A0 http://lucene.apache.org/java/2_4_0/api/contrib-snowball/index.html " .
   .
   .
   .
 "title" "SnowballStemmer" .
 "content" "According to the Get Involved page each blog post has to start with a short introduction:  I created this implementation to provide a reference implementation for NIF 1.0. \r\n\r\n\r\nThe SnowBall libraries provide basic implementations for stemming algorithms for a lot of languages.\u00A0 This NIF implementation encapsulates the stemmer.\r\n\r\n\r\n" .
   .
  "None" .
  "Reference Implementation for NIF 1.0 . Provides lemmas, POS tags and also (experimental) Syntax trees" .
   .
   .
   .
 "title" "Stanford CoreNLP" .
 "content" "According to the Get Involved page each blog post has to start with a short introduction:  I created this implementation to provide a reference implementation for NIF 1.0. \r\n\r\n\r\nStanfordCore is an NLP tool, that combines lemmatizing, POS-tags, dependency parsers and many more layers. The tool currently only produces NIF output, but might be extended to read NIF input as well. There is a Demo Web service available\r\n\r\n \r\n\r\n" .
 "title" "Tutorial Challenge: Multilingual Part-Of-Speech Tagger" .
 "content" "The goal of this challenge is straight-forward: An HTML page has one text area, where you can post a text. The language of the text should be detected and then the following should be highlighted: Verbs should be highlighted in green, Nouns in red, Adjectives in orange and Articles in yellow.The highlighting should work for 5-10 languages of your choice. (The choice of colour is of course not strict, but it has to be the same across languages).\r\n\r\nA mockup can be found here: http://nlp2rdf.lod2.eu/tutorial/mutlilingual-pos/mockup.php\r\n\r\nCode: http://nlp2rdf.lod2.eu/tutorial/mutlilingual-pos/mockup.txt\r\n\r\nSome suggestions of resources that can be used, i.e. you can use anything else:\r\n
\r\n\t
The connection between Stanford CoreNLP and OLiA is currently only implemented for the English pre-trained model and only for the Penn tag set.
\r\n\t
In some months, KAIST will produce a NIF adapter for a Korean POS tagger.
\r\n\t
Not all components required for this task have NIF adapters currently.
\r\n
" .
 "title" "Tutorial Challenge: Semantic Search" .
 "content" "According to the Get Involved page each blog post has to start with a short introduction:  \r\nMy name is Sebastian and I wrote his challenge to give you a rough template for writing your own challenge. Besides I think, that the problem can be easily solved with NIF and it is a good showcase. \r\n\r\nThe goal of this challenge is to create a Semantic Search. In this context this means the following.\r\n\r\nFor a given text (see below) a user gets a search form and can enter one or several search terms. The search shall return all sentences that have \"something to do\" with the search term. Additional information should also be shown.\r\n\r\nMost of the following requirements should be met:\r\n
\r\n\t
Synonyms should be included, i.e. searching for \"USA\" returns sentences with \"United States\"
\r\n\t
Some form of normalisation (stemming, lemmatising, stopword removal) should be applied.
\r\n\t
DBpedia Instances, that are in the text and match the search should shown. They can also be shown to disambiguate the search, i.e.\u00A0 when searching for \"Bush\"\u00A0 or \"Madonna\".
\r\n\t
Related and similar instances to the found DBpedia instances, that are also in the same text, i.e. Barack Obama is related to United States.
\r\n
\r\n
Given text
\r\nthis text should be used: http://nlp2rdf.lod2.eu/tutorial/semantic-search/search_text.txt\r\n
Mockup
\r\nA static mockup, where only \"USA\" can be searched can be found here\r\nhttp://nlp2rdf.lod2.eu/tutorial/semantic-search/mockup.php\r\nCode:\r\nhttp://nlp2rdf.lod2.eu/tutorial/semantic-search/mockup.txt\r\n\r\n\r\nSome suggestions of resources that can be used, i.e. you can use anything else.\r\n
\r\n\t
Snowball Stemmer
\r\n\t
FOX
\r\n\t
Stanford CoreNLP\u00A0
\r\n\t
Pablo Mendes Lexicalizations data set for Wikipedia . Some information from the data set was extracted and loaded here in a Virtuoso Triples Store: http://hanne.aksw.org:8890/sparql . Graph: http://dbpedia.org/lexicalizations You can get alternative surface forms for DBpedia with SPARQL Queries.
\r\n
\r\n " .
 "title" "Tutorial Challenge: Semantic Yellow Pages" .
 "content" "According to the Get Involved page each blog post has to start with a short introduction: \r\nHello, I am Konrad H\u00F6ffner and I am a student of computer science at the at University of Leipzig. I love living in the future but one of the things that I am still dissatisfied with is yellow pages. They are nationally limited, pestered by advertisments (and I *hate* ads),\u00A0 don't understand synonyms, are only indexed in the language of the country of origin and/or are generell dumb (try searching for \"delicious pizza nearby\" in Google Maps). Fortunately I think the Semantic Web is the technology that can alleviate this nuisance and it's only *you* who can save the world!\r\n\r\n
Challenge
\r\nYour goal is to create a Semantic Yellow Pages Search for LinkedGeoData. In a simple html search form a user can enter keywords or a search sentence. For the search the following needs to be extracted:\r\n
\r\n\t
a location
\r\n\t
an amenity
\r\n\t
(optional) a restriction or filter condition
\r\n
\r\nThis information is now to be used to construct SPARQL queries on the LinkedGeoData SPARQL endpoint (or another knowledge base if you like) and present the result to the user. Note that if no location can be found in the search string, the user's current location should be used instead. The position can be found out via the HTML 5 feature geolocation (or given in another input text field for testing ).\r\n
Example 1
\r\n\"I am looking for a optician in Paris.\" Here the location is the city of lgdo:Paris and the amenity is lgdo:Optician. There is no restriction or filter in this example. The city Paris only has a single geo point (her center). Since it is a lgdo:City a radius of 5 km is appropriate. Here is an example SPARQL query(click here to see the result):\r\n
Prefix lgd: \r\nPrefix lgdo: \r\nSelect ?optician ?name ?opticiangeo from  {\r\n   ?paris owl:sameAs  .\r\n   ?paris geo:geometry ?parisgeo .\r\n   ?optician a lgdo:Optician .\r\n   OPTIONAL {?optician rdfs:label ?name . }\r\n   ?optician geo:geometry ?opticiangeo .\r\n   Filter(bif:st_intersects(?parisgeo, ?opticiangeo, 5))\r\n}
\r\nAs an additional challenge you can adjust the radius not only for the type of the location (city:5km, country:100km), but also for the searched amenity (lgdo:Optician 5 km, lgdo:Toilets 0.4 km)\r\n
Example 2
\r\n\"cheap restaurant\": Here the task is to find cheap restaurants near the position of the user. The amenity in this case is lgdo:Restaurant. The restriction is hard to extract here and could best be translated to \"below a certain price point\" which even then still requires the application to a) find out the restaurant's prices and b) determine where that price lies (e.g. below the median or at least one standard deviation to the left of the average). Because the restriction handling is quite challenging, it is ok if you don't implement restrictions or only do it for basic cases like \"within 500 m\". If a restriction is present and the results are shown as a list, the results should be ordered according to the restriction criterion, e.g. for \"within 500 m\" they should be ordered by distance, ascending.\r\n\r\n
Requirements
\r\nMost of the following requirements should be met:\r\n
\r\n\t
Synonyms should be included, i.e. searching for \"tooth doctor\" returns the same result as \"dentist\".
\r\n\t
Other languages should be included, i.e. searching for \"Zahnarzt\" returns the same result as \"dentist\".
\r\n\t
Search results should be shown as a table. The geo position and the name of the amenities should be shown along with their relevant properties (distance, opening times, etc. )
\r\n
\r\n\r\n
Suggested resources
\r\nSome suggestions of resources that can be used, i.e. you can use anything else.\r\n
\r\n\t
LinkedGeoData SPARQL Endpoint (recommended for both the ontology, the instances itself and the queries)
\r\n\t
LinkedGeoData Ontology. Note that there are already many multilingual labels included.
\r\n\t
 Example SPARQL queries on LinkedGeoData
\r\n\t
Wortschatz Universit\u00E4t Leipzig for the synonyms. AFAIK the synonyms are only included for the German language so it is ok if synonyms are only used for German. A prepared table of synonyms specifically for the LinkedGeoData ontology will be available soon, so that you don't have to work with the Wortschatz interface.
\r\n\t
LinkedGeoData supports the REST interface and can thus be queried like this: http://linkedgeodata.org/page/near/51.033333,13.733333/1000/class/Optician. Further details can be found at http://linkedgeodata.org/OnlineAccess/RestApi.
\r\n
" .
 "title" "Tutorial: How to call a NIF web service with your favorite SemWeb library" .
 "content" "The parameters for NIF 1.0 can be found in the Parameter Section of the spec.\r\nBelow are example code snippets for several client side implementations. The result is always a combined RDF model of two NIF services.\r\n\r\n\r\n\r\n
curl
\r\nNote that there currently is no \"best\" RDF merge tool for the command line so we will use Jena CLI.\r\n\r\n\r\n# query snowball demo webservice\r\ncurl \"http://nlp2rdf.lod2.eu/demo/NIFStemmer?input=My%20favorite%20actress%20is%20Natalie%20Portman!&input-type=text&nif=true\" > snowball.owl\r\n# query stanford demo webservice\r\ncurl \"http://nlp2rdf.lod2.eu/demo/NIFStanfordCore?input=My%20favorite%20actress%20is%20Natalie%20Portman!&input-type=text&nif=true\" > stanford.owl\r\n#combine with Jena rdfcat\r\nrdfcat -x snowball.owl stanford.owl > combined.owl\r\n\r\n\r\n\r\n\r\n
Jena
\r\nSee http://jena.sourceforge.net\r\n
\r\n\r\nModel model = ModelFactory.createDefaultModel();\r\nString text = \"My favorite actress is Natalie Portman!\"\r\nStringBuilder p = new StringBuilder();\r\np.append(\"?input=\");\r\np.append(URLEncoder.encode(text,\"UTF-8\"));\r\np.append(\"&input-type=text\");\r\np.append(\"&nif=true\");\r\nURL stemmer = new URL(\"http://nlp2rdf.lod2.eu/demo/NIFStemmer\"+p.toString());\r\nURL stanford = new URL(\"http://nlp2rdf.lod2.eu/demo/NIFStanfordCore\"+p.toString());\r\nmodel.read(\r\n   new BufferedReader(new InputStreamReader(stemmer.openConnection().getInputStream())), null);\r\nmodel.read(\r\n   new BufferedReader(new InputStreamReader(stanford.openConnection().getInputStream())), null);\r\n\r\n
\r\n\r\n
ARC2
\r\nSee http://arc.semsol.org. This is also the code used in this .\r\n\r\n
\r\n$stemmer = \"http://nlp2rdf.lod2.eu/demo/NIFStemmer?input-type=text&nif=true&input=\".urlencode($text); \r\n$parser = ARC2::getRDFXMLParser();\r\n$parser->parse($stemmer);\r\n$stemmertriples = $parser->getTriples();\r\n$stanford = \"http://nlp2rdf.lod2.eu/demo/NIFStanfordCore?input-type=text&nif=true&input=\".urlencode($text); \r\n$parser = ARC2::getRDFXMLParser();\r\n$parser->parse($stanford);\r\n$stanfordtriples = $parser->getTriples();\r\n$alltriples = array_merge($stanfordtriples, $stemmertriples);\r\n$ser = ARC2::getTurtleSerializer();\r\n$output = $ser->getSerializedTriples($alltriples);\r\necho $output;\r\n
\r\n" .
   .
  "None" .
  "NIF 1.0 compliant without RDF/XML input and given error handling." .
   .
   .
   .
 "title" "MontyLingua" .
 "content" "My name is Marcus Nitzschke and I'm studying computer science at the University of Leipzig. This implementation was written as the practical course of the lecture \"Software aus Komponenten\" in autumn 2011. Generally I chose this topic because I'm interested in the techniques of the Semantic Web and in detail because the connection of these techniques and NLP applications meant a new experience to me.\r\n\r\nDue to the website, \"MontyLingua is a free, commonsense-enriched, end-to-end natural language understander for English\". The commonsense-enriched part let MontyLingua differ from various other NLP tools. MontyLingua combines a Tokenizer, Part-of-speech Tagger, Extractor, Lemmatiser and a so called NLGenerator, which generates naturalistic English sentences and text summaries.\r\n\r\nBecause MontyLingua is written in Python this is one of the first non-Java wrapper for NLP2RDF (Monty also provides a Java binary, but Python is more fun :)). The wrapper currently implements the Part-of-speech Tagger component of MontyLingua. For future work it would be interesting to extract informations of word relationships which are provided by MontyLingua.\r\n
" .
   .
  "None." .
  "NIF 1.0 compliant without RDF/XML input; JSONP output" .
   .
   .
   .
 "title" "DBpedia Spotlight" .
 "content" "My name is Robert Schulze and like Marcus I'm studying computer science at the University of Leipzig. For the practical course of the lecture \"Software aus Komponente\" I created a wrapper for the DBpedia Spotlight web service, that\u00A0generates NIF output.\r\n\r\nThe wrapper uses the Spotlight annotation endpoint to find named entities in a given text input. It's implemented in Node.js, runs as a web service itself and fulfills all normative and (almost) all\u00A0interface requirements given by the NIF-1.0 specification. Please have a look at the projects README\u00A0for a detailed overview. Additionally to the specification I added JSONP as a output format. JSONP output allows JavaScript developers to create client side\u00A0software on top of my implementation.\r\n\r\nFor future development I would like to support N-Triples, \u00A0Turtle and N3 as output formats. Because to the best of my knowledge there is no RDF framework/library/tool written in JavaScript or for Node.js, that supports transformations between these formats and RDF/XML, this is not the easiest goal to achieve. Furthermore I think it would be convenient to have a small reference implementation that uses the JSONP output.\r\n\r\n" .
 "title" "Gate ANNIE" .
 "content" " \r\n\r\nMy name is Didier Cehrix and like\u00C2\u00A0Marcus\u00C2\u00A0and Robert\u00C2\u00A0I\u00E2\u0080\u0099m studying computer science at the University of Leipzig. For the practical part of the lecture \u00E2\u0080\u009CSoftware aus Komponente\u00E2\u0080\u009D I created a wrapper for the NLP Software Gate, especially for the ANNIE plugin.\r\n\r\nThe wrapper use the embedded version of Gate. The ANNIE plugin is ein Part Of Speach tagger. For the NIF output must the Gate document format be converted. The Gate document use a tree and this tree must be traversed and so the RDF output generated.\r\n\r\nFor future work I will to implement a document converter from NIF to Gate. This enable to use NIF as input in Gate.\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n
Homepage
Gate
Additional parameter
None
Webserviceurl
NIFgateAnnie
Demo
Hello World
Code
Bitbucket
" .
 "title" "NIF Roadmap 2012 and pointers" .
 "content" "Just a repost of an email I wrote to the Stanbol Dev mailing list. See here for the discussion.\r\n\r\nBelow is a copy of the email:\r\nLast year, we have been working on the NLP Interchange Format (NIF).\r\nNIF is an RDF/OWL-based format that aims to achieve interoperability between Natural Language Processing (NLP) tools, language resources and annotations.\r\n\r\nWhat NIF currently is:\r\n1. In Sept. 2011, we published the specification 1.0: http://nlp2rdf.org/nif-1-0 . There are about 8-12 implementations (see demo at 5.) out there, we know of.\r\n2. One of the latest draft papers about it can be found here: http://svn.aksw.org/papers/2012/WWW_NIF/public/string_ontology.pdf\r\n3. Basic idea is to use # fragments to give URIs to Strings, e.g.:\r\n http://www.w3.org/DesignIssues/LinkedData.html#offset_717_729 represents the first occurence of \"Semantic Web\" in http://www.w3.org/DesignIssues/LinkedData.html\r\nOf course, you can then use this URI as subject and add any annotation you want.\r\ne.g.:\r\n:offset_717_729 its:mentions dbpedia:Semantic_Web .\r\n4. There is a Web annotator making use of the Hash URI scheme or NIF:\r\nhttp://pcai042.informatik.uni-leipzig.de/~swp12-9/vorprojekt/index.php?annotation_request=http%3A//www.w3.org/DesignIssues/LinkedData.html%23frag_65b9eea6e1cc6bb9f0cd2a47751a186f\r\n5. There is a demonstrator (will be much nicer in a couple of days): http://nlp2rdf.lod2.eu/demo.php\r\nwith eye candy, but minor bug: http://nlp2rdf.lod2.eu/demo_new.php\r\n6. Apart from that NIF also tries to find best practices for annotation. E.g. OLiA idenitifers for Part of Speech tags http://www.sfb632.uni-potsdam.de/~chiarcos/ontologies.xml or NERD or the lemon model.\r\n\r\nWhat is planned for NIF:\r\na) A new spec NIF 2.0 within this year. Discussion will be on this mailing list: http://lists.informatik.uni-leipzig.de/mailman/listinfo/nlp2rdf\r\nNIF will be simplified (simpler URI Schemes and annotations), consolidated (Better implementations) and extended (ability to express confidence value and string sets, etc. )\r\nb) We plan to have implementations for NERD http://nerd.eurecom.fr , DBpedia Spotlight, Zemanta.com and DKPro http://www.ukp.tu-darmstadt.de/research/current-projects/dkpro/\r\nc) Inclusion of XPointer as NIF URI Scheme and creation of a mapping to \"string uris\". This should somehow be compatible with the Internationalisation Tag Set (ITS) 2.0 http://www.w3.org/TR/its20/ , but we are still working together on a bidirectional bridge. There have been a plethora of discussion partly at this thread: http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2012Jun/0101.html\r\nd) NIF should be compatible with PROV-AQ: Provenance Access and Query http://www.w3.org/TR/2012/WD-prov-aq-20120619/\r\n\r\nWhat I am hoping for or my ideas about how Stanbol and NIF overlap:\r\nI) Reading your docu, you guys seem to be able to provide very good use cases and feedback for NIF 2.0 . We would really like to include that and also tailor NIF 2.0 to your needs. We are currently setting up a Wiki - still ugly sorry: http://wiki.nlp2rdf.org/ Please mail me for accounts.\r\nII) I would assume, that you need some OWL model for all the enhancer output. NIF standardizes NLP tool output and it tries to be blank-node free and lightweight, but still as expressive as possible. So for you this would mean that you could really save time, as ontology modelling is really tedious. By reusing NIF you would get a free data model and spec and you could focus on the implementation of the Stanbol engine. I got a 404 on http://incubator.apache.org/enhancer/enhancementstructure.html\r\nI read \"fise\" somewhere. What is it? How does it compare to NIF? What URIs do you use? How many triples do you have per annotation?\r\nIII) With NIF we focused on the RDF output for tools, not on the workflow. Stanbol seems to focus on the workflow as well, right? It might be easy to implement a NIF engine with Stanbol. This could be a good showcase for NIF and Stanbol. With a Debian package, we could include Stanbol into the LOD2 Stack http://stack.lod2.eu/" .