Is there a relationship between schema.org and WAI-ARIA?
Is one a subset of the other? Are they different? Are there any commonalities?
No, there is no relationship. Neither is a sub-set of the other.
Schema.org is intended to provide search engines with additional information about content, via microdata, RDFa, and JSON-LD. Within HTML you would use microdata. You can read more on using microdata at schema.org. There is no formal standards body behind it, it is defined by the major search engines.
ARIA (Accessible Rich Internet Applications) is a bridging technology that allows authors to add additional information to HTML so that assistive technology can make better use of it. Ideally it will go away as browsers catch up. It has no bearing on search engines. It is maintained by W3C, where you can read an overview on ARIA.
Related
I want to use json ld micro-data from schema.org to reference images on my website but at the same time retrieve the json ld object in my Javascript to use it for others things. The problem is that I want to add custom fields that do not match any type in Schema.org. My question is, will search engines just ignore the fields they don't recognize or discard the whole micro-data ?
Short answer, yes they’ll ignore properties they don’t define, and it’s quite normal to use JSON-LD for other purposes, such as to drive your UI. That said, it’s best if these properties and types come from a known vocabulary, or even resolve to your own. It’s always good to test your data patterns first, using any of the online tools available.
Also, it’s not JSON-LD micro-data, they are actually two different things, both of which (along with RDFa) can be used to provide schema.org markup. JSON-LD is contained in a script element, the others are expressed using HTML attributes.
Are there any advantages/disadvantages in using a specific format for http://www.schema.org/Product? Something like "Searchengines understand Microdata better than JSON-LD"? I would like to use JSON-LD, because it doesn't mess-up with your html-code, but I'm not sure if it would be better concerning the searchengines to use Microdata.
There is no general answer, it depends on the consumer of the data.
A specific consumer supports a specific set of syntaxes, and might or might not recommend a subset of these supported syntaxes.
Because search engines usually try to make sure not to get lead astray (e.g., a page about X claims via its Schema.org use to be about Y), it seems natural that they would prefer a syntax that couples the Schema.org metadata to the visible content of the page (in HTML5, this would be Microdata or RDFa); for the same reasons why many meta tags are dead for SEO.
However, this is not necessarily always the case. Google, for example, recommends the use of JSON-LD for a few of their features (bold emphasis mine):
Promote Critic Reviews:
Though we strongly recommend using JSON-LD, Google can also read schema.org fields embedded in a web page with the microdata or RDFa standards.
Sitelinks Search Box:
We recommend JSON-LD. Alternatively, you can use microdata.
I am looking for Content Management Systems that comply with W3 standards in HTML. I prefer those that are coded in Java or PHP (preferably Java). Any ideas where I can get such information? I checked on http://www.cmsmatrix.org and http://en.wikipedia.org/wiki/List_of_content_management_systems but they don't tell if the CMS's actually comply with W3 standards.
W3C published many standards.
I’d say that most of these standards can be relevant for CMS, e.g., HTML, CSS, RDFa, ATAG, WCAG, WAI-ARIA, etc.
And most of these technologies/standards/best-practices would be implemented in the frontend/backend theme (aka. template). So any CMS which allows you to use custom themes should do the job.
If or which default themes of which CMS follow W3C standards is a question which would be off-topic for Stack Overflow. You already found lists of CMS; select the Java/PHP ones and check their default theme for whichever criteria are relevant to you.
I am familiar with using cyclomatic complexity to measure software. However, in terms of web site, do we have a kind of metrics to measure complexity of website?
If you count HTML tags in the displayed HTML pages, as "Operators", you can compute a Halstead number for each web page.
If you inspect the source code that produces the web pages, you can compute complexity measures (Halstead, McCabe, SLOC, ...) of those. To do that, you need tools that can compute such metrics from the web page sources.
Our SD Source Code Search Engine (SCSE) is normally used to search across large code bases (e.g., the web site code) even if the code base is set of mixed languages (HTML, PHP, ASP.net, ...). As a side effect, the SCSE just so happens to compute Halstead, McCabe, SLOC, comment counts, and a variety of other basic measurements, for each file it can search (has indexed).
Those metrics are exported as an XML file; see the web link above for an example.
This would give you a rough but immediate ability to compute web site complexity metrics.
Though the question was asked 6 moths ago...
If your website is 100% static site with no javascript at all, then it needs to be powered by a back-end programmed in a programming language. So indirectly, the complexity measures that afflict the back-end programming will also affect the complexity of maintaining the site.
Typicall, I've observed a corellation between the maintainability and quality (or lack thereof) of the web pages themselves to the quality (or lack thereof) exhibited, through software metrics, in the back-end programming. Don't quote me on that, and take it with a grain of salt. It is purely an observation I've made in the gigs I've worked on.
If your site - dynamic content or not - also has JavaScript in it, then this is also source code that demonstrate measurable attributes in terms of software complexity metrics. And since JavaScript is typically used for rendering HTML content, it stands as a possibility (but not as a certainty) that attrocious, hard to maintain JavaScript will render similarly attrocious, hard to maintain HTML (or be embedded in attrocious, hard to maintain markup.)
For a completely static site, you could still devise some type of metrics, though I'm not aware of any that are publisized.
Regarless, a good web site should have uniform linking.
It should provide uniform navigation.
Also, html pages shouldn't be replicated or duplicated, little to no dead links.
Links within the site should be relative (either to their current location or to the logical root '/') and not absolute. That is, don't hard-code the domain name.
URI naming patterns should be uniform (preferably lower case.) URLs are case-insensitive, so it makes absolutely no sense to have links that mix both cases. Additionally, links might be mapping to stuff in actual filesystems that might be case-sensitive, which leads to the next.
URIs that represent phrases should be uniform (either use - or _ to separate words, but not both, and certainly no spaces). Avoid camel case (see previous comment on lower casing.)
I'm not aware of any published or advocated software-like metrics for web sites, but I would imagine that if there are, they might try to measure some of the attributes I mentioned above.
I suppose you could consider "hub scores" to be a complexity metric since it considers how many external sites are referenced. "Authoritative sources in a hyperlinked environment" by Jon Kleinberg discusses it.
This is a great paper on the topic.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'd like to develop a CMS for fun/personal using asset-based architecture rather than page-based (why, is the purpose of this question), but I can't find much information on the subject. All I've found barely scrapes the surface (there's a good chance I'm searching with the wrong terms).
An asset-based CMS stores information
as blocks of text called assets. These
individual assets are then related to
each other to automatically build
pages.
What are the (dis/)advantages of such a system?
What are the primary principles of asset-based architecture?
What should and shouldn't be an 'asset'? Where can I read more?
Decided to try to answer this after leaving my comment :)
If your definition of "asset" is along the lines of a "node" (such as in Drupal), or a document (such as the JSON-style documents in MongoDB or CouchDB), then here is some info:
I'll use the term "node" for this post. I think it's closest to "asset" and more popularly used. This also might be a very abstract answer, but hopefully it will at least get you thinking and pointed in the right direction.
Node-based architecture, could be described as a cross between neural networking patterns and object-oriented programming. The key is that "nodes" are points of data, and nodes can be connected to each other in some way.
Some architectures will treat nodes much like object-oriented classes, where you have different classes of nodes that can inherit various characteristics of parent nodes - every type of node inherits the basic properties of its parent - an "Essay" node might inherit the properties of a "Text-Document" node, which in turn inherits the properties of the base node. Drupal implements this inheritance model well, although it does not emphasize the connections between nodes in the way that something like Facebook's GraphAPI/Open Graph Protocol does.
This pattern of node-based architecture can be implemented at any level too, and exists in nature - think of social circles within society or ecosystems ;) On a software engineering level, it can take the form of a database, such as how MongoDB simply has nodes of data (which are called documents in that case). These documents can reference other documents, although, like Drupal, Mongo does not emphasize connectedness. Ironically, relational databases like MySQL that are the opposite of document-based databases actually emphasize connectedness more, but that's a discussion for another day. Facebook's GraphAPI that I mentioned above is implemented on a Web-API level. The Open Graph Protocol shapes it. And again, something like Drupal is implemented at the front-end level (although its back-end implements the node pattern on a lower level, of course).
Lastly, node-based architecture is much more flexible than traditional document/page based CMS architecture, but that also means there is a lot more programming and configuring to be done on the side of the developers. A node-based system will end up being far more inter-connected and its components will be integrated with one-another a deeper level, but it can also be more susceptible to breaking because of this deep level of connection - it is less than separated into individual modules. Personally, I see a huge trend where people are moving to become more "node-based" and less "content-based" as people begin to interact with websites more like applications than as electronic magazines as they did in the 90's. Plus, the node-pattern fits well with the increasing emphasis on user-contribution and social browsing because adding people and their accounts/profiles to a web site dramatically increases the complexity.
I know you said "asset," so I'll also say that asset emphasizes the data side of the node pattern more, whereas "node" emphasizes the connections between the pieces of data more.
But for further reading, I'd recommend reading up on the architecture of the software I mentioned. You could also check out node.js, JSON, and document-based databases, and GraphAPI's as they seem to fit well with this idea of asset/node-based architecture. I'm sure Wikipedia has some good stuff on these patterns as well.
You could very quickly scale this up using the CakePHP framework. It uses an MVC pattern and it provides classes called elements that may be inserted into layouts and can load whatever content you want based on the page, user, moon phase, etc.
<page>
<element calls methodX>
<element calls methodY>
<Default Content relies on Controller Action(view/edit/add/custom)>
<element calls methodZ>
</page>
I think you might be describing a CMS backed up by a content repository.
The repository itself is implemented by Apache Jackrabbit based on JSR 170:
The API should be a standard, implementation independent, way to access content bi-directionally on a granular level within a content repository. A Content Repository is a high-level information management system that is a superset of traditional data repositories. A content repository implements "content services" such as: author based versioning, full textual searching, fine grained access control, content categorization and content event monitoring. It is these "content services" that differentiate a Content Repository from a Data Repository.
For a CMS working on top a content repository, look at Nuxeo.