Best practices says that
JSON documents may be in the form of a object, or an array of objects.
For most purposes, developers need a single entry point, so the JSON
SHOULD be in the form of a single top-level object.
This seems to me to be encouraging the idea that the top-level object in a JSON-LD document has some special significance, say that it might be where processing should start. This works fine for RDF-unaware components but, when the JSON-LD document has been converted into RDF, how do I tell which node is the top-level object? Is the RDF-unaware component attaching significance to something that has no semantic footprint?
Some possible solutions I am considering:
Ask the RDF-unaware client to mark the root node for me (e.g. rdf:type my:RootNode)
Find the blank node (subject) that never appears as an object (and hope there is exactly one).
Load the JSON-LD as JSON, and do (1) myself before parsing, hoping that the JSON-LD is always in just the right form.
Related
As far as I know, POST is usually used for changing the state of the server, and PUT usually for updating the information. If I am creating a new index, should it not be POST instead of PUT? PUT does make sense when creating a document as it changes the state of data.
Your statement
As far as I know, POST is usually used for changing the state of the server, and PUT usually for updating the information.
does conform to the conventional HTTP vs CRUD semantics:
HTTP method
CRUD equivalent
Description
POST
Create
Let the target resource process the representation enclosed in the request.
PUT
Update
Set the target resource’s state to the state defined by the representation enclosed in the request.
However, the PUT spec also stipulates that:
The PUT method requests that the state of the target resource be
created or replaced with the state defined by the representation
enclosed in the request message payload
As such, PUT can (and is) used in Elasticsearch to both create an index AND update its
[settings and mappings].
Also, keep in mind that it's rarely just a matter of strict adherence to the semantics. One of the creators of ES put it this way:
It's all about REST semantics.
And our understanding of the semantics at the time when we made the APIs. And backwards compatibility constraints. And whatever "feels" natural to the person who implemented the API.
Where it makes a lot of sense Elasticsearch maps the HTTP verbs to
useful things. But when it doesn't make a ton of sense we just go with
whatever verb feels good rather than trying to be super strict about
REST. Also, we don't do linked data, instead relying on you to build
links from context. I'm told that is particularly non-REST. But it is
what we do.
When someone talks about hydrating an object, what does that mean?
I see a Java project called Hydrate on the web that transforms data between different representations (RDMS to OOPS to XML). Is this the general meaning of object hydration; to transform data between representations? Could it mean reconstructing an object hierarchy from a stored representation?
Hydration refers to the process of filling an object with data. An object which has not yet been hydrated has been instantiated and represents an entity that does have data, but the data has not yet been loaded into the object. This is something that is done for performance reasons.
Additionally, the term hydration is used when discussing plans for loading data from databases or other data sources. Here are some examples:
You could say that an object is partially hydrated when you have only loaded some of the fields into it, but not all of them. This can be done because those other fields are not necessary for your current operations. So there's no reason to waste bandwidth and CPU cycles loading, transferring, and setting this data when it's not going to be used.
Additionally, there are some ORM's, such as Doctrine, which do not hydrate objects when they are instantiated, but only when the data is accessed in that object. This is one method that helps to not load data which is not going to be used.
With respect to the more generic term hydrate
Hydrating an object is taking an object that exists in memory, that doesn't yet contain any domain data ("real" data), and then populating it with domain data (such as from a database, from the network, or from a file system).
From Erick Robertson's comments on this answer:
deserialization == instantiation + hydration
If you don't need to worry about blistering performance, and you aren't debugging performance optimizations that are in the internals of a data access API, then you probably don't need to deal with hydration explicitly. You would typically use deserialization instead so you can write less code. Some data access APIs don't give you this option, and in those cases you'd also have to explicitly call the hydration step yourself.
For a bit more detail on the concept of Hydration, see Erick Robertson's answer on this same question.
With respect to the Java project called hydrate
You asked about this framework specifically, so I looked into it.
As best as I can tell, I don't think this project used the word "hydrate" in a very generic sense. I see its use in the title as an approximate synonym for "serialization". As explained above, this usage isn't entirely accurate:
See: http://en.wikipedia.org/wiki/Serialization
translating data structures or object state into a format that can be stored [...] and reconstructed later in the same or another computer environment.
I can't find the reason behind their name directly on the Hydrate FAQ, but I got clues to their intention. I think they picked the name "Hydrate" because the purpose of the library is similar to the popular sound-alike Hibernate framework, but it was designed with the exact opposite workflow in mind.
Most ORMs, Hibernate included, take an in-memory object-model oriented approach, with the database taking second consideration. The Hydrate library instead takes a database-schema oriented approach, preserving your relational data structures and letting your program work on top of them more cleanly.
Metaphorically speaking, still with respect to this library's name: Hydrate is like "making something ready to use" (like re-hydrating Dried Foods). It is a metaphorical opposite of Hibernate, which is more like "putting something away for the winter" (like Animal Hibernation).
The decision to name the library Hydrate, as far as I can tell, was not concerned with the generic computer programming term "hydrate".
When using the generic computer programming term "hydrate", performance optimizations are usually the motivation (or debugging existing optimizations). Even if the library supports granular control over when and how objects are populated with data, the timing and performance don't seem to be the primary motivation for the name or the library's functionality. The library seems more concerned with enabling end-to-end mapping and schema-preservation.
While it is somewhat redundant vernacular as Merlyn mentioned, in my experience it refers only to filling/populating an object, not instantiating/creating it, so it is a useful word when you need to be precise.
This is a pretty old question, but it seems that there is still confusion over the meaning of the following terms. Hopefully, this will disambiguate.
Hydrate
When you see descriptions that say things like, "an object that is waiting for data, is waiting to be hydrated", that's confusing and misleading. Objects don't wait for things, and hydration is just the act of filling an object with data.
Using JavaScript as the example:
const obj = {}; // empty object
const data = { foo: true, bar: true, baz: true };
// Hydrate "obj" with "data"
Object.assign(obj, data);
console.log(obj.foo); // true
console.log(obj.bar); // true
console.log(obj.baz); // true
Anything that adds values to obj is "hydrating" it. I'm just using Object.assign() in this example.
Since the terms "serialize" and "deserialize" were also mentioned in other answers, here are examples to help disambiguate the meaning of those concepts from hydration:
Serialize
console.log(JSON.stringify({ foo: true, bar: true, baz: true }));
Deserialize
console.log(JSON.parse('{"foo":true,"bar":true,"baz":true}'));
In PHP, you can create a new class from its name, w/o invoke constructor, like this:
require "A.php";
$className = "A";
$class = new \ReflectionClass($className);
$instance = $class->newInstanceWithoutConstructor();
Then, you can hydrate invoking setters (or public attributes)
Using Sphinx's domain-aware ObjectDescriptions I can create fancy rendered documentation for them. For example:
.. py:function:: pyfunc()
Describes a Python function.
This renders the content in a nice way, and this works really well with module indices, references and so on. Cool so far!
Now, let's say I have that directive in a source document src/mymodule/functions.rst, and I have a bunch of text in src/guide/getting-started.rst, I can reference to the objects like
:py:func:`pyfunc`
Also cool!
Now, my actual question; Could I also tell the Sphinx writer to re-render the same documentation snippet for that object? To ease the user in not having to navigating away from the Getting Started page where I just want to include a single piece of content again.
What I've tried to do:
Simply copy the contents. This results in a warning that the object is defined multiple times, hurts the index and as a result references don't point to the "authoritative" place in your project, if unlucky. Not okay.
Document each object in its own file and then use .. include:: rel/path/to/pyfunc.rst in each document where I want to render it. As those includes are literal on ReST-level, this results in the same downsides as the option above. :-(
Thus, I'm looking for a solution where I would tell the renderer/writer of Sphinx to simply re-render the contents of a reference instead of producing a link. It should not add it to the index for a simple re-render.
I'm okay with a custom extension or a domain-specific custom solution - I'm already using my own custom domain, but I just used the general Python domain above as a well-known example.
Context for the use case: I'm building a Protobuf domain. Protobuf messages and enums are reused a lot and I would like to show the context of commonly reused objects inline on pages where this is useful to the reader. This means it is repeated over the whole project on purpose where it is deemed useful rather than navigating away all the time. Yet only the reference page should be "authoritative".
I've been successful with a dirty hack: abusing the XRef role logic. Cross-references in Sphinx render dynamically (e.g. Table 23) by producing arbitrary 'nodes'. By:
keeping a copy of the parent node during parsing in a custom Domain
registering a custom Sphinx/ReST XRef role to render a whole set of nodes (the saved parent node)
re-running the ReferencesResolver another time
... this basically does what I need. But yuck, it's rather ugly.
Working example I implemented in a Protobuf Domain extension.
I'm quite new to MVC3, just learning and am looking for some guidance.
For sake of simplicity, I have a model that represents 3 types of elements, questions, answers and containers.
All 3 inherit from a common base type, which I'll call baseElement.
When the model is delivered to the view it is a single object of type 'baseElement'
The container elements have an internal list of baseElements.
Those baseElements can be of any of the three types. So - containers can contain questions, or containers (which could also contain questions, containers, etc..)
Each question can contain different types of answer types.
I'm trying to figure out how to use mvc3 to best implement a system to display this container/question structure to the user - permitting them to answer questions with various answer types while respecting the nested structure of the incoming model.
Alright, despite the dynamic nature of my model, after poking around for awhile longer I've been able to render my model object structure without too much complication.
I did it by using a strongly typed Editor Templates (one for each type), and the following code in the View.
#Html.EditorFor(x => #Model, #Model.GetType().Name)
This automatically chooses the proper editor template to use based on the actual type.
In each of the type specific Editor Templates I make the same call for each of the children.
It actually ends up being pretty simple.
The big problem I'm running into now, is how to model bind (or otherwise retrieve) the form values back into something usable once it's posted by the user. The dynamic nature of the structure causes the default model binder to cross it's arms and give up.
At this point I think retrieving/remapping the form data might be a much bigger issue, but that will certainly require more tinkering, and perhaps a separate question.
Thanks for the help.
:-)
I'm trying to figure out how to decide when to use NSDictionary or NSCoder/NSCoding?
It seems that for general property lists and such that NSDictionary is the easy way to go that generates XML files that are easily editable outside of the application.
When dealing with custom classes that holds data or possibly other custom classes nested inside, it seems like NSCoder/NSCoding would be the better route since it will step through all the contained object classes and encode them as well when an archive command is used.
NSDictionary seems like it would take more work to get all the properties or data characteristics to a single level to be able to save it, where as NSCoder/NSCoding would automatically encode nested custom classes that implement the NSCoding interface.
Outside of it being binary data and not editable outside of your application is there a real reason to use one over the other? And along those lines is there an indicator of which way you should lean between the two? Am I missing something obvious?
Apple's documentation on object graphs has this to say:
Mac OS X serializations store a simple hierarchy of value objects, such as dictionaries, arrays, strings, and binary data. The serialization only preserves the values of the objects and their position in the hierarchy. Multiple references to the same value object might result in multiple objects when deserialized. The mutability of the objects is not maintained.
…
Mac OS X archives store an arbitrarily complex object graph. The archive preserves the identity of every object in the graph and all the relationships it has with all the other objects in the graph. When unarchived, the rebuilt object graph should, with few exceptions, be an exact copy of the original object graph.
The way I interpret this is that, if you want to store simple values, serialization (using an NSDictionary, for example) is a fine way to go. If you want to store an object graph of arbitrary types, with uniqueness and mutability preserved, using archives (with NSCoder, for example) is your best bet.
You may also want to read Apple's Archives and Serializations Programming Guide for Cocoa, of which the aforelinked page on object graphs is a part, as it covers this topic well.
I am NOT a big fan of using NSCoding/NSCoder/NSArchiver (we need to pick a name!) to serialise an object graph to a file.
Archives created in this way are incredibly fragile. If you save an object of class Foo then by golly you need to make sure when you load the data back in you have a class Foo in your application.
This makes NSCoder based serialisation difficult from the perspective of sharing files with other applications or even forwards compatibility with your future application.
I forgot to list what I would recommend.
NSCoding can be ok in certain situations: if you're just doing something quick and simple (although you do have to write a lot of code - two methods per class to be serialised). It can also be ok if you're not worried about compatibility with other applications.
Export/import via property lists (perhaps using the NSPropertyListSerializaion class) is a fine solution. XML based plists are easy to create and edit. Main advantage to plists is that you're not tying the file format to just your application.
You can also create your own XML based file format and read/write to it using NSXMLDocument API and friends. This really isn't much more work than using property lists.
I think you're a bit confused, NSDictionary is a data structure, it also happens to implement the NSCoding protocol. So in essence, you could either put all your data into a NSDictionary and have that encode itself later on, or you can implement the NSCoding protocol and encode your object tree using the NSCoder API. Based on the type of NSCoder object passed in to the encodeWithCoder: method, is the output of your encoding.