Dear Robert,
What you do here is the standard procedure and exactly the right decision:
The standard CRM relies on multiple instantiation. The standard CRM is
concerned with logic, and not with various platforms.
The standard platform would be an OWL/RDF supporting system. For any
other platforms not supporting multiple instantiation,
you introduce for each combination necessary a new subclass in your
local system. This does not need any particular modelling discussion.
This maps identically and without loss of meaning to the standard. Note
that any system is standard compliant that maps to the standard, and NOT
that its internal structure is that of the standard.
The CRM can only be maintained as a standard, if this differentiation of
implementation from logic is maintained and well understood by users and
developers.
I hope that all CRM users understand that replacing multiple
instantiation by multiple IsA at the standard level is definitely
impossible to maintain. Non-believers may provide us with a
comprehensive list of candidates!;-)
All the best,
martin
On 9/13/2017 7:49 PM, Robert Sanderson wrote:
After working through all of the possible options, we’ve decided to create our
own class “Name” that we would propose be used in implementations for
Linguistic Appellations (e.g. pretty much all of them that are not Identifiers,
as far as we can tell).
The options, and the rationale for the decision:
* Multiple Instantiation: We rejected this approach not because of the
philosophy, but because a scan of implementations showed none that support it
in practice. Yes, the assertion can be captured in a triple store, but once you
try to do anything outside of merely recording it, implementations picked one
of the classes (typically at random) for the programming level object to be an
instance of. This, to us, is a very strong indication that MI is an
anti-pattern that should be avoided, and replaced with Multiple Inheritance to
a single class.
* Associate multiple languages as literals (of datatype rdf:langString) with
the Appellation. This would let us record the language along with the value. We
rejected the approach as not allowing for valuable use cases, such as recording
which name forms are translations of which, and being inconsistent with the
patterns for Linguistic Objects. Consistency is very important when it comes to
ease of use, and two patterns for pretty much exactly the same scenario is a
costly exception. An additional consideration is that JSON-LD 1.0 doesn’t have
great support for situations where there are both values that have languages
and values that do not, generating unintuitive JSON constructions.
* Use a new predicate from Appellation for language, such as dc:language or
schema.org:inLanguage. Again, this would be entirely inconsistent with the use
of P72 has language and create confusion as to when to use which pattern. An
additional consideration is that JSON-LD 1.0 doesn’t allow for the same key to
be used to map to different predicates in different classes, which would let us
at least hide the inconsistency from developers. Both of these are fixed in
JSON-LD 1.1, but it’s still early days in the W3C process for that and
implementations don’t support them yet.
* Ignore the scope notes and use Title for all Linguistic Appellations. This
would be both unintuitive and horribly inconsistent with systems that use Title
following its official semantics.
* Not associate language with Appellations at all. This is also a terrible
non-solution for any international system.
* Introduce a new class, which is a sub class of both Appellation and
Linguistic Object… which is what we’ve done. The challenge is that systems
that do not process the ontology will not realize that Name is really just an
Appellation with the additional necessary functionality for languages. If there
was a CRM ontology class, we would not need to do this.
For consistency, we will also create another class for the combination of End
Of Existence plus Activity, to prevent the multiple instantiation problem there
as well.
Thanks,
Rob
On 9/12/17, 9:01 AM, "Crm-sig on behalf of Robert Sanderson"
<[email protected] on behalf of [email protected]> wrote:
Yes, I understand that a single instance can have multiple classes – for
example Destruction + Activity. If that’s the recommended approach, that’s
what we’ll work with.
Thanks Martin!
Rob
On 9/12/17, 3:06 AM, "Crm-sig on behalf of martin" <[email protected] on behalf of [email protected]> wrote:
Dear Robert,
This is a basic question of modelling methodology, which must be clearly understood by those using any current formal ontology. We are modelling under the "Open World Assumption". This means that anything
not said may be true or false, but never false per rule. If something
is an instance of a class A, it does never imply that it cannot be an instance
of a class B
at the same time, except if we declare these classes as "disjoint".
Hence, Appellation being not a subclass of Linguistic Object, does not mean that it is not a Linguistic Object. It means that an instance of Appellation
may or may not be a Linguistic Object, and many other things not said.
A Title on the other side is
defined to be always a Linguistic Object.
If an instance of Appellation, such as "information science" happens to be a
Linguistic Object, you declare it to be instance of both classes, which is standard RDF/OWL. This
is called "multiple instantiation"
Title in the CRM has a more specific sense than just being a Linguistic Object and Appellation. We do not declare subclasses of combinations of classes just for the sake of an accidental combination. It would fill the CRM with some thousand classes without
particular meaning. You can do that for your own convenience in a
local extension. If title were indeed regarded only an accidental combination
of Appellation and Linguistic Object, it has to be deleted from the CRM.
So, there is neither an intellectual nor technical issue to it, as far as I understand:-).
All the best,
Martin
On 9/12/2017 12:50 AM, Robert Sanderson wrote:
Dear all,
Is there a reason why only Titles are also Linguistic Objects?
The examples of Appellation:
"the Forth Bridge"
"the Merchant of Venice" (E35)
"Spigelia marilandica (L.) L." [not the species, just the name]
"information science" [not the science itself, but the name through
which we refer to it in an English-speaking context]
“安” [Chinese “an”, meaning “peace”]
All of these Appellations are in a language (English, Latin, and Chinese) but only “The Merchant of Venice” can have its language explicitly declared, as Titles are also Linguistic Objects.
If Appellation was a subclass of Linguistic Object (as a descendent of Symbolic Object) then this issue would go away. And also make Title just a P2 of Appellation, rather than a special case.
Alternatively, Title could be re-described to cover all Appellations with language, whereas E41 would be for Appellations like identifiers that do not have linguistic content.
Rob
_______________________________________________
Crm-sig mailing list
[email protected]http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
--------------------------------------------------------------
Dr. Martin Doerr | Vox:+30(2810)391625 |
Research Director | Fax:+30(2810)391638 |
| Email: [email protected] |
|
Center for Cultural Informatics |
Information Systems Laboratory |
Institute of Computer Science |
Foundation for Research and Technology - Hellas (FORTH) |
|
N.Plastira 100, Vassilika Vouton, |
GR70013 Heraklion,Crete,Greece |
|
Web-site: http://www.ics.forth.gr/isl |
--------------------------------------------------------------
_______________________________________________
Crm-sig mailing list
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
--------------------------------------------------------------
Dr. Martin Doerr | Vox:+30(2810)391625 |
Research Director | Fax:+30(2810)391638 |
| Email: [email protected] |
|
Center for Cultural Informatics |
Information Systems Laboratory |
Institute of Computer Science |
Foundation for Research and Technology - Hellas (FORTH) |
|
N.Plastira 100, Vassilika Vouton, |
GR70013 Heraklion,Crete,Greece |
|
Web-site: http://www.ics.forth.gr/isl |
--------------------------------------------------------------
