RDF Aggregation Operators (Was: RDF Extensibility)

Hi Pat,

You wrote...

*..how do we know, given some RDF, what semantic extensions are
appropriately to be used when interpreting it? That is a VERY good question.
This is something that RDF2 could most usefully tackle,...*

One as yet uncharted direction in which RDF semantics standardization could
in future do much better than SQL concerns aggregation. An approach is in
the executable file [1].

                        HTH,  -- Adrian

[1]  www.reengineeringllc.com/demo_agents/RDFQueryLangComparison1.agent
See: 6. the publication that-title has that-number author(s)

Internet Business Logic
A Wiki and SOA Endpoint for Executable Open Vocabulary English Q/A over SQL
and RDF
Online at www.reengineeringllc.com
Shared use is free, and there are no advertisements

Adrian Walker
Reengineering


2010/7/6 Pat Hayes <phayes@ihmc.us>

>
> On Jul 6, 2010, at 9:34 AM, Jiří Procházka wrote:
>
>  On 07/06/2010 03:35 PM, Toby Inkster wrote:
>>
>>> On Tue, 6 Jul 2010 14:03:19 +0200
>>> "Michael Schneider" <schneid@fzi.de> wrote:
>>>
>>>  So, if
>>>>
>>>>   :s "lit" :o .
>>>>
>>>> must not have a semantic meaning, what about
>>>>
>>>>   "lit" rdf:type rdf:Property .
>>>>
>>>> ? As, according to what you say above, you are willing to allow for
>>>> literals in subject position, this triple is fine for you
>>>> syntactically. But what about its meaning? Would this also be
>>>> officially defined to have no meaning?
>>>>
>>>
>>> It would have a meaning. It would just be a false statement. The
>>> same as the following is a false statement:
>>>
>>>        foaf:Person a rdf:Property .
>>>
>>
>> Why do you think so?
>> I believe it is valid RDF and even valid under RDFS semantic extension.
>> Maybe OWL says something about disjointness of RDF properties and classes
>> URI can be many things.
>>
>> I think there are issues about RDF extensibility which haven't been
>> solved and they concern:
>> a) semantics
>> b) serializations
>>
>> In case of a) I don't have cleared up my thoughts yet, but generally I
>> would like to know:
>> How are semantic extensions to work together in automated system?
>>
>
> Well, the semantics always defines some notion of entailment, and your
> system is supposed to respect that notion: not draw invalid conclusions,
> draw as many valid conclusions as you feel are useful, don't say things are
> inconsistent when they aren't, etc.. Otherwise, you have free rein. So, if
> you have several semantic extensions, they are each provide a set of such
> entailments and they should add up to one single set of legal entailments.
>
>
>  How to let agent know that the data is described using new RDF
>> extension, which the client doesn't know and the data could be (or
>> definitely are) false if it is interpreted using vanilla RDF semantics?
>>
>
> NOt false, if its a semantic extension (they can't contradict the RDF
> semantics., only extend it.) BUt same point more generally: how do we know,
> given some RDF, what semantic extensions are appropriately to be used when
> interpreting it? That is a VERY good question. This is something that RDF2
> could most usefully tackle, if only in a first-step (ham-fisted?) kind of a
> way. We were aware that this was an issue in the first WG, but it was just
> too far outside out charter, and our energy level, to tackle properly. One
> obvious (?) thing to say is that using a construction from a namespace which
> is associated with the definition of any RDF semantic extension is deemed to
> bring along the necessary interpretation conditions from the extension, so
> that for example if I use owl:sameAs in some RDF, then I mean it to be
> understood using the OWL semantic conditions. We all do this without
> remarking upon it, but loosely, and to make this precise and normative would
> be a very interesting (and useful) exercise. (An issue already here is,
> which version of the OWL semantics is intended? Does the use in RDF also
> "import" the OWL-DL syntactic restrictions on its use, for example?)
>
> Pat
>
>
>
>
>> b) How should my system know that the data which is just being processed
>> is new revision of RDF/XML and not malformed RDF/XML when forward
>> compatibility was out of sight, out of mind when RDF/XML was designed?
>>
>> Best,
>> Jiri Prochazka
>>
>>
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 or (650)494 3973
> 40 South Alcaniz St.           (850)202 4416   office
> Pensacola                            (850)202 4440   fax
> FL 32502                              (850)291 0667   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>
>
>
>