Re: Social Web WG Agenda for 6 October 2015

elf Pavlik writes:

> On 10/07/2015 05:16 AM, Kevin Marks wrote:
>> On Tue, Oct 6, 2015 at 8:08 PM, Melvin Carvalho <melvincarvalho@gmail.com>
>> wrote:
>> 
>>>
>>>
>>> On 7 October 2015 at 04:01, Aaron Parecki <aaron@parecki.com> wrote:
>>>
>>>> Melvin, I don't know if you actually read any of the discussion around
>>>> the post-type-discovery proposal, but the -1 votes were not actually
>>>> downvoting the algorithm's existence, they were -1s because they had
>>>> clarifying questions. Since this was brought up within minutes of the end
>>>> of the call, I'm not surprised to see the -1s. Anyway, there is now another
>>>> week to review the document and we will discuss it on next week's call. I
>>>> encourage you to join the call if you have an opinion on this.
>>>>
>>>
>>> Thanks for the clarification, Aaron.  I dont have a problem with the
>>> algorithm's existence.  Im sure it could be useful.  It's just not REC
>>> track.
>>>
>>> This problem is already solved via inferencing.  IMHO not a good use of
>>> time discussing whether or not to reinvent the wheel.  Just use existing
>>> RECs.
>>>
>>>
>> Can you link me to some data that shows where this particular problem is
>> already solved by a REC?
> You can find nice illustration of reasoning over rdfs:domain here:
> * http://www.slideshare.net/EUCLIDproject/querying-linked-data/60
> * http://www.euclid-project.eu/modules/course2 (video to accompany those
> slides)
>
> RDFS definition which implies an entity on which one uses property
> mo:member to have type mo:MusicGroup
> *
> https://github.com/motools/musicontology/blob/master/rdf/musicontology.n3#L1658-L1669
>
> Normative definition in *W3C Recommendation*
> * http://www.w3.org/TR/rdf-schema/#ch_domain
>
> Major dataset using MusicOntology
> * http://linkedbrainz.org/

Having read Tantek's spec, it looks like it serves a different purpose
than this.  The above linked examples show a whole bunch of RDF data,
and infer other things from the RDF data.  That seems to be a different
problem.

If I understand Tantek's proposal correctly, it looks like it's for the
type of case where *none* of this information is available, say a simple
blogpost submission type interface.  This might be used by a client,
where the user isn't selecting a type because it isn't exposed by the
user interface, or by some microformats to activitystreams / rdf
conversion tool.  So I don't think these solve the same problem, despite
using similar terminology.  So if I understand it right, this seems to
be a nice heuristics-heavy way to get microformats stuff to convertable
to ActivityStreams more easily, without having to restructure
ActivityStreams itself.  That would be a good goal.  Tantek seemed to
indicate my understanding of this is right.  I'd love clarity from him.

I also have some hesitance about whether or not this spec fits within
the SocialWG charter, but I think it might be very useful, and might at
least be something for the group to acknowledge.

But if the above objections are because the w3c really does have
algorithms that can solve this exact same problem of something that is
relatively free of linked data contexts, then this might be worth
raising, and please demonstrate!  If this is a "linked data does this
right and microformats does this wrong", again, see my recent email: I'd
like to keep these arguments out of the group; they can't be solved
here.

Received on Wednesday, 7 October 2015 13:18:50 UTC