- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Wed, 7 Oct 2015 15:36:58 +0200
- To: Christopher Allan Webber <cwebber@dustycloud.org>
- Cc: elf Pavlik <perpetual-tripper@wwelves.org>, Kevin Marks <kevinmarks@gmail.com>, Aaron Parecki <aaron@parecki.com>, Social Web Working Group <public-socialweb@w3.org>
- Message-ID: <CAKaEYhKKw-BuSTAELWB+yUc6FdfEvw73eJN4+LoaZQOXwmTQ6g@mail.gmail.com>
On 7 October 2015 at 15:06, Christopher Allan Webber <cwebber@dustycloud.org > wrote: > 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. > Also perhaps best to avoid framing things in terms of "right and wrong". But rather different approaches have different functionality, and we aim to reuse rather than reinvent. I think this issue could be solved quite neatly by moving MF2 into an AS2 or schema.org style vocab document with the implied types. I think everyone, including members of the MF2 community would appreciate such a normative reference which would be a great WG deliverable, and align MF2 functionality with AS and the linked data set of RECs. At this point much of the functionality that is sought such as implicit types would drop out for free.
Received on Wednesday, 7 October 2015 13:37:28 UTC