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
>
>
>
>
>
>
