Re: firts and rdf:rest as functional property

Bijan Parsia said the following on 03/20/2009 03:36 PM:
> On 20 Mar 2009, at 14:22, Reto Bachmann-Gmür wrote:
>
>> Bijan Parsia said the following on 03/20/2009 03:14 PM:
>>> On 20 Mar 2009, at 14:02, Reto Bachmann-Gmür wrote:
>>>
>>>> Hi Bijan
>>>>> ...
>>>>>> If rdf:rest
>>>>>> and rdf:first are not functional a list could typically not be be
>>>>>> splitted into different rdf molecules[1]. Splitting graphs into
>>>>>> small
>>>>>> components is essential for applications like diff, sync[2] and
>>>>>> versioning[3].
>>>>>
>>>>> If you are doing to decompose *semantically*, then functionality will
>>>>> be too weak to do the job anyway.
>>>> Not sure if I understand you, if a do decomposition of a graph into
>>>> RDF
>>>> molecules[1] (as this is done in the Graph Versioning System GVS
>>>> [2]) if
>>>> the base ontology contains the fact that rdf:rest and rdf:firts are
>>>> owl:functionalProperty a list will typically (i.e. if some of the
>>>> objects of the rdf:first statements are grounded or if the first
>>>> rdf:List resource is grounded) be split into many small components
>>>> while
>>>> otherwise it is (assuming the rdf:List resources are anonymous) all
>>>> contained in one molecule. Isn't the decomposition into a semantical
>>>> decomposition?
>>>
>>> Sorry, don't have time to peek at that at the moment.
>>>
>>> By semantic decomposition, I mean that there will be certain
>>> properties preserved in the decomposition. See the slides for:
>>>     http://owl.cs.manchester.ac.uk/2008/iswc-modtut/
>> Indeed it seems we are not talking about the same, I'm talking about
>> lossless decomposition of graphs, i.e. a decomposition that has the
>> property that the union of the components expresses the same meaning as
>> the original graph.
>
> That is my meaning.
oh
>
>>> Functionality isn't necessarily the problem, but I presume you want
>>> first to be min1 as well (for a well formed list...having holes is as
>>> bad as having tentacles).
>> That's not an issue for decomposition.
>
> Why not?
Well it could be, that limiting the decomposable graphs to those without
lists with holes could allow some more (efficient) algorithms, but it
seems to me a too restrictive requirement. (In an open world context we
might well come across unfortunately truncated graphs and be able to put
these into our graph versioning system keeping all the available meaning)
>
>>> Functionality might have the surprising effect of entailing that two
>>> things are the same. Which might not be how you want to "repair" the
>>> tentacled list.
>> It's not about repairing list, but its exactly about having means of
>> knowing that "two" things are the same
>
> Yes, for this you should be looking at conservativity. Lists are just
> more abox statements. You don't need them to be nice to decompose them
> properly.
why not? for efficient processing (in application like sync, diff and
versioning) its crucial to decompose our knowledge bases into component
that are small and that are to high degree canonically serializable (and
can thus have a strong digest as this is the case for all functionally
grounded nodes)
>
>>> So, it's not clear to me that this is the right tool for the job.
>>> Perhaps I'm wrong about what job you're trying to do?
>> If you have some time at some point I invite you check out the Graph
>> Versioning System and see the effect of not asserting that the list
>> properties are functional of the size of the components containing large
>> lists.
> But this is irrelevant to the semantic correctness of the decomposition.
A bottle of champagne for a graph that expresses a different semantic
content after having been decomposed and recomposed by GVS :)

(I know this is not and argument, for those I refer to the previously
mentioned references)
>>> rdf:Lists were not introduced for modeling, but for encoding the
>>> syntax of OWL (taken from DAML+OIL). They have been pressed into
>>> service for modeling, but the built-in semantics (IMHO) as well as
>>> other aspects of them aren't really suited for modeling. But we model
>>> with what's at hand.
>> Don't see why we should have other list structure to describe lists
>> outside the owl ontology specification.
>
> I'm just pointing out that rdf:list is not a real list nor is it
> properly designed for representing lists. So it'll be hacky.
As Jeremy pointed out (as how I understood it) they are "real" lists by
conventions and that implementations may expect them to be like that, so
that it would be an interoperability bug to use these properties for non
list structures.

Is it just the absence of explicit cardinality and functionality
statement that makes it an non-real list for you? How would in your
opinion a proper list be designed?

Cheers,
reto

Received on Friday, 20 March 2009 15:30:08 UTC