Is it common to define cardinalities for properties (relationships) within DCMI or RDF schemas?
The existing content regarding this topic is quite limited, but there are resources showing the use of cardinalities (but not in official documents from DCMI or W3).
E.g. see occurence here:
Related
Imagine I have two RDF (turtle) files, one that contains my custom ontology (a.ttl) and one that contains values according to the ontology (b.ttl).
Is it possible to check if b.ttl is respecting all the definitions defined in a.ttl using .NET RDF?
I can load a.ttl using the OntologyGraph class, can I use this in some way to validate that the graph loaded from b.ttl is following the specification?
It depends on how your definitions are expressed.
If they are expressed in SHACL, then yes - dotNetRDF supports SHACL validation (which is sadly not yet written up in the docs, but take a look at this sample code).
If they are expressed in OWL, then no - dotNetRDF does not have an OWL inference engine so it cannot determine if your data is consistent with the ontology (in general OWL is actually for asserting new facts, and OWL "validation" is a process of determining if the facts asserted remain consistent with the ontology). You may need to look to one of the reasoners listed here to do this sort of processing.
A simple RDF-Schema based set of constraints (like just subclass, property domain, property range) could probably be converted to SHACL fairly easily, but that would be an additional step to add to your process.
I am quite puzzled with these two terminologies. I know the basic meaning of metadata is "data about the data".
Microdata means the webpages are now more accessible to the search engines.
But what separates these two terms?
Microdata is the name of a specific technology, metadata is a generic term.
Metadata is, like you explain, data about data. We’d typically want this metadata to be machine-readable/-understandable, so that search engines and other consumers can make use of it.
In the typical sense, metadata is data about the whole document (e.g., who wrote it, when it was published etc.). This goes into the head element (which "represents a collection of metadata for the Document"), where you have to use the meta element and its name attribute (unless the value is a URI, in which case you have to use the link element and its rel attribute), as this is defined to "represent document-level metadata".
Microdata is not involved here.
If the data is about entities described in that document (or the entity which represents the document itself), we typically speak of structured data. An example for such an entity could be a product and its price, manufacturer, weight etc.
Microdata is one of several ways how to provide structured data like that. Others are RDFa, Microformats, and also script elements used as data block (which can contain something like JSON-LD).
Metadata (small m) is a general descriptive term, Microdata (big M) is the name of a particular technology.
Microdata is a particular kind of metadata that can be attached to a particular kind of data (namely HTML) in a particular way (as defined by W3C's Microdata spec).
Metadata: using data to provide information about data. For instance, if you are collecting data about prices of different commodities and you added a small section at the top of the questionnaire to collect information about the name of the enumerator, time of interview, duration of interview etc., such information is a metadata.
Microdata: data from individual observations of interest.
First off, I'm trying to define database tables with attributes from Schema.org, eg., for example I have a table named "JobPosting" that more or less has the same attributes as those defined in http://schema.org/JobPosting (baseSalary, etc.,), same goes for another table named "Organisation"
I have recently come across dbpedia.org (http://dbpedia.org/ontology/Organisation), the schema details seem to be much more richer, but I'm am confused as to:
Is dbpedia.org ontology an extension of those listed in schema.org?
Are dbpedia.org schemas recognized by major search engines (as those from schema.org)
What's the difference between Microdata and RFDs?
I'm going a little stir crazy trying to find the details...I couldn't find any comparisons vis-a-vis dbpedia.og vs schema.org.
Schema.org is one of countless vocabularies (resp. ontologies). The DBpedia Ontology is another one. Both vocabularies are independent of each other. Another vocabulary, related to your example, would be The Organization Ontology.
Which search engines recognize which vocabularies is a question without a definite answer. Search engines might recognize vocabularies without documenting it, or they might not recognize some (parts of) vocabularies although their documentation says otherwise. On top of that, all this might change daily.
You asked for the difference between Microdata and RFDs RDFs, but it’s likely that you mean RDFa in this context. Both are syntaxes which can be used to annotate content with the help of vocabularies. See my answer about differences between Microdata and RDFa.
(RDFS is "just" another vocabulary which can be used to describe vocabularies.)
I will try to answer all your questions, with understandable explanations.
Is dbpedia.org ontology an extension of those listed in schema.org?
No, it's not. There are countless ontologies available online, and any of them can be used combined, or alone, as long as their namespace (i.e. https://www.w3.org/2004/02/skos/ for SKOS or http://rdfs.org/sioc/spec/ for SIOC) is a valid URI.
Are dbpedia.org schemas recognized by major search engines (as those from schema.org)?
dbpedia schemas are as good as any other, and, as stated in the answer for the first question, it really doesn't matter which ontology you decide to use, as long as it best fits your content.
You can even create your own ontology in OWL-RDF.
What's the difference between Microdata and RFDa (not RDFs)?
The only difference between these 2 attribute sets is the way they're written, while they both do the same thing.
Other information:
RDFs stands for Resource Description Format Schema, and it's a format used to write the ontologies, together with OWL
OWL stands for Web Ontology Language, and it was created especially for writing ontologies
RDFa stands for Resource Description Format in Attributes, and it's an attribute set used to create structured data mapped on the existent HTML code
Microdata is an attribute set used to create structured data mapped on the existent HTML code
When designing a specialized structured-data document format (perhaps upon XML): part of the requirements for this document format are that it accommodates, in a metadata section, a history of meaningful (app-level) changes to the structured data at a field level.
At minimum, useful tracked information would be:
an author identifier
time stamp
type of change
what it was changed from
Both data items and any lists of such data items are to be tracked meaningfully, efficiently. The data schema should be separable/unaware of the metadata tracking it - although facilitating annotations such as node identifiers could be required. A trusted application could be required to enforce the tracking; however, it would be a benefit to be able to calculate the "deltas" at intervals by comparing data-sections between versions rather than requiring the editor to track each change live.
"Meaningful" tracking may involve the metadata schema treating higher-level data changes atomically - such as an update to a group of fields which is treated at the application level as one data-point.
For character-by-character or byte-by-byte data, diff/patch type algorithms work. Structured data (to be treated as structured) seems to me to require more complex solutions.
I realize that I don't have very well-defined requirements - the purpose of my question here is to find out where these problems have been considered with more elegance.
What strategies exist for embedding change tracking in a structured data document format?
Thanks!
You might be interested in XML patch formats (e.g. as described by rfc 5261).
You could for example, build a list of such patches embedded at the top of your structured XML file and annotating each patch with its author, potential feature request/bug number and so on, potentially annotating it with semantic level patch information (such as "added such object", "removed such rule"...). Using such a format could help you obtain old versions from your document rather easily as tools exist to treat it.
What is the difference between CMSs and DMSs ? Both store date , give access to the data , where do they differ? Can apache Jack Rabbit be used in place of Alfresco ?
I would differentiate the two based on they mutability of the data under management:
In a Document Management System, the Documents are immutable (and often opaque) blobs created by external applications
A Content Management system contains mutable data (the content) and provides an interface to mutate said content.
Of course, DMSs have evolved to break this rule - for example, by adding document properties to a Word Document... however, people seem comfortable with calling this "metadata" and therefore it can break all the rules.
Given the immutable nature of the data, a DMS can make assumptions that a CMS can not - given these assumptions, I would be careful stating (as per Wolfwyrd's comment) that DMS is a subset of CMS.
Content management refers to a system that stores content of any type. It tends to involve a workflow (i.e. creators, editors, publishers). Content management oalso often deals with fragments of data applied to templates. For example, a template for a page may be created with editable body, sub title, title etc.
Document management refers to a system that stores electronic documents or files of any type. Document management can be considered a subset of content management - a more specialised form of content management as it approaches the management only of electronic files, not necessarily the potential to store fragments of content.
Jack Rabbit and Alfresco both supply content management services so they can also be used to support document management by the simple fact that one is a subset of the other. So in this case, it's more down to which provide the features you need.