Hello!
Thanks for your work with MADS/RDF!
On the list, the question of reinventing the wheel or not have been
recurring. I will write about this in the second part of my e-mail. I
begin with some comments I noted during my reading, accompanied by some
links that may be of interest.
* I really appreciate the use of "is" or "has" at the begining of
predicates to clarify their semantics. In many other circumstances, these
are neglected, which often leads to misunderstandings.
* In "RDF Semantics" from 2004, the W3C discourages the use of
xsd:duration in RDF in the following terms:
"xsd:duration does not have a well-defined value space (this may be
corrected in later revisions of XML Schema datatypes, in which case the
revised datatype would be suitable for use in RDF datatyping)"
http://www.w3.org/TR/rdf-mt/#XSDtable
Maybe we could consider this problem to be solved, thanks to the two
duration subtypes xs:yearMonthDuration and xs:dayTimeDuration now
described by the W3C at
http://www.w3.org/TR/xpath-functions/#duration-subtypes See also
http://www.w3.org/TR/xmlschema11-2/#sec-vs-duration about this topic.
We could thus choose to have two different duration elements (one for each
duration unit, that is the second and the month) or only one duration
element allowing authors to choose between two possible attributes.
* Despite of that, it is difficult to handle many periods, especially when
the intensity of the events vary during the period. Let's assume that a
cultural movement begins during the late 2010'ies, flourishes during the
first half of the 2020'ies, seems to vanish during the 2030'ies, have a
longer period of (weaker) flourishing during the 2040'ies, 2050'ies and
2060'ies and vanishes almost totally during the 2070'ies. In such a case,
the granularity of an activePeriod with point=start,end would probably be
too low. We would need both to describe period(s) of main flourishing and
the (total) dispersion of the cultural movement.
* There is of course no point in reinventing the wheel. This means that we
can take inspiration of what have already been done. Nonetheless, it is
important to remember that the web is incessantly being modified and this
applies of course to namespaces. This question have been discussed within
the W3C. There, N. Walsh wrote:
"As a general rule, resources on the web can and do change. In the absence
of an explicit statement, one cannot infer that a namespace is immutable."
http://www.w3.org/TR/namespaceState/#namespacedef
It's important to keep in mind that we have no guarantees on whom will be
in control of different URIs in the future and this applies to the
external namespaces included in most of today's XML schemas and RDF (among
others) on the Internet. What seems an interesting namespace today may be
modified to something totally different within a few years (or months!).
Furthermore, I consider it's important to ensure that as many libraries as
possible in the world will be able to use MADSXML, even in such countries
were the authorities may (for some or any reason) dislike the ideology
developed on these external URIs - today or in the future. Therefore, I
consider it wise to use only two domains within the normative parts of our
schemas and ontologies: w3.org and loc.gov. This will help to ensure the
preservation of the integrity of the library community.
On the same web page, N. Walsh also writes:
"Specifications that define namespaces SHOULD explicitly state their
policy with respect to changes in the names defined in that namespace."
http://www.w3.org/TR/namespaceState/#namespacedef
In light of that, it also seems advisable to formulate the change policy
for MADS' namespace at
http://id.loc.gov/ontologies/mads/2010/11/ or its successor.
To facilitate connections with parts of the semantic web on domains other
than loc.gov and w3.org, we could create an informative (non-normative and
therefore easily modified) file such as
http://id.loc.gov/ontologies/mads/2010/11/closeMatches.ttl
This file would contain triplets connecting the MADS scheme to concepts
within other namespaces through the skos:closeMatch - not the transitive
skos:exactMatch, because
"skos:closeMatch is not declared to be a transitive property."
http://www.w3.org/TR/skos-reference/#mapping
This way, we can use the wheel carefully and safely without reinventing it
Regards!
SaaĊĦha,
|
