Re: Proposal: Looking inside tables

On Thu, Aug 15, 2013 at 11:21 AM, Thad Guidry <thadguidry@gmail.com> wrote:

> Yeap. Thought so.  You might want to actually say exactly that in the
> proposal, since that helps make it very clear on the usage of @id
> definitions.
>
>
I tried to clarify. New version is attached.

Thanks,
-Omar



>
> On Thu, Aug 15, 2013 at 10:12 AM, Omar Benjelloun <benjello@google.com>wrote:
>
>> Hi Thad,
>>
>> The type declarations should all use SetOf, whether they're in schema.orgor class URLs from another vocabulary.
>>
>> The @id definitions (and other properties) are patterns where the values
>> of columns will be substituted for each row, to generate the values of the
>> properties for each instance, so the SetOf substitution doesn't apply to
>> them.
>>
>> Does that help clarify?
>>
>> Thanks,
>> -Omar
>>
>>
>>
>> On Thu, Aug 15, 2013 at 10:39 AM, Thad Guidry <thadguidry@gmail.com>wrote:
>>
>>> Omar,
>>>
>>> So the /SetOf/ will be optional in user defined urls or not ?  The
>>> examples under "Identifers and references" section seem to strip it out, or
>>> I misunderstood your earlier email :
>>>
>>>   "@type": "SetOf/Country",
>>>
>>>   "@id": "http://my.domain.org/country/{t1:col:country-code}",
>>>
>>>
>>> On Thu, Aug 15, 2013 at 9:21 AM, Omar Benjelloun <benjello@google.com>wrote:
>>>
>>>> Attached is a new version of the proposal that uses SetOf as a way to
>>>> declare table annotations explicitly (in the HTML mark-up as well as in
>>>> JSON-LD)
>>>>
>>>> @Markus we also considered explicit manipulation of tables in an
>>>> earlier version of this proposal. I'll try to explain why we went with the
>>>> current approach:
>>>>
>>>> If you look at the examples towards the bottom of the document, you'll
>>>> see that for the more complex cases, the directionality of the mappings is
>>>> different: instead of mapping from table columns to properties of a type,
>>>> we map from the type and its properties (sometimes with nesting) to columns
>>>> / patterns. This is more expressive, as the graph schema structured can be
>>>> nested, while the table structure is flat.
>>>>
>>>> Mapping from the type structure to the table columns with an explicit
>>>> table layer becomes quite heavy, as you first need to define the tables and
>>>> their columns, then the type/property structure with references to the
>>>> columns.
>>>>
>>>> I think the current approach with explicit SetOf is a nice trade-off
>>>> between simplicity and expressiveness.
>>>>
>>>> Thanks,
>>>> -Omar
>>>>
>>>>
>>>>
>>>> On Thu, Aug 15, 2013 at 9:55 AM, Markus Lanthaler <
>>>> markus.lanthaler@gmx.net> wrote:
>>>>
>>>>> On Wednesday, August 14, 2013 8:32 PM, Stéphane Corlosquet wrote:
>>>>> > From the proposal:
>>>>> >
>>>>> > <table typeof="Painting" vocab="http://schema.org/">
>>>>> >   <thead>
>>>>> >     <tr>
>>>>> >       <th property="image">Image</th>
>>>>> >       <th property="name">Title</th>
>>>>> >       <th property="dateCreated">Year</th>
>>>>> >       <th>Technique</th>
>>>>> >       <th>Dimensions</th>
>>>>> >       <th property="contentLocation">Gallery</th>
>>>>> >     </tr>
>>>>> >   </thead>
>>>>> > <tbody>...</tbody>
>>>>> > </table>
>>>>> >
>>>>> > It should be noted that parsers which are not aware of this table
>>>>> > extension would generate this information:
>>>>> >
>>>>> > <>
>>>>> >    rdf:type schema:Painting;
>>>>> >    schema:image "Image";
>>>>> >    schema:name "Title";
>>>>> >    schema:dateCreated "Year";
>>>>> >    schema:contentLocation "Gallery" .
>>>>> >
>>>>> > How do you plane to cope with this situation? Leave it be? Would it
>>>>> > have unintended consequences on some applications?
>>>>>
>>>>> Thanks Stéphane, I was going to ask the same question. I think the
>>>>> problem is even more apparent if you look at the JSON-LD examples in the
>>>>> draft:
>>>>>
>>>>> {
>>>>>   "@context": "http://schema.org/",
>>>>>   "@type": "Painting",
>>>>>   "dateCreated" : "{http://wp.org/rembrandt-paintings.csv#col:Year}",
>>>>>   "contentLocation" : "{
>>>>> http://wp.org/rembrandt-paintings.csv#col:Gallery}",
>>>>>   "author": "http://en.wikipedia.org/wiki/Rembrandt"
>>>>> }
>>>>>
>>>>> Why not define something which is a bit more explicit at the price of
>>>>> being a bit more verbose? Something like
>>>>>
>>>>> {
>>>>>   "@context": "http://schema.org/"
>>>>>     "rp" : "http://wp.org/rembrandt-paintings.csv#"
>>>>>   },
>>>>>   "@type": "Table",   ----- in lack of a better name
>>>>>   "columnDefinitions": [
>>>>>     {
>>>>>       "@id": "rp:col:Title",
>>>>>       "mapsTo": "http://schema.org/name" -- can also be abbrev. to
>>>>> "name"
>>>>>     },
>>>>>     {
>>>>>       "@id": "rp:col:Year",
>>>>>       "mapsTo": "dateCreated"
>>>>>     {
>>>>>       "@id": "rp:col:Gallery",
>>>>>       "mapsTo": "contentLocation"
>>>>>     {
>>>>>       "constants": {
>>>>>         "@type": "Painting",
>>>>>         "author": "http://en.wikipedia.org/wiki/Rembrandt"
>>>>>       }
>>>>>     }
>>>>>   ]
>>>>> }
>>>>>
>>>>> Or in HTML
>>>>>
>>>>> <table typeof="Table" vocab="http://schema.org/">
>>>>>   <thead rel="columnDefinitions">
>>>>>     <tr>
>>>>>       <th about="#image" property="mapsTo"
>>>>> resource="schema:image">Image</th>
>>>>>       <th about="#title" property="mapsTo"
>>>>> resource="schema:name">Title</th>
>>>>>       <th about="#year" property="mapsTo"
>>>>> resource="schema:dateCreated">Year</th>
>>>>> ...
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Markus
>>>>>
>>>>>
>>>>> --
>>>>> Markus Lanthaler
>>>>> @markuslanthaler
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Omar Benjelloun | benjello@google.com | (415) 845-8516
>>>>
>>>
>>>
>>>
>>> --
>>> -Thad
>>> Thad on Freebase.com <http://www.freebase.com/view/en/thad_guidry>
>>> Thad on LinkedIn <http://www.linkedin.com/in/thadguidry/>
>>>
>>
>>
>>
>> --
>> Omar Benjelloun | benjello@google.com | (415) 845-8516
>>
>
>
>
> --
> -Thad
> Thad on Freebase.com <http://www.freebase.com/view/en/thad_guidry>
> Thad on LinkedIn <http://www.linkedin.com/in/thadguidry/>
>



-- 
Omar Benjelloun | benjello@google.com | (415) 845-8516