Sorry, I just forgot:
Of course we can provide guidelines and S/W how to query all names etc.
We can hardly forbid CRM users to put appellations into rdfs:label.
So, how do this problem solved in OWL? Those of you opposing to the
superproperty hack, how do you solve the query question?
Best,
Martin
On 9/9/2021 11:12 PM, Martin Doerr wrote:
Dear Robert, Mark,
Of course this is not elegant schema design. Unease is accepted, but
what are the alternatives??
On 9/9/2021 10:30 PM, Robert Sanderson wrote:
As expected, it entails the nonsense that the literal "fish"@en is an
E1, E41, E90, etc. which is garbage caused by this pollution in the
ontology, as literals cannot be the subject of triples.
This is, in my eyes, not nonsense, but simply reality. The literal
"fish" is used as a name. Hence it is ontologically an E41. Following
the definition of E90, "fish"@en is also symbolic object, regardless
whether one distinguishes data objects and literals. Note, that the
definitions of the CRM are ontological, not syntactic in the first place.
This is a classical problem of data integration, and why formal
ontologies were invented. Literature in the 1980ties discussed that
classes can be hidden in boolean values, strings, or be explicit
tables. There is an arbitrary decision of applications to name things
via labels, or via classes in RDF/OWL. SKOS exclusively names things
via labels.
So, if one makes a knowledge base that commits to the CRM, I would
like to have a query that returns all names in the whole world I can
reach, regardless what encoding variant and KR paradigm is used.
Otherwise, SKOS names will not be appellations.
Alternatively, we close our eyes, and hard code in data entry and
query that "fish" is used as Appellation, but just don't write it down.
@en actually is equivalent to "has language" etc. With these hidden
properties RDFS itself violates the separation of Literals and data
objects. It opens up a whole world of user-defined data objects
within Literals, with no logical connection to the data objects. This
is nothing than a bad later patch to a problem not initially
anticipated. How are these compatible with OWL reasoners?
There is no elegant solution to providing an ontology that describes a
reality based on FOL to fitting it exactly with Schema languages.
At least, this is how I perceive this problem, having seen enough
knowledge representation languages and information integration
literature from the eighties and implementations from the nineties on.
For me, the question is completely practical: We have a CRM compatible
KB, a real platform. What is the simplest form that I get all names in
the KB back? I have not seen a whole "RDF" world that my statement
label IsA P1 would turn upside down. Do you have one?
Best,
Martin
Hope that helps explain my unease!
Rob
--
------------------------------------
Dr. Martin Doerr
Honorary Head of the
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
Vox:+30(2810)391625
Email: [email protected]
Web-site: http://www.ics.forth.gr/isl
_______________________________________________
Crm-sig mailing list
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
