|
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.
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@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/
|