Imagine a window showing some sort of a feed. There are multiple panels displaying various messages as they arrive, plus some boxes that show statuses of other things, or the time, for example. This is a complex system usually thought of as calls to different APIs, various types of messages, presentation layer etc. What if I told you however that such a feat could be done even with only standardized formats, no client-side scripting and a single XML document and HTTP request?
There is nothing like null in RDF, but sometimes it is necessary to express its meaning in RDF documents as well. The issue with null however is that its semantics can vary from use to use, and thus one has to think about the intended meaning before going for one of the alternatives, as it may negatively affect the consistency of the data when an incorrect representation is selected.
Let's look at some examples.
I have never had anything against XML. Despite its many quirks and burdens, I think it is even nowadays a perfectly reasonable format for providing or accepting structured data, and I think it is meaningless (albeit trendy) to compare it with JSON trying to determine whichever is better. It is obvious those two languages were designed for different purposes, and the real virtue in data engineering (or software engineering in general) is to know and use the proper tools for completing a task.
In that regard, no language should come out as the winner in this comparison, but it should give you an idea when to use one or the other.
At its core, any RDF document is just a collection of semantic triples, recognized by any basic RDF tool. However, the call for standardization and mutual intelligibility has led to several ways to describe the schema that the data should follow, with two use cases in mind: reasoning and validation.
I've recently discovered RDF, one of the web's rising frameworks for identifying and describing data, made for the web of linked data. It can describe people, institutions, accounts, places, events, languages, documents, and much more thanks to the vast range of standardized vocabularies for different concepts, entities, and relations. The core unit of information in RDF is the semantic triple: subject, predicate, and object. The individual concepts (resources) are identified with URIs, brining universal identification, verification, and navigation to pieces of data.
There are numerous vocabularies (ontologies) for RDF, and one of them is FOAF (Friend of a Friend), used for describing people and their online presence, as well as general groups of people. One of the properties a group in FOAF (class foaf:Group) can have is foaf:membershipClass. This states that people in a specific group can be thought of as members of a particular class, that the two sets of people are equal.
There is also OWL, an ontology of ontologies, a vocabulary for describing vocabularies. The purpose of this metaontology is assisting reasoners in deriving additional facts from data, forming a complex knowledge base. Even though there are simpler schemata that are sometimes enough (RDFS), OWL defines things like identity, equivalency of classes and properties, and constructions of anonymous classes and properties in terms of relations to other classes and properties.
There are parts of FOAF that are hard to describe using OWL, and foaf:membershipClass is one of those, since it links an individual (group) to a class. I will now try to describe it with OWL (using the Turtle language).
As always, one question at StackOverflow attracted my attention and made me program all the night. The question was actually about a way to refer to a predefined object in a dynamically emitted method in a dynamic assembly. That is actually quite an easy task, provided you aren't going to save the assembly and use it later in a different program. In this case, simply use some way to refer to the object using a number (add it to a list, or use a GCHandle) and there's nothing easier than emitting an integer in CIL.
If you want to save the assembly, this approach obviously will not work, as the object will be lost when you quit the runtime. In this case, you'd have to find an optimal way to serialize the desired object, either directly calling its constructor in method, or use a serializer and put the result in the assembly resource space.
However, for some strange reason, I didn't immediately think about those two ways, probably because it was late night. Instead, I thought about compiled lambdas in Linq.Expressions and how closures work there (mainly Expression.Constant). Behind all that emitting, it's actually quite simple - if you know how delegates work. Someone coming over from the land of C will think about delegates as wrappers for function pointers, but it's more than that. You can bind a function pointer to a specific target object, which is then internally used as the first argument to the method (you can actually even bind static methods to target objects, and they behave as expected).
LINQ Expressions work the same way - the compiled lambda is dynamically emitted, and non-primitive constants are placed in a special container, which is then used as the target object of the created delegate. The compiled method would then access the container as easily as using this in an instance method. Provided I wouldn't have to save the assembly, what if I were to bind the desired object to a delegate and then call that delegate in the dynamic assembly?
The immediate problem here is obvious - the delegate has a target object, and I still have no way (ignore the first paragraph) to refer to it from inside the dynamic method. What I would want is a way to generate a piece of code that somehow stores the delegate and its target object, and would allow me to call it as a raw function pointer. Hmm, is there something in .NET that does that?
