Re: Proposed change to the charter, section 4. Deliverables, Recommendation Track

On 08/07/2014 07:05 PM, Eric Prud'hommeaux wrote:
> * Peter F. Patel-Schneider <pfpschneider@gmail.com> [2014-08-07 18:41-0700]
>>
>>
>> On 08/07/2014 06:33 PM, Eric Prud'hommeaux wrote:
>>> * Peter F. Patel-Schneider <pfpschneider@gmail.com> [2014-08-07 17:41-0700]
>>>>
>>>>
>>>> On 08/07/2014 05:24 PM, Eric Prud'hommeaux wrote:
>>>>>
>>>>> On Aug 7, 2014 12:44 AM, "Peter F. Patel-Schneider" <pfpschneider@gmail.com
>>>>> <mailto:pfpschneider@gmail.com>> wrote:
>>>>>>
>>>>>> Well, I did present what I thought was a good neutral set of deliverables,
>>>>> namely
>> [...]
>>>>>>
>>>>>> 3. OPTIONAL A specification of how shape verification interacts with
>>>>>> inference.
>>>>>
>>>>> I think this one feel off radar. Did you see any support for this?
>>>>
>>>> Well, it was supposed to be a better version of the normalization requirement.
>>>
>>> I think I'm not getting the connection. I'd expect that inference
>>> would allow one to say that e.g. a myco:Employee is subclass of a
>>> foaf:Person before enforcing a rule that required the foaf:Person arc
>>> on employee records. I thought that normalization was about
>>> predictably ordering the arcs. Is my model wrong, or perhaps one
>>> conversationed morphed into the other? More importantly to my task at
>>> hand, should I continue to track this?
>>
>> I had thought that the normalization deliverable was to handle RDF
>> or RDFS inference.  I couldn't imagine any other use for
>> normalization as related to shape checking.
>
> I had thought it was about ordering triples to optimize various
> processes like parsing, querying, and hanging on Christmas trees.
> As far as I can tell, we don't have critical support for normalization.

Hmm, finally a use for RDF graph normalization.  :-)

peter

Received on Friday, 8 August 2014 02:28:25 UTC