Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
rdf [2018/08/20 20:53]
christian [Experience]
rdf [2020/03/18 09:09] (current)
christian [Experience]
Line 25: Line 25:
 The namespace is RDF. The core classes are The namespace is RDF. The core classes are
   * **Graph** is a collection of ''**Statement**''s   * **Graph** is a collection of ''**Statement**''s
-  * **Statement** consists of subject, predicate and object; each of which is a ''**Term**''+  * **Statement** consists of ''subject''''predicate'' and ''object''; each of which is a ''**Term**''
   * **Term** with ''**IRI**'', ''**Blank**'' and ''**Literal**'' as concrete subclasses   * **Term** with ''**IRI**'', ''**Blank**'' and ''**Literal**'' as concrete subclasses
  
Line 68: Line 68:
 First, I read the nicely written [[https://www.w3.org/TR/2014/REC-rdf-syntax-grammar-20140225/#section-Syntax|introductory chapter]] of the RDF specification. For the examples, I programmed a prototyp ad-hoc to read and write them. That was fun, but many details were not mentioned, so that I used wild guesses for parts of the code. First, I read the nicely written [[https://www.w3.org/TR/2014/REC-rdf-syntax-grammar-20140225/#section-Syntax|introductory chapter]] of the RDF specification. For the examples, I programmed a prototyp ad-hoc to read and write them. That was fun, but many details were not mentioned, so that I used wild guesses for parts of the code.
  
-Then I discovered all the [[https://www.w3.org/TR/rdf11-testcases/|tests for RDF]]. Among them was the official test suite which covers every detail. How cool is that! After importing all tests as SUnit tests into the image, I refactored and refined my implementation with the use of the tests. In the beginning, many - about half - failed or lead to errors. This as fun too, but again, there has been not enough information for a "right" implementation. The tests covered all features but only isolated and didn't give any explanation about what the test is testing; just the expected outcome. Sometimes it was not clear how the features would interact with others. Anyhow, I fiddled with my implementation until all tests were green (about 350).+Then I discovered all the [[https://www.w3.org/TR/rdf11-testcases/|tests for RDF]]. Among them was the official test suite which covers every detail. How cool is that! After importing all tests as SUnit tests into the image, I refactored and refined my implementation with the use of the tests. In the beginning, many - about half - failed or lead to errors. This was fun too, but again, there has been not enough information for a "right" implementation. The tests covered all features but only isolated and didn't give any explanation about what the test is testing; just the expected outcome. Sometimes it was not clear how the features would interact with others. Anyhow, I fiddled with my implementation until all tests were green (about 350).
  
 When an example or feature was not clear, I consulted the [[https://www.w3.org/TR/2014/REC-rdf-syntax-grammar-20140225/#section-Infoset-Grammar|formal grammar]]. The grammar consists of syntax productions which clearly describes the form and interplay of all elements. The chapter is not for reading. But it is invaluable for deciding on the right way to program things. So I decided to implement the productions as shown in the spec. This was a lot of fun. I had the tests - all green - and all functionality had been implemented already. Therefore it was just refactoring of the code into a form close to the productions in the spec. This lead to less and cleaner code. And now I am pretty sure, that the implementation is complete. I think that it will handle any legal RDF/XML. When an example or feature was not clear, I consulted the [[https://www.w3.org/TR/2014/REC-rdf-syntax-grammar-20140225/#section-Infoset-Grammar|formal grammar]]. The grammar consists of syntax productions which clearly describes the form and interplay of all elements. The chapter is not for reading. But it is invaluable for deciding on the right way to program things. So I decided to implement the productions as shown in the spec. This was a lot of fun. I had the tests - all green - and all functionality had been implemented already. Therefore it was just refactoring of the code into a form close to the productions in the spec. This lead to less and cleaner code. And now I am pretty sure, that the implementation is complete. I think that it will handle any legal RDF/XML.
Line 79: Line 79:
 ==== XMP ==== ==== XMP ====
  
-For the PDFtalk library I need XMP to work with the metadata of documents. XMP is a RDF language which restricts the very general RDF. Certain features are forbidden in XMP - luckily the complicated ones: ''**XMLLiterals**'' and ''**xml:base**''. Other restrictions apply to properties and how they are used. This defines the semantics of the language.+For the PDFtalk library I need XMP to work with the metadata of documents. XMP is a RDF language which restricts the very general RDF. Certain features are forbidden in XMP - luckily the complex ones: ''XMLLiterals'' and ''xml:base''. Other restrictions apply to properties and how they are used. This defines the semantics of the language.
  
 I wonder how to do this: defining a language on RDF. Interesting task. I wonder how to do this: defining a language on RDF. Interesting task.
 ==== Triple store ==== ==== Triple store ====
  
-Eventually, I want to store a lot of statements. For now, a ''**Graph**'' is just an ''**OrderedCollection**'' of ''**Statement**''s. This will not be sufficient for large amounts of data. I will need a [[https://en.wikipedia.org/wiki/Triplestore|triplestore]].+Eventually, I want to store a lot of statements. For now, a ''Graph'' is just an ''OrderedCollection'' of ''Statement''s. This will not be sufficient for large amounts of data. I will need a [[https://en.wikipedia.org/wiki/Triplestore|triplestore]].
  
 === Other syntaxes: Turtle and SPARQL === === Other syntaxes: Turtle and SPARQL ===
Line 92: Line 92:
 === Schemas and inferencing === === Schemas and inferencing ===
  
-Schemas (or Vocabularies or ontologies) for RDF can be easily (?) defined by anyone. A schema itself is defined in RDF. Commonly used (and sometimes mixed) are RDFS (RDF Schema) and OWL (Web Ontology Language). Besides concepts like ''**Class**'' and ''**Property**'', predicates and value restrictions, an ontology also defines properties for relationships. For example you can define that the relation ''**married**'' between two persons is symetrical; or that the ''**subclass**'' relationship is transitive.+Schemas (or Vocabularies or ontologies) for RDF can be easily (?) defined by anyone. A schema itself is defined in RDF. Commonly used (and sometimes mixed) are [[https://www.w3.org/TR/rdf-schema/|RDFS]] (RDF Schema) and [[https://www.w3.org/2001/sw/wiki/OWL|OWL]] (Web Ontology Language). Besides concepts like ''Class'' and ''Property'', predicates and value restrictions, an ontology also defines properties for relationships. For example you can define that the relation ''married'' between two persons is symetrical; or that the ''subclass'' relationship is transitive.
  
 With this, only basic facts have to be entered into a triple store. Many more facts can get deducted / inferenced. It would be an interesting project to build such an inferencer. I wonder if Gemstone would make a good triplestore. With this, only basic facts have to be entered into a triple store. Many more facts can get deducted / inferenced. It would be an interesting project to build such an inferencer. I wonder if Gemstone would make a good triplestore.
  • rdf.1534791216.txt.gz
  • Last modified: 2018/08/20 20:53
  • by christian