W3C home > Mailing lists > Public > public-vocabs@w3.org > August 2013

Re: Proposal: Looking inside tables

From: Thad Guidry <thadguidry@gmail.com>
Date: Thu, 15 Aug 2013 10:21:15 -0500
Message-ID: <CAChbWaNcvWasgkgejO9JCWDiWau8mBZ9p1icfdnCiHcf4LfMTg@mail.gmail.com>
To: Omar Benjelloun <benjello@google.com>
Cc: Markus Lanthaler <markus.lanthaler@gmx.net>, Stéphane Corlosquet <scorlosquet@gmail.com>, W3C Vocabularies <public-vocabs@w3.org>, Ramanathan Guha <guha@google.com>, Dan Brickley <danbri@google.com>
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.


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/>
Received on Thursday, 15 August 2013 15:21:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:29 UTC