- From: Martin Hepp <martin.hepp@ebusiness-unibw.org>
- Date: Fri, 22 Apr 2011 09:44:30 +0200
- To: Kingsley Idehen <kidehen@openlinksw.com>, Tim Berners-Lee <timbl@w3.org>
- Cc: public-lod@w3.org
Hi Tim, all: First: Thanks for your great feedback. As for labels vs. identifiers: What I want to do is change the identifier of a few conceptual elements. The reason why I also changed the labels in my example is that in GoodRelations, labels are historically geared towards the publisher of data and not the consumer and thus as close as possible to the identifier. Thus, we currently use - the original camel words for class labels, (e.g. "BusinessEntity") - the original camel words plus and indicator for cardinality information for properties (e.g. "eligibleRegions (0..*)") - the original camel words plus a hint to the most relevant class for an individual (e.g. "MasterCard (PaymentMethod)", even though gr:MasterCard is also an instance of gr:PaymentMethodCreditCard, but it is more important to know that it is a payment method) I agree with your suggestions to change the syntax in the labels from the camel words to regular spaces in between the words, but I want to keep the cardinality information for properties and the class membership information for individuals. Again, I think the perspective of someone coding / publishing data is more important that the consumption side, in my opinion, because in non-trivial data structures (e.g. relationships of higher arity), one cannot derive a meaningful user interface directly from the raw labels anyway. I assume that 90 % of the people consuming the GoodRelations specification, in both OWL and HTML, will be Web developers trying to encode data, not clients used for displaying the raw data. See inline comments for the remaining points. On Apr 21, 2011, at 11:15 PM, Kingsley Idehen wrote: > On 4/21/11 3:19 PM, Tim Berners-Lee wrote: >> Martin, >> >> Confused. >> Do you mean you want to change the localname (the bit after the namespace in the URI) or the label? Actually both, because they are the same in the case of GoodRelations, but the important thing is changing the localname so that coding in RDFa gets simpler and quicker. >> >> In your examples below, you have the same string for the localname and label. >> This looks like a bug. It was intended, but I see your point and share Kingsley's support for more readable labels. >> Let me explain things from the point of view of the tabulator, for example, >> which actually uses the rdfs:label for users. >> >> >> 0) if you want to change the label, don't change the URI. >> Keep the URIs the same, unless the meaning has changed, in which case make a new URI and keep the old one >> marked obsolete. The meaning has not changed, but I have to make coding in RDFa easier for common class names without breaking existing code or data. For example, GoodRelations uses, for historic reasons, a long name for stores, etc., which tries to capture the ontological essence: gr:LocationOfSalesOrServiceProvisioning It could not have been gr:Store, because this is basically and point of interest from which a product or service is available, including bus stops, gas stations, movie theaters, etc. But since this class is so frequently used, I want to change it to simply gr:Location while remaining as much of backward compatibility as possible; that is the background of the pattern I suggested. >> >> The actual string used in the URI has no meaning, it is just an identifier. Yes, thats clear. >> If it seems weird but people use it - make sure it is well documented but >> don't change it if there is data using it out there. Do make sure the labels track the >> meaning and usage. Well, in my case that would mean I cannot change a) gr:LocationOfSalesOrServiceProvisioning to gr:Location b) gr:ProductOrServicesSomeInstancesPlaceholder to gr:SomeItems and c) gr:ActualProductOrServiceInstance gr:Individual but I want to and will do that because the loss in backwards compatibility (if any) is minimal as compared to the increased ease of creating data, in particular in RDFa. Reducing the effort for lay Web developers to use SW tech is key. >> >> >> 1) Please use for the RDFS label what you would expect to see in a form which a user is filling in. >> Ideally give it in several languages. > +1 > As said, I am considering to change the formatting from camel word to non-camel style but keep the cardinality and class membership info for developers. The issue of several languages is, in theory, a nice feature, but extremely difficult to implement in six-sigma quality due to the differences in connotations and semantic granularity of natural languages. Having second-class translations would do more harm than good, in my opinion. The only reliable translations I could provide easily would be German, but that would really not increase adoption significantly - most German Web developers speak English. >> So gr:valueAddedTaxIncluded rdfs:label "includes VAT"@en, "TVA inclus"@fr . I am willing to change thus to "value added tax included" but want to avoid major differences between the identifiers and the labels, because someone using authoring tools should be kept familiar with the identifiers. >> >> This will be often shorter than a long URI localname >> >> The label has to be a reasonable prompt for the user, and not a complete explanation >> of what the field means. It should be usable also as a column heading in a table, >> for example. So while the URI is "gr:availableDeliveryMethods" the best label >> might just be "delivery methods". The longer string makes it clear for developers >> but the short label is quite explicit enough for a column header or field name in >> a report generated for a user. Well, from a perspective of consuming SW data in a tabular form, you are definitely right; however, I am not yet convinced that this is the most important use-case to address by rdfs:label in a Web ontology. >> >> >> >> 1.1) DO NOT do >> >> gr:appliesToDeliveryMethod rdfs:label "appliesToDeliveryMethod". >> >> This is worse than nothing. If you leave no rdf:label at all for gr:appliesToDeliveryMethod, >> then tabulator will synthesize a label "applies to delivery method" from the camel case. >> Actually on a form it will typically use the string "Applies to delivery method" >> as in English often form field names are capitalized. >> >> If you give an rdf label which actually is just the same as the URI localname, you are saying that >> that is the string which you recommend be used for the form. This will force tabulator >> to display the camel-case, which is not user-friendly. This is, IMO, a Tabulator-specific issue and only addresses the *consumption* of the data in a tool that directly uses the vocabulary labels for generating the user interaction. I am so far unconvinced that this is a dominant use-case for interacting with GoodRelations data. For example, a user seeing GoodRelations data via Google Rich Snippets or Yahoo SearchMonkey will never see the vocabulary labels, only the person configuring the generation of data. >> > > +1 > >> 2) Never put explanations for ontology engineers in the label. In the comment, OK, not the label. >> >> >> NOT rdfs:label "NewPropertyName1 (Note: See old URI foo:LongPropertyName1 used previously)" . >> but more like >> rdfs:label "new form label1"; rdfs:comment " (Note: See old URI foo:LongPropertyName1 used previously)" . >> >> You don't want that stuff showing up for users, in reports, forms, etc. As for the reference to the new element etc., I agree with you; that was just to keep the proposal short and simple. We will usually have a note "(DEPRECATED)" as part of the label, but no further explanation. It is pretty simple for and end-user tool to filter out the three patterns of developer information from GoodRelations labels by simple regex. Again, the majority of the people dealing with rdfs:labels from vocabularies will be developers, not end-users, because you will need an intermediate layer between the data and the user anyway. > > +1 > > Martin: > > In addition, if you are evolving the ontology (which I believe is the case) and seek to keep backward compatibility i.e., keeping classes and properties functional across ontology releases, just use owl:equivalentClass and owl:equivalentProperty accordingly. Naturally, if this evolution includes new levels abstraction then rdfs:subClassOf and rdfs:subPopertyOf should be put to use etc.. Yes, that was in my original proposal. > > We can't really negate reasoning, especially when showcases emerge that help general appreciation of OWL which (IMHO) continues to get an unjustified bad rap. Yes, I agree. I also think that since the little bit of reasoning needed in here can be easily implemented in SPARQL CONSTRUCT rules or SPIN, it is much better to take conceptually superior OWL axioms than "quick and dirty sameAs", which will backfire in the long run. Again, thanks for your detailed feedback! Martin > > Kingsley >> Tim >> >> On 2011-04 -21, at 14:28, Martin Hepp wrote: >> >>> Hi Bob, >>> Thanks! >>> >>> In my opinion, explicit versioning of ontologies should be avoided in general; rather, one should evolve deployed ontology in a backwards-compatible fashion only. While there is is quite some academic work on ontology versioning, fact is that in practice, if you use fine-grained versioning, the Semantic Graph will break more frequently and you will need a lot more inferred triples. >>> >>> So in GoodRelations, we use only one version of the ontology (http://purl.org/goodrelations/v1) and all modifications are as much backwards-compatible as possible. From time to time, we have widened the domain or range of a property from a single class to the union of multiple classes or other minor changes, but the side-effects of that are practically irrelevant, in particular if you judge them in the light of real-world data quality of WWW data. >>> >>> Thus, we do not use owl:priorVersion, owl:versionIRI, owl:backwardCompatibleWith etc., because it is still the same ontology. >>> >>> I intend to keep it like that ;-) >>> >>> It's only now that I would like to use shorter labels for 2 - 3 conceptual elements that are already in use, without forcing anybody to >>> >>> - update data or >>> - update derived ontologies or >>> - change queries. >>> >>> owl:sameAs for all classes, properties, and individuals would further reduce the type of reasoning needed to ensure backward-compatibility, but would at the same time turn GoodRelations into OWL Full. >>> >>> As for the SemWeb Vocab Status ontology: For keeping things simple, we just use owl:deprecated for the few elements that have been deprecated over time. From my perspective, the popularity / usage of an existing element is more important than the indicated degree of stability. >>> >>> Martin >>> >>> On Apr 21, 2011, at 2:43 PM, Bob Ferris wrote: >>> >>>> Hi Martin, >>>> >>>> I think this issue is also related to ontology versioning and assigning an applied version of an ontology in a dataset (see, e.g., [1]). >>>> OWL provides some properties to describe an version of an ontology, e.g., owl:priorVersion, owl:versionIRI, owl:backwardCompatibleWith (see [2,3]). However, all these relations have a range and domain of owl:Ontology. I'm unsure, whether you also like to type every property or class as an ontology (I think from a philosophical point of view this doesn't matter). >>>> So far your class and property alignment to prior versions looks good. Albeit, I would separate these axioms from the core ontology, because they are only need if one likes to process reasoning with backward compatible term definitions. >>>> Furthermore, you can make use of the SemWeb Vocab Status ontology [4] to mark an term, e.g., as 'archaic'. >>>> >>>> Cheers, >>>> >>>> >>>> Bob >>>> >>>> >>>> [1] http://answers.semanticweb.com/questions/2815/how-do-i-knowmodel-the-applied-version-of-an-ontology-specification >>>> [2] http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Ontology_IRI_and_Version_IRI >>>> [3] http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Ontology_Annotations >>>> [4] http://www.w3.org/2003/06/sw-vocab-status/ns# >>>> >>>> On 4/21/2011 11:46 AM, Martin Hepp wrote: >>>>> Dear all: >>>>> >>>>> I am considering to rename a few conceptual elements in the GoodRelations ontology. However, they are already in use in data, queries, and applications. Thus, I am thinking of the least intrusive way of implementing this. I think this question is also relevant for many other OWL vocabularies on the Web. >>>>> >>>>> Attached, please find my proposal. It critically depends on the ability of typical triple-stores to compute basic(*) inferences for >>>>> >>>>> - owl:equivalentProperty for owl:DatatypeProperty and owl:ObjectProperty entities, >>>>> - owl:equivalentClass for pairs of owl:Class and >>>>> - owl:sameAs for pairs of "ontological" instances, e.g. value nodes defined in the vocabulary. >>>>> >>>>> With "basic", I mean that additional triples for the additional class membership or property or instance must be materialized; this could be a subset of the complete theoretical implications. >>>>> As far as I know, Virtuoso does support this to a sufficient degree, but I am unsure about other parts of widely deployed infrastructure. >>>>> >>>>> It would be no problem to express the necessary inferences by means of a SPARQL CONSTRUCT rule or in SPIN. >>>>> >>>>> Please share any suggestions and concerns with me. >>>>> >>>>> Old, but in use: >>>>> --------------- >>>>> foo:LongClassName a owl:Class ; >>>>> rdfs:label "LongClassName" . >>>>> >>>>> foo:LongPropertyName1 a owl:DatatypeProperty ; >>>>> rdfs:domain foo:LongClassName ; >>>>> rdfs:label "LongPropertyName1" . >>>>> >>>>> foo:LongPropertyName2 a owl:ObjectProperty ; >>>>> rdfs:domain foo:LongClassName ; >>>>> rdfs:range foo:SomeOtherClass1 ; >>>>> rdfs:label "LongPropertyName1" . >>>>> >>>>> foo:LongNameIndividual a foo:SomeOtherClass2 ; >>>>> rdfs:label "LongNameIndividual" . >>>>> >>>>> Now, we want to rename those elements as follows, without breaking old data nor old queries / applications: >>>>> >>>>> foo:LongClassName --> foo:NewClassName >>>>> foo:LongPropertyName1 --> foo:NewPropertyName1 >>>>> foo:LongPropertyName2 --> foo:NewPropertyName2 >>>>> foo:LongNameIndividual --> foo:NewNameIndividual >>>>> >>>>> Proposal: >>>>> -------- >>>>> a) Step 1: Define new classes, properties, individuals and link back to their old variants >>>>> >>>>> foo:NewClassName a owl:Class ; >>>>> owl:equivalentClass foo:LongClassName . >>>>> rdfs:label "NewClassName (Note: This was foo:LongClassName previously)" . >>>>> >>>>> foo:NewPropertyName1 a owl:DatatypeProperty ; >>>>> owl:equivalentProperty foo:LongPropertyName1 ; >>>>> rdfs:domain foo:NewClassName ; >>>>> rdfs:label "NewPropertyName1 (Note: This was foo:LongPropertyName1 previously)" . >>>>> >>>>> foo:NewPropertyName2 a owl:ObjectProperty ; >>>>> owl:equivalentProperty foo:LongPropertyName2 ; >>>>> rdfs:domain foo:NewClassName ; >>>>> rdfs:range foo:SomeOtherClass1 ; >>>>> rdfs:label "NewPropertyName2 (Note: This was foo:LongPropertyName2 previously)" . >>>>> >>>>> foo:NewNameIndividual a foo:SomeOtherClass2 ; >>>>> owl:sameAs foo:LongNameIndividual ; >>>>> rdfs:label "NewNameIndividual (Note: This was foo:LongNameIndividual previously)" . >>>>> >>>>> b) Step 2: Deprecate the old elements in OWL 2 style (using owl:deprecated) >>>>> foo:LongClassName a owl:Class; >>>>> owl:deprecated true; >>>>> rdfs:label "LongClassName - Deprecated, use foo:NewClassName instead" . >>>>> >>>>> foo:LongPropertyName1 a owl:DatatypeProperty ; >>>>> owl:deprecated true; >>>>> rdfs:domain foo:LongClassName ; >>>>> rdfs:label "LongPropertyName1 - Deprecated, use foo:NewPropertyName1 instead" . >>>>> >>>>> foo:LongPropertyName2 a owl:ObjectProperty ; >>>>> owl:deprecated true ; >>>>> rdfs:domain foo:LongClassName ; >>>>> rdfs:range foo:SomeOtherClass1 ; >>>>> rdfs:label "LongPropertyName1 - Deprecated, use foo:NewPropertyName2 instead" . >>>>> >>>>> foo:LongNameIndividual a foo:SomeOtherClass2 ; >>>>> owl:deprecated true ; >>>>> rdfs:label "LongNameIndividual - Deprecated, use foo:NewNameIndividual instead" . >>>>> >>>>> c) Since the owl:deprecated property is not defined in OWL1, I would also add the following axiom in order to remain within OWL 1 DL: >>>>> #OWL 1 DL compatibility of the OWL2 deprecated property >>>>> owl:deprecated a owl:AnnotationProperty. >>>>> >>>>> Thanks in advance! >>>>> >>>>> Best >>>>> >>>>> Martin >>> >>> >> >> > > > -- > > Regards, > > Kingsley Idehen > President& CEO > OpenLink Software > Web: http://www.openlinksw.com > Weblog: http://www.openlinksw.com/blog/~kidehen > Twitter/Identi.ca: kidehen > > > > > >
Received on Friday, 22 April 2011 07:44:57 UTC