|
Dear
Hongsong,
Could you
please tell us which of the two identification schemes would be best for the
average Chinese engineer:
1) an RDL class identifier rdl:RDS902699 with a
skos:prefLabel "MULTI-STAGE IMPELLER BETWEEN BEARINGS RADIAL SPLIT DOUBLE CASING
CENTRIFUGAL PUMP" and a Chinese skos:altLabel "多级叶轮两端支承径向剖分双壳离心泵"
(I hope Google translated this correctly)
2) an RDL class
identifier
rdl:MULTI-STAGE_IMPELLER_BETWEEN_BEARINGS_RADIAL_SPLIT_DOUBLE_CASING_CENTRIFUGAL_PUMP
with a Chinese skos:altLabel "多级叶轮两端支承径向剖分双壳离心泵"
People who
speak English because that is their native tongue sometimes have a tendency to
neglect the interests of the rest of the world. So I ask from you to represent
that rest of the world and tell us what you think about this. Being involved in
the Chinese software industry makes you a perfect
representative.
I hope you
will cooperate, and any of those two alternatives is OK with me if it is OK for
you.
Regards,
Hans
Hans Teijgeler,
Laanweg 28,
1871 BJ Schoorl,
Netherlands
On 30 Jan 2014, at 14:20, Hans Teijgeler wrote:
Dear David and Matthew,
Using a non-humanreadable string for an ID has its
merits, that are probably not the first thing you, both English speaking,
would think of. If I refer to RDS45093 a person whose native language is not
English can refer to a translation of the skos:prefLabel (in English) in
his/her language, if provided by their standardization body or else. If we
would start with IDs in English we would be in deep trouble in certain regions
of the world.
Next to the ID you can have one skos:prefLabel per ID and as
many skos:altLabels as you need.
Hi Hans,
For data, artificial URIs are fine. For classes and properties in an
ontology they are not. Even a non-English speaker will have better luck
distinguishing PersonOrOrganization vs Organization rather than RDL94950595 vs
RDL9459869 when reviewing an ontology or writing SPARQL. Adding properties as
labels useful for presentation in a user interface does nothing wrt the issue I
raise.
Cheers,
David
Regards,
Hans
Hans Teijgeler,
Laanweg 28,
1871 BJ Schoorl,
Netherlands
Dear
David,
I
sympathise. When the decisions were made, the ID attribute was seen as a value
that would only be used in databases as a unique key, and never seen by
humans, with a relationship to a human readable name (or names). Although we
did at least make the ID a STRING, so there is no particular restriction on
what can be used. I would quite expect developers to use their own identifier,
or a name from the RDL as their identifier if that were convenient. In the new
world, human readable identifiers, especially for classes, are probably more
important.
Regards
Matthew
From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of David Price
Sent: 30 January 2014
10:46
To: Ontology
Summit 2014 discussion
Subject: Re: [ontology-summit]
[ReusableContent] Partitioning the problem
On
30 Jan 2014, at 08:59, Matthew West wrote:
I
agree with Ed that we are talking past each other ? which is clear from what
you write below.
Since
we are not actually disagreeing, I won’t respond to what you have below, but
I will just make two comments.
1. The
names of predicates are just labels, they formally mean just what they mean
if you replaced them with numbers.
2. It
is of course helpful to use labels that guide the human reader towards the
intended interpretation. This is relatively easy with small ontologies, but
as ontologies get larger it becomes harder to retain readability with
consistency in naming and being unambiguous.
But
2 is the case when it's most important to help the human. People can all keep
20 numbers in our heads, but not 20000. I speak from experience in
developing apps that are based on SPARQL over a 15926-based ontology. Without
human readable URIs, it's simply impossible. Imagine telling Java developers
all their classes had to be of the form "C1231231" ... you'd get laughed out
of the room. Don't ontologists deserve at least the same respect given to Java
developers?
As
a real-world example, we have projects that require developing maintainable,
production-worthy software over OWL and we use a lot of SPARQL. It's based on
ISO 15926 but we we cannot directly use *any* 15926 reference data in our
ontology because all the RD URIs are numbers and that makes the SPARQL
completely opaque :-(
Sensible
partitioning of large ontologies (or reference data) using namespaces to
enable human readable URIs is a show-stopper requirement from
implementors.
This
email originates from Information Junction Ltd. Registered in England and
Wales No. 6632177.
Registered
office: 8 Ennismore Close, Letchworth Garden City, Hertfordshire, SG6
2SU.
On 1/29/2014 5:47 AM, Matthew West
wrote:
Hi Mathew,[MW>] (Matthew)
Thank you for your patient explanations. On the
list just last week was an exchange about namespace identifiers, and it
was claimed there is no semantic definition for such; well, 15926's
LeftNamespace and RightNamespace proves that assertion wrong I
guess.
[MW>]
No, I’m afraid not. ISO 15926 treats strings as first class objects that
can be used to represent other objects. The semantic connection comes from
the relationship, not the strings themselves. This bit of the model is
just about string processing.
As for reuse, my understanding about First Order
Logic is that all properties are requred to be
predicators;
[MW>]
This is not true. It is for example quite permissible to make
Classification a predicate, and associate all you properties to objects
using the classification predicate.
JMc: Matthew, it is true. (Btw, your 'Classification'
is a defined Class, so it cannot be a
predicate in a triple.) I again cite Wikipedia: "the predicate of a
sentence corresponds ... to the main verb and any auxiliaries that accompany
the main verb, whereas the arguments of that predicate (e.g. the subject
and object noun phrases) are outside the predicate".
And this makes good sense.
It'd be a stunningly hobbled descriptive logic when the only way to know
that a resource participates in a given type of relation is by stating a
specific instance of the relation in which the resource
participates.
Example: if "isFatherOf" is said to be a valid
relation between A & B, how can know that A is a "Father" without
referencing an "A isFatherOf B" statement? However if predicates were
coordinate with *the rule* then the statement "A is-a Father" exists with
or without a statement that "A has-this C" where "C is-a Child" and "C
is-this B". Note that all predicates are verbs. IOW "isFatherOf" is
merely shorthand, in
no way definitive itself.
I maintain this odious shorthand completely screws up
the industry as these non-English psuedo technical artificially-intelligent
programmer words like "isFatherOf" overwhelm us like bunnies. It's so bad
now we need tools to help us understand our own damn language - what a
towering joke it all is-a!
15926's are not -- instead they are all camelcased
phrases, predicatorNouns, as is the common practice
elsewhere.
[MW>]
Well the format is usually defined by the language/tool used, many of
which use space as a separator, so you need to use e.g. camelcase or
underscores to make multiword terms readable.
JMc: little wonder SMEs are nauseated when asked to
confront the resulting nightmare of a vocabulary. (BTW,
semantic wikis handle spaces quite
easily.)
It is one's use of those nouns in object properties
in my opinion that eliminates reuse of very substantial bodies of work
like 15926. But as you say 15926 had no design intention for reuse, that
to the extent it occurs is pure serendipity.
[MW>]
That is incorrect. ISO 15926 was defined for reuse, just not for piecemeal
reuse I combination with other ontologies. It has been reused as intended
(usually subsets) and it has also been reused in a piecemeal way with
other ontologies ? despite that not being the design intent ? only that
last was serendipity.
But if 15926 were constrained to use predicators
for all relations, I'd expect its reuse to be less
random.
[MW>]
Actually I disagree. I think that defining just one or two predicates like
classification has made it much easier to create a regular and more
portable ontology, though that was not why we did it. ISO 15926 was
originally created using entity relationship models, and other
considerations lead to us taking the particular approach we did, in
particular that one entity type cannot be a member of
another.
JMc: Your "Classification" is not a defined object
property; it is a defined class. "Classification" cannot be used as a
predicate in a triple/statement.
In fact it would then conform to the rule that FOL
predicates are predicators not nouns. I mean all predicators, no nouns.
Said differently, here's the rule: no nouns, only
predicators.
[MW>]
That is OK as long as you can say what a predicator is. I have struggled
to get a good answer to that question from even the wisest heads on this
forum. My take is that predication is the same as classification as near
as makes no difference, but I suspect there is some slight
difference.
Perhaps you've missed the recent threads where I've
given links to Free Dictionary, Wiktionary and
Golds. Predicators have nothing to do with
classification.
Why is this good valid rule with many beneficial
consequences violated, even by RDFS?
[MW>]
It’s not FOL, that’s why.
I'm told RDF was meant to be a proper subset, to avoid
the so-called complexity of FOL and its tools.
So often the 'noun' in the object property is exactly
the Class referenced by the rdfs:range for the object property -- 15926
does that rather consistently. Hmm, let's go further and name properties
per their domain too! "domainPredicatorRange" -- just what we did in the
bad old days of C data structures, prefixing members with the name of the
structure, sometimes with the predicator "is" and sometimes with "has" all
separated with underscores.
[MW>]
That would be a mistake, the role played by the range would be more
appropriate ? which is what we do in ISO 15926.
But we're semanticists now, so let's not be
caught with properties like "approval", much better to say "hasApproval"
-- at least we're not saying "designApproval" or "designHasApproval" or
several others. It's got the predicator in there, so what's the damn
problem?
[MW>]
As I said the original is approval and class of approval. You will find
both the range and domain, and the role played them also there. You should
do your homework before you offer criticisms.
Oops, I meant hasApprover which, just now rechecking,
is definitely in the published ontology. Whichever makes no difference to my
point, that there are many ways to state the relation, but only one is
correct if *the rule* is followed.
Oops, here's the
problem:
Forgetting the rules = Having no rules = No
reuse.
[MW>]
Which might mean something if anything you said above was correct. So I
wonder how you account for ISO 15926 having been reused on some hundreds
of projects over the last 10+ years?
So you'd agree that if what I've said above is correct,
then this formulation is meaningful, regardless of anecdotes. Fine, then
we'll focus on whether the rule is a rule, or not. Then we'll focus on what
'breaks' the rule.
This
email originates from Information Junction Ltd. Registered in England and
Wales No. 6632177.
Registered
office: 8 Ennismore Close, Letchworth Garden City, Hertfordshire, SG6
2SU.
Thanks/jmc
_________________________________________________________________ Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/ Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/ Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx Community Files: http://ontolog.cim3.net/file/work/OntologySummit2014/ Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2014 Community Portal: http://ontolog.cim3.net/wiki/
_________________________________________________________________ Msg
Archives: http://ontolog.cim3.net/forum/ontology-summit/ Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/ Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxxCommunity
Files: http://ontolog.cim3.net/file/work/OntologySummit2014/Community
Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2014 Community Portal: http://ontolog.cim3.net/wiki/
|