Re: ISSUE-3: REPORTED: Lack of anonymous individuals

Sorry to be very late in answering this, I was on a long trip in Asia,
and just got back home.

I think it is a bit more than a migration problem. Indeed, if we make
this decision (dropping bnodes from OWL1.1) this would be valid (I
presume) for the various tractable fragments, too. And while it is
probably true that big ontologies will not be authored by hand but via
various tools and/or using the functional syntax, this may _not_ be the
case if one just uses 1-2 OWL constructs in a very minimal level
tractable fragment (the RDFS fragment of the submission, something like
what is now called OWL Horst, or something similar). We all know the
huge importance of those in practice and I do not expect authors using
that level of OWL1.1 to use, say Protege. They will encode their
ontologies directly into RDF/XML and/or Turtle (I know this is what I
would do...; the latest evolution of the POWDER specification[1] is also
a good example for such 'minimal' usage). And at that point the
clumsiness and ugliness of, say, the Turtle encoding (as shown by Alan),
the necessity of coming up with new URI-s all the time, etc, become a
major drawback. We might shoot in our own feet, ie, killing the
simplicity we are looking for in those fragments...

Ivan

[1] http://lists.w3.org/Archives/Public/public-powderwg/2007Nov/0033.html

Alan Ruttenberg wrote:
> 
> As I said, I think this goes halfway to solving the problem, though I'd
> be curious about what others think.
> 
> As for the other half, your comment about repair/FAQ in the previous
> message makes me wonder whether it might make sense to formalize a set
> of standard repairs, defining exactly what the suggested repairs are and
> consequences thereof.
> 
> Maybe we could call this a "profile" or somesuch, giving tool providers
> sanction to perform these repairs when users explicitly ask for RDF/RDFS
> to be reasoned with under the closest OWL-DL semantics possible.
> 
> I suggest this because even though such repair services are offered by
> some tools, it isn't always clear what they are doing. Also, having this
> in the specification might allow more developers who want or need to use
> RDFS for other reasons (can't see why they would, personally :) to do
> so, while still making provision for users who wished to use the
> stronger inference capabilities available in DL reasoners. Viewed in
> this context, translating bnodes into skolems would be one more "repair".
> 
> In other words, it provides a way for there to be a simpler migration
> path for users of RDF/RDFS who are intrigued by OWL, but not ready to
> commit to changing their vocabulary.
> 
> I guess I would be rather curious about Jeremy's, Ivan's, and Jim's 
> opinion about whether this would seem like a good idea. From the DL side
> of things, I can't see it being much of a problem.
> 
> -Alan
> 
> On Nov 13, 2007, at 12:13 AM, Boris Motik wrote:
> 
>> Hello,
>>
>> OK, I didn't know about the fact that people are using bnodes in OBO.
>>
>> Providing some construct that would allow you not to name individuals
>> explicitly is not difficult. Still, I would make this
>> construct independent from bnodes. Thus, you would have two types of
>> things:
>>
>> - Unnamed individuals would be just normal individuals for which a
>> tool invents a name.
>>
>> - Bnodes would be "true" existential nodes.
>>
>> It seems to me that an elegant solution would be to drop bnodes from
>> OWL 1.1, but to allow unnamed individuals in the functional
>> syntax.
>>
>> The OBO people would then have to switch from using bnodes to using
>> unnamed individuals (assuming that they want to be in OWL 1.1
>> DL).
>>
>> Do you think this would solve the problem?
>>
>>     Boris
>>
>>> -----Original Message-----
>>> From: Alan Ruttenberg [mailto:alanruttenberg@gmail.com]
>>> Sent: 13 November 2007 14:08
>>> To: Boris Motik
>>> Cc: 'Web Ontology Language (OWL) Working Group WG'
>>> Subject: Re: ISSUE-3: REPORTED: Lack of anonymous individuals
>>>
>>>
>>> On Nov 12, 2007, at 8:13 PM, Boris Motik wrote:
>>>
>>>> Hello,
>>>>
>>>> I actually like the suggestion of dropping blank nodes from OWL 1.1
>>>> DL, but leaving them in OWL 1.1 Full. No OWL 1.0 DL ontology I know
>>>> of actually uses blank nodes, so the loss of them is no big deal in
>>>> practice.
>>>
>>> The OBO ontologies use them, though I am not fond of that use, and
>>> suspect it could be changed.
>>>
>>>> I don't believe that anyone in practice of OWL 1.1 DL would ever
>>>> mourn the lack of blank nodes.
>>>
>>> They would mourn the fact that they have to specify the name of an
>>> individual when they don't want to, and the fact that the pool of
>>> "almost OWL" RDF would shrink.
>>>
>>>> Furthermore, I am not aware of any OWL 1.0 DL tool that implements
>>>> blank nodes exactly as it is said in the spec: most tools skolemize
>>>> blank nodes when reading an ontology. This makes the tools sound
>>>> and complete for ontology satisfiability, but not for ontology
>>>> entailment. No OWL 1.0 DL tool actually supports ontology
>>>> entailment directly: the inferences traditionally supported are
>>>> instance checking, subsumption checking, classification, etc.
>>>>
>>>> Thus, the simplest solution would be to leave the specification of
>>>> OWL 1.1 DL as it is, and to allow blank nodes to appear only in RDF
>>>> data in OWL 1.1 Full. This would make OWL 1.1 DL technically not
>>>> 100% backwards compatible, but I doubt that anyone in practice
>>>> would really care.
>>>
>>> Actually, independent of the blank node issue, the first step would
>>> be to provide a syntactic construct where a name need not be
>>> provided, but a unique name (using urn:uuid, for instance) would be
>>> created instead. This would solve half the problem, without
>>> prejudicing the resolution of blank nodes.
>>>
>>>> Now I don't completely understand what you meant with the following:
>>>>
>>>>> We couldn't generate, within OWL-DL, bnodes. I'm not sure this is
>>>>> a big deal. It
>>>>> means we can't generate idiomatic foaf. It also means that OWL
>>>>> rendered in turtle gets potentially uglier.
>>>
>>>  From http://wiki.foaf-project.org/TurtleFoafTutorial
>>>
>>> @prefix : <http://xmlns.com/foaf/0.1/> .
>>> <mailto:person@example.net> :knows [ a :Person ; :name "Uther
>>> Example" ] .
>>>
>>> which can be written in OWL DL as
>>>
>>> Individual(<mailto:person@example.net> value(knows Individual(type
>>> (Person) value(name "Uther Example")))
>>>
>>> This would no longer be possible. With generated ids(as I suggest),
>>> the closest we could come would be something like:
>>>
>>> Individual(<mailto:person@example.net> value(knows UnnamedIndividual
>>> (type(Person) value(name "Uther Example")))
>>>
>>> which would render in turtle as, e.g.
>>>
>>> @prefix : <http://xmlns.com/foaf/0.1/> .
>>> <mailto:person@example.net> :knows urn:uuid:d81294c0-91a5-11dc-
>>> bb37-0002a5d5c51b.
>>> urn:uuid:d81294c0-91a5-11dc-bb37-0002a5d5c51b  a :Person.
>>> urn:uuid:d81294c0-91a5-11dc-bb37-0002a5d5c51b :name "Uther Example" .
>>>
>>>
>>>> Please note that we could only drop bnodes in instance data;
>>>> however, bnodes would still be allowed in the translation from the
>>>> structural specification into the RDF syntax. Hence, I don't
>>>> understand why OWL rendered in turtle gets potentially uglier. The
>>>> RDF rendering of OWL 1.1 DL would be unchanged by this: we would
>>>> only just prohibit anonymous individuals in instance data.
>>>
>>> See above.
>>>
>>>>> We could read bnodes within rdf and interpret them within OWL by
>>>>> way of the translation to the explicit existential (restriction on
>>>>> property blah blah), as long as there were only trees of bnodes, i.e,
>>>>> as Bijan notes
>>>>
>>>> If we define OWL 1.1 DL without bnodes, then we should probably not
>>>> handle a potential translation of bnodes while parsing in the spec.
>>>> Implementations are free to read bnodes in instance data and
>>>> translate them into skolem constants; however, this is then
>>>> something that the implementation *may* choose to do. Strictly
>>>> speaking, this should not affect the definition of the language in
>>>> any way; otherwise, we are risking incompatibility with OWL 1.1 Full.
>>>
>>> If we translate bnodes into skolem constants then, as I see it, we
>>> are incompatible with OWL Full. I don't think this is a good idea,
>>> personally, because I think it will lead to confusion, nor do I see a
>>> reason to do so.
>>>
>>>> To summarize, the solution would be the following:
>>>>
>>>> 1. Leave the structural spec and the mapping to RDF as is -- that
>>>> is, disallow blank nodes in instance data.
>>>>
>>>> 2. Allow for bnodes in OWL 1.1 Full.
>>>>
>>>> Regards,
>>>>
>>>>     Boris
>>>>
>>>>> -----Original Message-----
>>>>> From: public-owl-wg-request@w3.org [mailto:public-owl-wg-
>>>>> request@w3.org] On Behalf Of Alan Ruttenberg
>>>>> Sent: 10 November 2007 17:57
>>>>> To: Web Ontology Language (OWL) Working Group WG
>>>>> Subject: Re: ISSUE-3: REPORTED: Lack of anonymous individuals
>>>>>
>>>>>
>>>>> Related to the question of skolems versus existentials, I note that
>>>>> both the OWL 1.0 and the OWL 1.1 RDF mappings make liberal use of
>>>>> bnodes. Is there any reason that we couldn't use skolems (which are
>>>>> not bnodes)?
>>>>>
>>>>> -- 
>>>>>
>>>>> It doesn't seem like a good idea to me to *interpret* bnodes as
>>>>> skolems. Better to assume that we serialize skolems as urn:uuid: as
>>>>> Reto suggested in the email Bijan cites.
>>>>>
>>>>> It seems to me that we could actually support both.
>>>>>
>>>>> Individual(type(owl:Thing)) could be a skolem
>>>>> SomeIndividual(type(owl:Thing)) could be an existential.
>>>>>
>>>>> Suppose we dropped bnodes(old style anonymous individuals) from OWL-
>>>>> DL, but not OWL-Full, what would be the consequences? We couldn't
>>>>> generate, within OWL-DL, bnodes. I'm not sure this is a big deal. It
>>>>> means we can't generate idiomatic foaf. It also means that OWL
>>>>> rendered in turtle gets potentially uglier.
>>>>>
>>>>> We could read bnodes within rdf and interpret them within OWL by way
>>>>> of the translation to the explicit existential (restriction on
>>>>> property blah blah), as long as there were only trees of bnodes, i.e,
>>>>> as Bijan notes
>>>>>
>>>>> Can anyone say why doing things this way would be problematic?
>>>>>
>>>>> -Alan
>>>>>
>>>>
>>>>
>>
>>
> 
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf