Apache Any23
  1. Apache Any23
  2. ANY23-83

Remove hardcoded formats throughout Any23 to make it useful as a library

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.7.0
    • Fix Version/s: 0.8.0
    • Component/s: core
    • Labels:
      None

      Description

      Many classes inside of Any23 seem to hardcode restrictions on the supported formats, making it difficult to utilise Any23 as an extensible library.

      One example of this are RDFSchemaUtils that artificially restricts itself to three formats using an enum mapping, where it could easily accept any RDFHandler, even if it were not an RDFWriter.

      Another example is RDFUtils where the list of RDFParser's is hardcoded in, and enforced using an enum.

      What was the reasoning for creating artificial format classes and manually mapping them to writers/parsers instead of using either allowing any RDFHandler in the first case, or allowing any accessible RDFParser in the second case, using Rio.getParser() to avoid hardcoding anything.

        Issue Links

          Activity

          Hide
          Lewis John McGibbney added a comment -

          Having had a browse of both o.a.a.vocab.RDFSchemaUtils, and o.a.a.rdf.RDFUtils respectively, I understand where you are coming from. I also notice that you propose a more generic factory type implementation similar to Tika which (based on some criteria) guesses the specific parser which should be used per situation. What other mimetypes would we encounter other than the ones mentioned in both of the above classes as specified within the hardcoded RDFParsers?
          I am interested to find out what you think. Thank you

          Show
          Lewis John McGibbney added a comment - Having had a browse of both o.a.a.vocab.RDFSchemaUtils, and o.a.a.rdf.RDFUtils respectively, I understand where you are coming from. I also notice that you propose a more generic factory type implementation similar to Tika which (based on some criteria) guesses the specific parser which should be used per situation. What other mimetypes would we encounter other than the ones mentioned in both of the above classes as specified within the hardcoded RDFParsers? I am interested to find out what you think. Thank you
          Hide
          Peter Ansell added a comment -

          I was hoping that Any23 would be extensible to more than the current list of supported parsers. I understand that when Any23 was originally developed that it would have needed to restrict itself to a small set of supported parsers. I am not familiar enough with the rest of the codebase to know why the shortlist of supported parsers is in place, but it would be good if it could be made generic in the future.

          In terms of a generic factory type implementation, one could use the SPI based Rio.getParser(RDFFormat) or any of the other static methods in the Rio class. RDFFormat is not a fixed enum, so it can be extended, and the parsers are instantiated using RDFParserFactory implementations instead of directly created [1]. The mime-types are described inside of RDFFormat as a list, with preferred and alternate mime types, and the RDFParserFactory implementations that are found using SPI are each tested to see if the RDFFormat that they support fits with a given mime-type before the parser is instantiated.

          In terms of RDFSchemaUtils, it is not clear why the list is restricted the way it is, as it would be very useful to be able to patch any RDFHandler in, and would not take much coding to make the change as far as I can tell.

          [1] http://www.openrdf.org/doc/sesame2/api/org/openrdf/rio/RDFParserFactory.html

          Show
          Peter Ansell added a comment - I was hoping that Any23 would be extensible to more than the current list of supported parsers. I understand that when Any23 was originally developed that it would have needed to restrict itself to a small set of supported parsers. I am not familiar enough with the rest of the codebase to know why the shortlist of supported parsers is in place, but it would be good if it could be made generic in the future. In terms of a generic factory type implementation, one could use the SPI based Rio.getParser(RDFFormat) or any of the other static methods in the Rio class. RDFFormat is not a fixed enum, so it can be extended, and the parsers are instantiated using RDFParserFactory implementations instead of directly created [1] . The mime-types are described inside of RDFFormat as a list, with preferred and alternate mime types, and the RDFParserFactory implementations that are found using SPI are each tested to see if the RDFFormat that they support fits with a given mime-type before the parser is instantiated. In terms of RDFSchemaUtils, it is not clear why the list is restricted the way it is, as it would be very useful to be able to patch any RDFHandler in, and would not take much coding to make the change as far as I can tell. [1] http://www.openrdf.org/doc/sesame2/api/org/openrdf/rio/RDFParserFactory.html
          Hide
          Lewis John McGibbney added a comment -

          Hi Peter,

          {bq}

          I am not familiar enough with the rest of the codebase to know why the shortlist of supported parsers is in place [bq}

          Although I have tried to get to grips with as much of the codebase as I have a use-case for, I am sorry as I cannot provide insight into the original design considerations which you refer to... maybe one of the other guys could chime in here and clear the picture for us?

          I must admit though, I am in agreement with your overall analysis and think that the more extensible we can make the Any23 libraries the better. There was some discussion however over in ANY23-19 where the vision was to have an abstraction layer between Any23 and the underlying RDF API's. In my opinion, this would provide far greater potential for us to make Any23 a more flexible library... wdyt?

          Show
          Lewis John McGibbney added a comment - Hi Peter, {bq} I am not familiar enough with the rest of the codebase to know why the shortlist of supported parsers is in place [bq} Although I have tried to get to grips with as much of the codebase as I have a use-case for, I am sorry as I cannot provide insight into the original design considerations which you refer to... maybe one of the other guys could chime in here and clear the picture for us? I must admit though, I am in agreement with your overall analysis and think that the more extensible we can make the Any23 libraries the better. There was some discussion however over in ANY23-19 where the vision was to have an abstraction layer between Any23 and the underlying RDF API's. In my opinion, this would provide far greater potential for us to make Any23 a more flexible library... wdyt?
          Hide
          Peter Ansell added a comment -

          My personal preference ( as you may have noticed at ANY23-19 ) is to stay with the OpenRDF API, even if you don't use the Sesame implementation of it. All of the elements of the OpenRDF API are specified as interfaces and there are no hidden static singletons in the background that you can't reimplement another way when you need to. In addition, you can pull in the API using Maven without having to use the implementations which I view as a large point in its favour.

          I made quite a few changes yesterday to basically suit my use cases. These including fixing the cause for this issue by switching to RDFFormat as the central point of reference for the utils classes. I pushed the changes to GitHub at https://github.com/ansell/any23 . I am not sure how many of the changes you will want to pick up but you may find something interesting. The most visible change is that I split the core module up into a large number of smaller modules. You probably won't want to do that just yet, but I found that I could work with it and visualise it more easily if everything wasn't in a single core module. It may seem a little convoluted, particularly having the test resources in their own module, separate from the core unit tests, but it makes it simpler to use the test resources in maven to unit test the other modules, without having to either split up the test resource bundle or replicate some resources in other modules.

          The other very visible change is that I deleted the Any23 NQuads library in favour of importing the MIT licensed Sesametools NQuads library ( https://github.com/joshsh/sesametools ). It contains both a NQuadsParserFactory and an NQuadsWriterFactory that make it work with the static Rio methods that are all based on Service Provider Interface (ie, META-INF/services), including Rio.createParser() and Rio.createWriter(). This meant that the use of RDFFormat was no longer a breaking point, as it was when I first tried to switch and I was wondering why Rio.getParserFormatForFileName() was not working for NQuads. It turned out to be due to the missing ParserFactory in the Any23 NQuads implementation. In either case it doesn't really matter for long as there are plans inside Aduna to pick parts from one or both of the Any23 or Sesametools NQuads libraries (or the other two open source OpenRDF NQuads implementations) and implement them internally in a new sesame-rio-nquads package.

          Show
          Peter Ansell added a comment - My personal preference ( as you may have noticed at ANY23-19 ) is to stay with the OpenRDF API, even if you don't use the Sesame implementation of it. All of the elements of the OpenRDF API are specified as interfaces and there are no hidden static singletons in the background that you can't reimplement another way when you need to. In addition, you can pull in the API using Maven without having to use the implementations which I view as a large point in its favour. I made quite a few changes yesterday to basically suit my use cases. These including fixing the cause for this issue by switching to RDFFormat as the central point of reference for the utils classes. I pushed the changes to GitHub at https://github.com/ansell/any23 . I am not sure how many of the changes you will want to pick up but you may find something interesting. The most visible change is that I split the core module up into a large number of smaller modules. You probably won't want to do that just yet, but I found that I could work with it and visualise it more easily if everything wasn't in a single core module. It may seem a little convoluted, particularly having the test resources in their own module, separate from the core unit tests, but it makes it simpler to use the test resources in maven to unit test the other modules, without having to either split up the test resource bundle or replicate some resources in other modules. The other very visible change is that I deleted the Any23 NQuads library in favour of importing the MIT licensed Sesametools NQuads library ( https://github.com/joshsh/sesametools ). It contains both a NQuadsParserFactory and an NQuadsWriterFactory that make it work with the static Rio methods that are all based on Service Provider Interface (ie, META-INF/services), including Rio.createParser() and Rio.createWriter(). This meant that the use of RDFFormat was no longer a breaking point, as it was when I first tried to switch and I was wondering why Rio.getParserFormatForFileName() was not working for NQuads. It turned out to be due to the missing ParserFactory in the Any23 NQuads implementation. In either case it doesn't really matter for long as there are plans inside Aduna to pick parts from one or both of the Any23 or Sesametools NQuads libraries (or the other two open source OpenRDF NQuads implementations) and implement them internally in a new sesame-rio-nquads package.
          Hide
          Peter Ansell added a comment -

          Patch for NaiveMimeDetector to use Rio before resorting to the hardcoded list

          Show
          Peter Ansell added a comment - Patch for NaiveMimeDetector to use Rio before resorting to the hardcoded list
          Hide
          Peter Ansell added a comment -

          Patch to make RDFWriterTripleHandler accept any RDFHandler instead of RDFWriter to make it more generic

          Show
          Peter Ansell added a comment - Patch to make RDFWriterTripleHandler accept any RDFHandler instead of RDFWriter to make it more generic
          Hide
          Lewis John McGibbney added a comment -

          On the face of it this looks like great work Peter. This kind of foresight is what Any23 needs right now. I think we need to have a good discussion based on some of the points you make, especially w.r.t the actual Jira issue itself. Thank you

          Show
          Lewis John McGibbney added a comment - On the face of it this looks like great work Peter. This kind of foresight is what Any23 needs right now. I think we need to have a good discussion based on some of the points you make, especially w.r.t the actual Jira issue itself. Thank you
          Hide
          Lewis John McGibbney added a comment -

          I like these two patches and based on the conversation on any23-dev give the +1. Marking for 0.7.0 and happy to commit on behalf of Peter unless there are objections?

          Show
          Lewis John McGibbney added a comment - I like these two patches and based on the conversation on any23-dev give the +1. Marking for 0.7.0 and happy to commit on behalf of Peter unless there are objections?
          Hide
          Michele Mostarda added a comment -

          Hi Guys,
          about #ANY23-19: I don't like the idea to add an abstraction library, it would add useless complexity and compromise performances.
          Furthermore we would be conditioned to wait the update of the abstraction library to access any evolution of the underlying libraries.

          About patches:

          • I've improved the NaiveMIMETypeDetector logic as suggested by the submitted patch. See r1337905.
          • I've improved the RDFUtils library renaming/adding/refactoring methods to improve flexibility and usability. See r1337919, rr1337933.
          • About the suggested RDFParserTripleHandler: the RDFParserTripleHandler is a TripleHandler meant to serialize the received messages
            so it has to accept an RDFWriter, despite the current small difference between an RDFHandler and an RDFWriter it is cleaner to use the first,
            also keeping in mind future evolutions of such interface.
          • I've improved the NQuads Parser/Writer integration with Sesame RIO registering all via SPI. See r1337933.
          Show
          Michele Mostarda added a comment - Hi Guys, about # ANY23-19 : I don't like the idea to add an abstraction library, it would add useless complexity and compromise performances. Furthermore we would be conditioned to wait the update of the abstraction library to access any evolution of the underlying libraries. About patches: I've improved the NaiveMIMETypeDetector logic as suggested by the submitted patch. See r1337905. I've improved the RDFUtils library renaming/adding/refactoring methods to improve flexibility and usability. See r1337919, rr1337933. About the suggested RDFParserTripleHandler: the RDFParserTripleHandler is a TripleHandler meant to serialize the received messages so it has to accept an RDFWriter, despite the current small difference between an RDFHandler and an RDFWriter it is cleaner to use the first, also keeping in mind future evolutions of such interface. I've improved the NQuads Parser/Writer integration with Sesame RIO registering all via SPI. See r1337933.
          Hide
          Michele Mostarda added a comment -

          The refactoring of the ExtractorRegistry via SPI is still missing, stopping issue progress but keeping it open.

          Show
          Michele Mostarda added a comment - The refactoring of the ExtractorRegistry via SPI is still missing, stopping issue progress but keeping it open.
          Hide
          Hudson added a comment -

          Integrated in Any23-trunk #200 (See https://builds.apache.org/job/Any23-trunk/200/)
          Improved RDFUtils API, removed RDFUtils.Parser enum type. Improved compliancy of RDFUtils and NQuads support with Sesame RIO ServiceRegistry . This commit is related to issue #ANY23-83. (Revision 1337933)
          Improved util class usability. Related to #ANY23-83. (Revision 1337919)
          Improved Naive MIME type detection logic as per #ANY23-83. (Revision 1337905)

          Result = UNSTABLE
          mostarda :
          Files :

          • /incubator/any23/trunk/core/src/main/java/org/apache/any23/io/nquads/NQuadsParserFactory.java
          • /incubator/any23/trunk/core/src/main/java/org/apache/any23/io/nquads/NQuadsWriterFactory.java
          • /incubator/any23/trunk/core/src/main/java/org/apache/any23/rdf/RDFUtils.java
          • /incubator/any23/trunk/core/src/test/java/org/apache/any23/cli/RoverTest.java
          • /incubator/any23/trunk/core/src/test/java/org/apache/any23/rdf/RDFUtilsTest.java
          • /incubator/any23/trunk/plugins/basic-crawler/src/test/java/org/apache/any23/cli/CrawlerTest.java

          mostarda :
          Files :

          • /incubator/any23/trunk/core/src/main/java/org/apache/any23/rdf/RDFUtils.java

          mostarda :
          Files :

          • /incubator/any23/trunk/core/src/main/java/org/apache/any23/mime/NaiveMIMETypeDetector.java
          Show
          Hudson added a comment - Integrated in Any23-trunk #200 (See https://builds.apache.org/job/Any23-trunk/200/ ) Improved RDFUtils API, removed RDFUtils.Parser enum type. Improved compliancy of RDFUtils and NQuads support with Sesame RIO ServiceRegistry . This commit is related to issue # ANY23-83 . (Revision 1337933) Improved util class usability. Related to # ANY23-83 . (Revision 1337919) Improved Naive MIME type detection logic as per # ANY23-83 . (Revision 1337905) Result = UNSTABLE mostarda : Files : /incubator/any23/trunk/core/src/main/java/org/apache/any23/io/nquads/NQuadsParserFactory.java /incubator/any23/trunk/core/src/main/java/org/apache/any23/io/nquads/NQuadsWriterFactory.java /incubator/any23/trunk/core/src/main/java/org/apache/any23/rdf/RDFUtils.java /incubator/any23/trunk/core/src/test/java/org/apache/any23/cli/RoverTest.java /incubator/any23/trunk/core/src/test/java/org/apache/any23/rdf/RDFUtilsTest.java /incubator/any23/trunk/plugins/basic-crawler/src/test/java/org/apache/any23/cli/CrawlerTest.java mostarda : Files : /incubator/any23/trunk/core/src/main/java/org/apache/any23/rdf/RDFUtils.java mostarda : Files : /incubator/any23/trunk/core/src/main/java/org/apache/any23/mime/NaiveMIMETypeDetector.java
          Hide
          Peter Ansell added a comment -

          "- About the suggested RDFParserTripleHandler: the RDFParserTripleHandler is a TripleHandler meant to serialize the received messages
          so it has to accept an RDFWriter, despite the current small difference between an RDFHandler and an RDFWriter it is cleaner to use the first,
          also keeping in mind future evolutions of such interface. "

          The RDFParserTripleHandler code only uses the RDFHandler API currently. I don't have a use case for it currently, but I think it would be nice to allow any RDFHandlers even if they do not implement the full RDFWriter API. if you want to allow the future possibility of using the RDFWriter API in addition to the RDFHandler API then it would be best for API stability to leave it at the more restrictive RDFWriter.

          Show
          Peter Ansell added a comment - "- About the suggested RDFParserTripleHandler: the RDFParserTripleHandler is a TripleHandler meant to serialize the received messages so it has to accept an RDFWriter, despite the current small difference between an RDFHandler and an RDFWriter it is cleaner to use the first, also keeping in mind future evolutions of such interface. " The RDFParserTripleHandler code only uses the RDFHandler API currently. I don't have a use case for it currently, but I think it would be nice to allow any RDFHandlers even if they do not implement the full RDFWriter API. if you want to allow the future possibility of using the RDFWriter API in addition to the RDFHandler API then it would be best for API stability to leave it at the more restrictive RDFWriter.
          Hide
          Peter Ansell added a comment -

          "- I've improved the NaiveMIMETypeDetector logic as suggested by the submitted patch. See r1337905. "

          I think there is also the possibility of an equivalent patch for the TikaMIMETypeDetector as a backup for cases where Tika doesn't reveal a MIME-type but Rio might provide it. See https://github.com/ansell/any23/commit/6da60d6b92932f08a7ca9f08a3cdf9aa74615bb2

          Show
          Peter Ansell added a comment - "- I've improved the NaiveMIMETypeDetector logic as suggested by the submitted patch. See r1337905. " I think there is also the possibility of an equivalent patch for the TikaMIMETypeDetector as a backup for cases where Tika doesn't reveal a MIME-type but Rio might provide it. See https://github.com/ansell/any23/commit/6da60d6b92932f08a7ca9f08a3cdf9aa74615bb2
          Hide
          Peter Ansell added a comment -

          I rebased my git repository onto a copy of the current trunk to check how many patches I still had in this area and noticed that RDFSchemaUtils still hardcodes the supported formats. I may not be seeing the significance of VocabularyFormat currently, but I assume that it could be generalised to any RDFFormat.

          Is it related to the ability to type in a human readable alias for the format in VocabPrinter? If so, have you tried using RDFFormat.valueOf(String) in the converter inside VocabPrinter which matches against registered formats using:

          format.getName().equalsIgnoreCase(formatName)

          These names may not exactly match the historical names for each format that were previously used, but they are extensible at runtime so it makes RDFSchemaUtils easier to maintain. This may also help with ANY23-3 as N3 would be available, although it would just be the Turtle subset in practice as we only hold RDF triples in memory.

          Show
          Peter Ansell added a comment - I rebased my git repository onto a copy of the current trunk to check how many patches I still had in this area and noticed that RDFSchemaUtils still hardcodes the supported formats. I may not be seeing the significance of VocabularyFormat currently, but I assume that it could be generalised to any RDFFormat. Is it related to the ability to type in a human readable alias for the format in VocabPrinter? If so, have you tried using RDFFormat.valueOf(String) in the converter inside VocabPrinter which matches against registered formats using: format.getName().equalsIgnoreCase(formatName) These names may not exactly match the historical names for each format that were previously used, but they are extensible at runtime so it makes RDFSchemaUtils easier to maintain. This may also help with ANY23-3 as N3 would be available, although it would just be the Turtle subset in practice as we only hold RDF triples in memory.
          Hide
          Hudson added a comment -

          Integrated in Any23-trunk #311 (See https://builds.apache.org/job/Any23-trunk/311/)
          ANY23-83 : Remove some more hardcoded formats and mime-types (Revision 1380399)

          Result = FAILURE
          ansell :
          Files :

          • /incubator/any23/trunk/core/src/main/java/org/apache/any23/extractor/html/TurtleHTMLExtractor.java
          • /incubator/any23/trunk/core/src/main/java/org/apache/any23/extractor/rdf/BaseRDFExtractor.java
          • /incubator/any23/trunk/core/src/main/java/org/apache/any23/extractor/rdf/NTriplesExtractor.java
          • /incubator/any23/trunk/core/src/main/java/org/apache/any23/extractor/rdf/RDFParserFactory.java
          • /incubator/any23/trunk/core/src/main/java/org/apache/any23/extractor/rdf/RDFXMLExtractor.java
          • /incubator/any23/trunk/core/src/main/java/org/apache/any23/extractor/rdf/TriXExtractor.java
          • /incubator/any23/trunk/core/src/main/java/org/apache/any23/extractor/rdf/TurtleExtractor.java
          • /incubator/any23/trunk/core/src/main/java/org/apache/any23/vocab/RDFSchemaUtils.java
          • /incubator/any23/trunk/core/src/main/java/org/apache/any23/writer/NTriplesWriterFactory.java
          • /incubator/any23/trunk/core/src/main/java/org/apache/any23/writer/RDFXMLWriterFactory.java
          • /incubator/any23/trunk/core/src/main/java/org/apache/any23/writer/TriXWriterFactory.java
          • /incubator/any23/trunk/core/src/main/java/org/apache/any23/writer/TurtleWriterFactory.java
          • /incubator/any23/trunk/core/src/test/java/org/apache/any23/extractor/html/AbstractExtractorTestCase.java
          • /incubator/any23/trunk/core/src/test/java/org/apache/any23/extractor/microdata/MicrodataExtractorTest.java
          • /incubator/any23/trunk/service/src/main/java/org/apache/any23/servlet/Servlet.java
          • /incubator/any23/trunk/service/src/test/java/org/apache/any23/servlet/ServletTest.java
          Show
          Hudson added a comment - Integrated in Any23-trunk #311 (See https://builds.apache.org/job/Any23-trunk/311/ ) ANY23-83 : Remove some more hardcoded formats and mime-types (Revision 1380399) Result = FAILURE ansell : Files : /incubator/any23/trunk/core/src/main/java/org/apache/any23/extractor/html/TurtleHTMLExtractor.java /incubator/any23/trunk/core/src/main/java/org/apache/any23/extractor/rdf/BaseRDFExtractor.java /incubator/any23/trunk/core/src/main/java/org/apache/any23/extractor/rdf/NTriplesExtractor.java /incubator/any23/trunk/core/src/main/java/org/apache/any23/extractor/rdf/RDFParserFactory.java /incubator/any23/trunk/core/src/main/java/org/apache/any23/extractor/rdf/RDFXMLExtractor.java /incubator/any23/trunk/core/src/main/java/org/apache/any23/extractor/rdf/TriXExtractor.java /incubator/any23/trunk/core/src/main/java/org/apache/any23/extractor/rdf/TurtleExtractor.java /incubator/any23/trunk/core/src/main/java/org/apache/any23/vocab/RDFSchemaUtils.java /incubator/any23/trunk/core/src/main/java/org/apache/any23/writer/NTriplesWriterFactory.java /incubator/any23/trunk/core/src/main/java/org/apache/any23/writer/RDFXMLWriterFactory.java /incubator/any23/trunk/core/src/main/java/org/apache/any23/writer/TriXWriterFactory.java /incubator/any23/trunk/core/src/main/java/org/apache/any23/writer/TurtleWriterFactory.java /incubator/any23/trunk/core/src/test/java/org/apache/any23/extractor/html/AbstractExtractorTestCase.java /incubator/any23/trunk/core/src/test/java/org/apache/any23/extractor/microdata/MicrodataExtractorTest.java /incubator/any23/trunk/service/src/main/java/org/apache/any23/servlet/Servlet.java /incubator/any23/trunk/service/src/test/java/org/apache/any23/servlet/ServletTest.java
          Hide
          Hudson added a comment -

          Integrated in Any23-trunk #489 (See https://builds.apache.org/job/Any23-trunk/489/)
          ANY23-83 : Remove fixme note that is now fixed (Revision 1448890)
          ANY23-83 : Support arbitrary RDFFormats for VocabPrinter without being manually added to the list (Revision 1448888)

          Result = ABORTED
          ansell :
          Files :

          • /any23/trunk/core/src/main/java/org/apache/any23/vocab/RDFSchemaUtils.java

          ansell :
          Files :

          • /any23/trunk/core/src/main/java/org/apache/any23/cli/VocabPrinter.java
          • /any23/trunk/core/src/main/java/org/apache/any23/vocab/RDFSchemaUtils.java
          • /any23/trunk/core/src/test/java/org/apache/any23/vocab/RDFSchemaUtilsTest.java
          Show
          Hudson added a comment - Integrated in Any23-trunk #489 (See https://builds.apache.org/job/Any23-trunk/489/ ) ANY23-83 : Remove fixme note that is now fixed (Revision 1448890) ANY23-83 : Support arbitrary RDFFormats for VocabPrinter without being manually added to the list (Revision 1448888) Result = ABORTED ansell : Files : /any23/trunk/core/src/main/java/org/apache/any23/vocab/RDFSchemaUtils.java ansell : Files : /any23/trunk/core/src/main/java/org/apache/any23/cli/VocabPrinter.java /any23/trunk/core/src/main/java/org/apache/any23/vocab/RDFSchemaUtils.java /any23/trunk/core/src/test/java/org/apache/any23/vocab/RDFSchemaUtilsTest.java

            People

            • Assignee:
              Michele Mostarda
              Reporter:
              Peter Ansell
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development