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/
|
_________________________________________________________________
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/ (01)
|