W3C home > Mailing lists > Public > www-archive@w3.org > September 2013

tentative actions, endorsement

From: Sandro Hawke <sandro@w3.org>
Date: Tue, 24 Sep 2013 10:32:47 -0400
Message-ID: <5241A28F.9010708@w3.org>
To: Dan Brickley <danbri@danbri.org>
CC: Pat Hayes <phayes@ihmc.us>, Jeremy J Carroll <jjc@syapse.com>, Gregg Reynolds <dev@mobileink.com>, www-archive <www-archive@w3.org>
On 09/24/2013 09:53 AM, Dan Brickley wrote:
> On 24 September 2013 14:51, Sandro Hawke <sandro@w3.org> wrote:
>> On 09/24/2013 09:38 AM, Dan Brickley wrote:
>>>>> Do you have a use case (involving RDF on computers) for having different
>>>>> properties on different "graphs" (which happen to have the same
>>>>> triples),
>>>>> and which does not involve "graphs" changing over time?
>>> (jumping in here...)
>>>
>>> Related to change over time, but not quite the same: description of
>>> Actions that may never happen, e.g. possible events (alongwith URLs +
>>> info etc. that could be used to make them happen).
>>>
>>> Dan
>>>
>> Can you give me a little more detail there?
>>
>> Maybe we're doing meeting scheduling, and the meeting might be at 9am in the
>> Star room or might be at 10am in the Patel room, like this:
>>
>> GRAPH :g1 { :staffMtg83 :start 2013-09-24T09ET; :location :Star }
>> GRAPH :g2 { :staffMtg83 :start 2013-09-24T10ET; :location :Patel }
>> :staffMtg83 :option :g1, :g2.
>>
>> Something like that?
>>
>> I agree that's a very interesting use case for datasets.
>>
>> I don't think it's one that motivates having different properties on the
>> same group of triples.  At least not as far as I can see.
> It's for schema.org; we defined http://schema.org/Action recently,
> including a variety of sub-types. These work as-is in triples for
> actions that have happened.
>
> We have discussed using actionStatus=tentative properties of an
> Action, but that is non-ideal since that triple could always drop off,
> leaving the impression the action wasn't tentative (esp. if date is in
> the past, which ties back to the date issue of course).
>

Right, it's a common problem with RDF on the Web.   You want to attach 
some important metadata to some of the triples, like "I'm just kidding", 
or "tentative", "was true for the 1988-1989 school year".

You could put that data inside the graph (sometimes), inside another 
graph, or make it part of the arc linking to that data source. And you 
might set the data "aside" by putting it in a different web page from 
some more "main" page, or by putting it inside a named graph inside a 
Web page, instead of directly in a Web page.

I'm sure what users want is to just put it inside the graph.    They 
want to say:

     <> a :Tentative thing

or

    <> dc:temporal :schoolYear1988-1989

But that goes against the RDF Semantics and the common practice of 
querying a graph.   As you say, that triple might be dropped.

So, I think the safest way to do it is make it part of the arc leading 
to the graph.    if :t1 is the graph with the tentative knowledge (a 
named graph, a web page URL, whatever), it's only reachable from 
endorsed content via a link like { :t1 a :TentativeSource }.

This requires some notion of "endorsed content".    Clearly Google has a 
fuzzy notion of this, and for this system to work, it kind of has to be 
smart about this.  The presence of the url :t1 in endorsed content does 
not mean that the graph :t1 is endorsed.

But maybe this is pushing water uphill.   Maybe we need a way to say { 
<> a :TentativeSource. }.  Somehow we handle this in human systems all 
the time.   I think the human process is something like: assume a 
document is true and about the current context until/unless something 
raises doubt about that, then try to figure out if it's untrue or true 
of a different context.    Maybe we can formalize that process -- you 
find some RDF in the wild, so you tentatively assume it's true in the 
universal context, then do some reasoning, looking for signs it might 
not really be.   If it's not, then you try to figure out what its real 
status is.  dc:temporal is pretty clear about this.     If this is too 
hard, then perhaps you shouldn't be looking for RDF in the wild.  :-)

         -- Sandro
Received on Tuesday, 24 September 2013 14:32:57 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:44:23 UTC