Situation: I define a class, and instances of this class are likely to have a title. I want to say that, - when giving a title to an instance of this class, one should use dc:title - when searching for instances of this class by title, one will get good results using dc:title

Some ideas: - I can add a dc:comment to the class, but that's not machine understandable - I can create a myTitle property, with range MyClass, and make it a subProperty of dc:title. But this requires some work when handling the queries (I can then have instances with either dc:title or my:myTitle) - I can make MyClass a subclass of the things which have a dc:Title - but not all instances of MyClass have a title

What do you suggest? TIA

asked 16 Jul '11, 05:41

fps's gravatar image

fps
9115
accept rate: 0%

edited 17 Jul '11, 18:02

Thanks for the answers, all interesting. There is some ambiguity in the title of my question: "recommend or require" are different things. I am currently more concerned by the way to "recommend", but also interested in the constraint checking. I understand the "fact vs requirement" discussion about OWL semantics. However, knowing the fact, for instance, that any instance of AClass has a dc:title is a very useful hint when setting up a GUI to help creating instances, or when writing SPARQL queries. (Note that this is not exactly what I want to say about MyClass, but that's not the point here)

(17 Jul '11, 18:44) fps fps's gravatar image

In Anzo, we do this via property restrictions, though I don't know how legit this is. So we'd do:

ex:myClass rdfs:subClassOf [
   a owl:Restriction ;
   owl:onProperty dc:title ;
   owl:minCardinality 0
]

...which, semantically speaking, really doesn't say anything at all (I think), but which our tools interpret as a hint to consider using this property (dc:title) in conjunction with this class (ex:myClass).

link

answered 17 Jul '11, 09:37

lee's gravatar image

lee
3.2k39
accept rate: 37%

Such a min-0 cardinality restriction is semantically void, so it is essentially really only a - somewhat complicated - hint; and tools need to be prepared to see this construct to make use of the hint, which I consider rather unlikely in general. Also, when being used in OWL DL, you have to ensure that dc:title is declared as either a owl:DatatypeProperty or a owl:ObjectProperty; if it is declared as an owl:AnnotationProperty, then you cannot use it this way (not even in OWL 2 DL).

(17 Jul '11, 11:51) Michael Schn... ♦ Michael%20Schneider's gravatar image

That's right, in the absence of a standard way to do this, it's a hint only. We don't really ever use DL reasoning, so that particular aspect isn't an issue for us; if it were, I suppose we would simply add axioms that declare dc:title as an owl:DatatypeProperty.

It's not clear to me whether there's any meaningful difference between using the OWL vocabulary in this way to convey this hint versus inventing new (annotation) vocabulary. Either way, any tools that want to interoperate need to understand the hint.

shrug

(17 Jul '11, 12:39) lee lee's gravatar image

Both TopBraid Composer and its predecessor, Protégé, use this hint. It is of pragmatic use for creating class members, i.e. via filling in a form, and works well.

(17 Jul '11, 14:18) scotthenninger ♦ scotthenninger's gravatar image

Awesome! Hurrah for unintended interoperability!

(17 Jul '11, 14:23) lee lee's gravatar image

Lee, I like very much your answer. Indeed it doesn't seem to add anything, but is a very useful hint - including for humans. It creates a link between the class and the dc:title property. As an example, I tried loading it in Protégé 4.1, expecting to get "dc:title" listed in the "class usage" panel for MyClass. But I seem to get a NullPointerException instead (too bad!)

(17 Jul '11, 19:41) fps fps's gravatar image

Here's my suggestion: Don't try to make such "recommendations" part of the model itself. What you are about here is a "soft" pragmatic aspect of your model ("one should use dc:title to enable search engines to get the most out of it"), but when you add axioms, then you make it into a "hard" semantic aspect. Instead, write up a "best practices" document, explaining what should be done, and maybe implement some lint-style checking tool to be used by others for checking that these best practices are being applied. If not, then this tool should give a warning, which is a lot better than having direct semantic consequences, such as an inconsistent knowledgebase, which may stop people from doing what they want to do, because they may have their good reasons not to follow your recommended best practices.

An alternative would be to introduce a special set of OWL annotations to indicate what should be done. OWL already has annotations for deprecation and for (in)compatibility between ontologies, which do not have a real effect on the model, and one could easily extend this set of annotations to whatever one wishes to have. One could and should do this outside the core OWL standardization process and may do it even outside W3C, but it would require some kind of standardization effort to make it into something that is widely used. So this would certainly be more of a future thing.

link

answered 17 Jul '11, 11:44

Michael%20Schneider's gravatar image

Michael Schn... ♦
6.1k1612
accept rate: 34%

I believe the SO is looking for some way to make the constraints machine interpretable, not just recommended practice documents. As you state, one needs to look outside of OWL for such solutions. OTOH, SPIN constraint checking is built for just this use case.

(17 Jul '11, 14:25) scotthenninger ♦ scotthenninger's gravatar image

So the question is that you want to communicate to the modeler that they should use dc:title, and you want some machine operable way to detect when this convention is violated. Using RDFS/OWL you could set up a way to create an inconsistency when dc:title is missing. For example, infer all members of classes without a dc:title to be members of some "non-title" class and assert that all classes are owl:disjointWith that class. Any instance that is a member of the "non-title" class and one of the classes it is disjoint with will be flagged as an inconsistency.

There are two issues with that solution. First, computing complements in OWL is both troublesome (some may disagree with me on this) and computationally expensive. Second, reasoners tend to poorly support how inconsistencies are reported. At best you will get a list of model inconsistencies that include your convention and you get to sort out which ones you want to expose to the modeler creating the instance.

An alternative, which is more general than the notion of model consistency, is the SPIN notion of constraint checking. This defines a constraint check in a SPARQL query that can directly specify the semantics you need. For example, your rule would be:

# instance must have a dc:title property
ASK WHERE
{  FILTER NOT EXISTS  { ?this dc:title ?title .} .  
}

The rule is defined for a class and is applied to all members of the class, pre-binding ?this to each instance before running the rule. Any instance not having a dc:title is flagged as having a constraint violation. This could be displayed on the instance view of your editor. TopBraid Composer and the Web-based application builder TopBraid Ensemble both do this. I.e. when the user creates an instance and forgets dc:title, a warning appears in the view. In addition the comment line is used in the warning, giving you a way to communicate the rule's intent. (I work for TopQuadrant, so feel free to ask more questions here or on our forum.)

Either of these approaches would work, but I find the consistency check method to be more aligned with your needs.

I worry about the statement

I can make MyClass a subclass of the things which have a dc:Title - but not all instances of MyClass have a title
…as it seems to assume that instances inherit object attributes. This is simply not the case in RDFS/OWL. Unlike attributes in OO modeling, adding a property to a class definition in RDFS/OWL will have NO IMPLICATIONS on instances. Instances can have any eoprrties and the only way it is known that an instance is a member is through the type triple - {:thing rdf:type :someClass}. You may understand this already, but I'm not getting the gist of the solution you propose so I thought I'd throw this out as a possible misconception.

link

answered 16 Jul '11, 14:20

scotthenninger's gravatar image

scotthenninger ♦
7.5k813
accept rate: 17%

edited 18 Jul '11, 11:29

You cannot specify in RDFS/OWL that a title has to be provided. You cannot impose anything to be provided. OWL just expresses facts and facts are independent of what is provided. As a side note, complement is really not an issue, not any more than intersection, union, quantifiers etc. What creates computational issues is the combination of certain constructs. Concerning your last paragraph, I have the impression that you may have a possible misconception. Depends what you mean by attribute (a notion that does not exist in OWL).

(17 Jul '11, 05:14) Antoine Zimm... ♦ Antoine%20Zimmermann's gravatar image

Consider fps statement: "I can make MyClass a subclass of the things which have a dc:Title." This means that all instances of MyClass have a dc:title. It's a fact, not a requirement. To be clearer, it's like saying "all Persons are things that have a birthday". It's a fact that does not impose anyone or anything to provide a birthday. But you know that all instances of Person do have a birthday. And this has consequences on all the subclasses of Person. Moreover, attributes of instances (if I interpret the term correctly) do have a consequence on the type of the instances.

(17 Jul '11, 05:20) Antoine Zimm... ♦ Antoine%20Zimmermann's gravatar image

My use of the term "attribute" was to point out that OO semantics of instantiation do not apply here. I was trying to understand the expectations from the SO. Your points are well-taken and well-known.

(17 Jul '11, 14:22) scotthenninger ♦ scotthenninger's gravatar image

Edited last para for clarity per comments by @Antoine.

(17 Jul '11, 18:37) scotthenninger ♦ scotthenninger's gravatar image

@scotthenninger That ASK query is somewhat pointless since it will always evaluate to true. The algebra is Minus(Bgp({}), Bgp({this dc:title ?title})) - since the two sides are disjoint the minus has absolutely no effect so the result of the LHS will be returned, evaluating an empty BGP should always return identity which implies true for an ASK i.e. your query is equivalent to ASK WHERE {}. If you want to write a constraint like this you'll need to use a filter with an EXISTS or NOT EXISTS as appropriate

(18 Jul '11, 04:22) Rob Vesse ♦ Rob%20Vesse's gravatar image

Ah, yes, this is one of those corner cases where they differ. Edited for correctness.

(18 Jul '11, 11:27) scotthenninger ♦ scotthenninger's gravatar image
showing 5 of 6 show 1 more comments
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "Title")
  • image?![alt text](/path/img.jpg "Title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Tags:

×595
×44

Asked: 16 Jul '11, 05:41

Seen: 1,635 times

Last updated: 18 Jul '11, 11:29