Plan to refactor the data JSON format to JSON-LD, using a dictionary schema.org.
The problem is that we need to pass additional properties that are not in the dictionary schema.org, we cannot abandon these properties because there it is technical metadata that is used in the logic of our AJAX sites.
The question of having the properties are not in the dictionary schema.org, create problems for indexing AJAX our site, or search bot will simply ignore the properties he does not know and it does not affect indexing?
Bots will simply ignore those properties. If you don't map them to URLs (for example by setting them explicitly to null in the context), they are effectively invisible for a JSON-LD processor. See http://www.w3.org/TR/json-ld/#advanced-context-usage for more details
Related
I have to model a product, which has properties that aren't listed in the Schema.org Product type. After seeking in many places, I didn't find anything that fits to my need.
How can I extend the Schema.org Product type?
You could always use other vocabularies (that offer the properties you need) in addition to Schema.org. But if you want to use only the vocabulary Schema.org, you have two options in general:
Propose new properties (or classes).
You can do this on Schema.org W3C Community Group’s mailing list, or on Schema.org’s GitHub issue tracker.
See: How can I get involved? How can I propose new schemas or other improvements?
If accepted, it might become part of the core (if it’s something "the most common web applications need"), or it might become an extension.
(deprecated!) Extend existing properties.
Extending existing properties is documented at http://schema.org/docs/old_extension.html, but note that this mechanism is considered outdated.
For specific types (including Product), you can use Schema.org’s additionalProperty property:
A property-value pair representing an additional characteristics of the entitity, e.g. a product feature or another characteristic for which there is no matching property in schema.org.
How to store only metadata for an object of type sys:base or cm:object? I have a type which is sub-type of sys:base. I need to store the metadata of it.
My doubts are:
1. Where should the data be stored?
How to retrieve the data, as in content and folder you can see the appearance as icon in the company home or user home etc. How does the metadata appear in a folder(is it like an icon of cm:object)?
With reference to the question posted earlier in alfresco forum (http://forums.alfresco.com/forum/developer-discussions/content-modeling/can-i-store-only-metadata-alfresco-11292012-0437) should the object be of type cm:content to store the metadata (except that they do not have a content property). Is there anyway to create metadata other than being subtype of cm:content?
Thank you
You can store metadata on instances of any type as long as the content model includes properties that meet your needs. Those might be out-of-the-box types or they might be custom types.
If you need to create objects that have a content stream, use cm:content. If you don't need to set a content stream you might consider using one of the two types you mentioned. But it won't necessarily hurt anything if you elect to simply create instances of cm:content that don't have a content stream.
If you want to use sys:base or cm:object, simply create an instance of either of those types. Alternatively, define your own sub-type of those types then instantiate that custom type and set your metadata.
If you don't know how to define custom types or you are unsure about how to set, update, or query metadata, you could start by reading this tutorial.
Also note that if you create instances of any type other than cm:content, cm:folder, or a custom type that inherits from one of those two types, you will be unable to do that using CMIS. That isn't the end of the world, just be aware that it is currently a limitation. Someday Alfresco will support the "item" type which is new in CMIS 1.1, but until then, CMIS in Alfresco can only work with documents, folders, and your custom types that inherit from those types.
I have my first iOS app with Core Data, and there is an Entry entity. Entry has the attribute called "Tag" and it's NSString.
So now when user created a new Entry he can put any string into Tag field and it will be stored in Core Data as NSString, which can be used later for search by tag.
The thing is I want to implement multiple tags feature in my app and I can't figure out how to do it, what's the correct design for cases like this in iOS, considering using Core Data.
For example, if someone wants to create an Entry and give it tags like "food", "groceries", "apples". How should I assign all of them to my property of Entry entity? How should I store them in Core Data? As a separate entity Tags with unique ids? How should I retrieve them and how can user edit multiple tags for an Entry?
Thank you in advance for answers.
There are 2 common ways to do that.
the simplest one is to store comma separated tags in your NString. (but you won't be able do filtering and other operations involving tags)
Create another entity - Tag with name and id. And have many-to-many relationship (assuming one tag can be used by several entries)
a good explanation on how to do that is given here cdrelationships
you can do it in multiple way. You could just separate your tags with the character of you choice and just split the NSString in you code to retrieve your tags.
Or, if you want to make things right, just use another entity to store your tag's IDs.
Use that tutorial
This will help you to understand core data.
I need to store an activity feed in an iOS application. Activity feed items will have a payload field which can be one of many (and I really mean many) types of entities in the system.
What is a good way to implement this payload relationship field on the Activity entity in my CoreData model?
Is it possible to use the id data type, or maybe use an NSManagedObject type?
One way to workaround this maybe to just store CoreData's entityId as a string in a special field, but I'd rather avoid that if there is a better way.
Example:
For simplicity let's say we have a not-so-standard blogging model: User, Blog, BlogPost, Comment and the following activities may happen:
User may create a new blog.
User may publish a new blog post.
A blog can be commented on.
A comment maybe liked.
etc.
Each of these generate a new Activity item on the website which in turns have a related payload relation to the item that was modified or being acted on.
Now I need to download, translate and store these activity feed items from the website in my iPhone application... so how do I mimic this payload field since it maybe pointing to any possible entity?
In my real code, though, there are about 10+ types of entities that could be put into this payload field so I'm looking for a good approach here.
If you don't need to search / query the fields of your objects of variable type, then I suggest to use NSCoder to convert them into a binary representation and store them in a BLOB field of your managed object. You might want to store some type information as well in an other field of the same managed object. On the other side if you need to search between these variable objects then you have to create a new managed object type (entity) for each object. See my answer also here: NSCoding VS Core data
Only thing that you can use is NSManagedObject. So you have to create your model and your relation and create new file for Activity and payload that will be subclasses of NSManagedObject.
Take a look at Core Data Programing Guide .
You will find your answers in there.
I would like to experimentally apply an aspect of encapsulation that I read about once, where an entity object includes domains for its attributes, e.g. for its CostCentre property, it contains the list of valid cost centres. This way, when I open an edit form for an Extension, I only need pass the form one Extension object, where I normally access a CostCentre object when initialising the form.
This also applies where I have a list of Extensions bound to a grid (telerik RadGrid), and I handle an edit command on the grid. I want to create an edit form and pass it an Extension object, where now I pass the edit form an ExtensionID and create my object in the form.
What I'm actually asking here is for pointers to guidance on doing this this way, or the 'proper' way of achieving something similar to what I have described here.
It would depend on your data source. If you are retrieving the list of Cost Centers from a database, that would be one approach. If it's a short list of predetermined values (like Yes/No/Maybe So) then property attributes might do the trick. If it needs to be more configurable per-environment, then IoC or the Provider pattern would be the best choice.
I think your problem is similar to a custom ad-hoc search page we did on a previous project. We decorated our entity classes and properties with attributes that contained some predetermined 'pointers' to the lookup value methods, and their relationships. Then we created a single custom UI control (like your edit page described in your post) which used these attributes to generate the drop down and auto-completion text box lists by dynamically generating a LINQ expression, then executing it at run-time based on whatever the user was doing.
This was accomplished with basically three moving parts: A) the attributes on the data access objects B) the 'attribute facade' methods at the middle-tier compiling and generation dynamic LINQ expressions and C) the custom UI control that called our middle-tier service methods.
Sometimes plans like these backfire, but in our case it worked great. Decorating our objects with attributes, then creating a single path of logic gave us just enough power to do what we needed to do while minimizing the amount of code required, and completely eliminated any boilerplate. However, this approach was not very configurable. By compiling these attributes into the code, we tightly coupled our application to the datasource. On this particular project it wasn't a big deal because it was a clients internal system and it fit the project timeline. However, on a "real product" implementing the logic with the Provider pattern or using something like the Castle Projects IoC would have allowed us the same power with a great deal more configurability. The downside of this is there is more to manage, and more that can go wrong with deployments, etc.