Re: shapes as classes

So the EDM example is connected, after all.

peter


On 12/29/2014 12:22 PM, Karen Coyle wrote:
> No, that is correct. The short bit in my email would not have been complete.
>
> kc
>
> On 12/29/14 12:11 PM, Peter F. Patel-Schneider wrote:
>> So http://kcoyle.net/temp/edmtest.ttl is not correct?  That graph is
>> connected.
>>
>> If http://kcoyle.net/temp/edmtest.ttl is not correct, then what is the
>> correct setup?
>>
>> peter
>>
>>
>> On 12/29/2014 11:05 AM, Karen Coyle wrote:
>>>
>>>
>>> On 12/29/14 7:56 AM, Peter F. Patel-Schneider wrote:
>>>> As far as I can see this is a connected example because of the
>>>> edm:aggregatedCHO property.
>>>
>>> I thought so too, until I saw Eric's dot diagram, which showed that
>>> they are
>>> actually held together by a property from the ORE ontology [1] called
>>> "ore:proxy", which I didn't include in this example. I was fooled by
>>> the fact
>>> that the IRIs all end in the same string
>>> ("BibliographicResource_2000092034263"), but that the differences
>>> between them
>>> is earlier on in the path:
>>>
>>> http://data.europeana.eu/item...
>>> http://data.europeana.eu/aggregation...
>>>
>>> That ORE relies heavily on naming metadata graphs as "proxies" is
>>> interesting
>>> in light of the discussion of "what is a thing in RDF?" The library and
>>> archive world has been very clear that their metadata is a proxy or
>>> surrogate
>>> for a much richer Real World Object, and has kept that Real World at
>>> arm's
>>> length. Even the representation of persons as creators has stopped far
>>> short
>>> of the real world: the person graph (or record, as it currently is)
>>> represents
>>> only the *chosen name* that will stand for the person in the data, and
>>> not the
>>> person him/her self. There is no biographical information included
>>> (dates of
>>> birth only exist to differentiate two persons of the same name, and other
>>> information can be used in place of the date). The person is not a
>>> "Resource"
>>> in library data.
>>>
>>> All this to say that in spite of having a rich tradition of metadata
>>> in this
>>> community, that tradition is a great distance from the approach that
>>> comes
>>> from the AI activities that attempt to replicate real world activities.
>>>
>>> kc
>>> [1] http://www.openarchives.org/ore/1.0/datamodel - and which makes
>>> very heavy
>>> use of the term Resource, as "any item of interest", from the Web
>>> architecture
>>> document (http://www.w3.org/TR/webarch/)
>>>
>>>>
>>>> peter
>>>>
>>>>
>>>> On 12/20/2014 09:05 AM, Karen Coyle wrote:
>>>>> This isn't my data, so what you're getting here is my understanding of
>>>>> the
>>>>> model and the rules. The rule that needs to be applied is that for
>>>>> every
>>>>> "record" there must be one edm:ProvidedCHO (by rdf:Type) and at
>>>>> least one
>>>>> ore:Aggregation (by rdf:Type). It looks to me like these are the
>>>>> relevant "bits":
>>>>>
>>>>> <http://data.europeana.eu/item/9200231/BibliographicResource_2000092034263>
>>>>>
>>>>>
>>>>>      a edm:ProvidedCHO .
>>>>>
>>>>> <http://data.europeana.eu/aggregation/europeana/9200231/BibliographicResource_2000092034263>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>      edm:aggregatedCHO
>>>>> <http://data.europeana.eu/item/9200231/BibliographicResource_2000092034263>
>>>>>
>>>>> ;
>>>>>      a ore:Aggregation .
>>>>>
>>>>> In the RDF/XML this reads as:
>>>>>
>>>>>   <edm:ProvidedCHO
>>>>> rdf:about="http://data.europeana.eu/item/9200231/BibliographicResource_2000092034263"/>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ...
>>>>>    <ore:Aggregation xmlns:ore="http://www.openarchives.org/ore/terms/"
>>>>> rdf:about="http://data.europeana.eu/aggregation/provider/9200231/BibliographicResource_2000092034263">
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>    </ore:Aggregation>
>>>>>
>>>>> As I said below, EDM uses RDF/XML, and there is the concept of a
>>>>> "record" in
>>>>> the sense of a beginning and end and that "record" has an identifier
>>>>> (here
>>>>> ending in "263"). Other than sharing that URI, the ProvidedCHO and
>>>>> Aggregation
>>>>> have no direct links to each other that I can find. To me, this makes
>>>>> a graph,
>>>>> and I don't know if this is what is meant below by: "in the same
>>>>> information
>>>>> resource".
>>>>>
>>>>> kc
>>>>>
>>>>> On 12/20/14 8:36 AM, Peter F. Patel-Schneider wrote:
>>>>>> Without knowing what sort of thing you want to do with this, it is
>>>>>> impossible to determine whether you are depending on an implicit
>>>>>> connection.
>>>>>>
>>>>>> peter
>>>>>>
>>>>>>
>>>>>> On 12/20/2014 08:22 AM, Karen Coyle wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 12/19/14 8:11 PM, Peter F. Patel-Schneider wrote:
>>>>>>>> The narrative for S35 says "There is no path from the
>>>>>>>> acc:AccessContextList node to either of the acc:AccessContext nodes.
>>>>>>>> There is an implicit containment relation of acc:AccessContext
>>>>>>>> nodes in
>>>>>>>> the acc:AccessContextList by virtue of these nodes being in the same
>>>>>>>> information resource."  This implicit connection is not part of RDF.
>>>>>>>
>>>>>>> An example would really help here. I have what may be a similar
>>>>>>> example from
>>>>>>> the Europeana data. I'm not sure if this mailing list takes
>>>>>>> attachments, so
>>>>>>> the (short) example is here:
>>>>>>>
>>>>>>> http://kcoyle.net/temp/edmtest.ttl
>>>>>>>
>>>>>>> I cut the data down from something with dozens of related files and
>>>>>>> subject
>>>>>>> headings, but I think I kept the structure intact. The main nodes of
>>>>>>> the model
>>>>>>> are edm:ProvidedCHO and ore:Aggregation. The data is natively in
>>>>>>> RDF/XML but I
>>>>>>> have trouble reading that so I converted it to TTL.
>>>>>>>
>>>>>>> Q: Is this an example of what is being discussed here?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> kc
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> peter
>>>>>>>>
>>>>>>>>
>>>>>>>> On 12/19/2014 06:01 PM, Karen Coyle wrote:
>>>>>>>>> DC has at least one similar case, in use today. Can you,
>>>>>>>>> however, say
>>>>>>>>> what you
>>>>>>>>> mean by "some characteristic of two nodes"? What "characteristics"
>>>>>>>>> would put
>>>>>>>>> them out of scope?
>>>>>>>>>
>>>>>>>>> kc
>>>>>>>>>
>>>>>>>>> On 12/19/14 4:12 PM, Peter F. Patel-Schneider wrote:
>>>>>>>>>> If the only connection is that they are in the same graph, then it
>>>>>>>>>> might
>>>>>>>>>> be in scope.  However, if there is some indication that the
>>>>>>>>>> connection
>>>>>>>>>> is somehow special because of the some characteristic of two nodes
>>>>>>>>>> that
>>>>>>>>>> are both in a particular graph, then I would say that this is
>>>>>>>>>> out of
>>>>>>>>>> scope.
>>>>>>>>>>
>>>>>>>>>> It appears to me that the latter is the case.
>>>>>>>>>>
>>>>>>>>>> peter
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 12/19/2014 12:42 PM, Arthur Ryman wrote:
>>>>>>>>>>> "Peter F. Patel-Schneider" <pfpschneider@gmail.com> wrote on
>>>>>>>>>>> 12/19/2014
>>>>>>>>>>> 02:40:44 PM:
>>>>>>>>>>>
>>>>>>>>>>>> From: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
>>>>>>>>>>>> To: Arthur Ryman/Toronto/IBM@IBMCA, public-data-shapes-wg@w3.org
>>>>>>>>>>>> Date: 12/19/2014 02:41 PM
>>>>>>>>>>>> Subject: Re: shapes as classes
>>>>>>>>>>>>
>>>>>>>>>>>> S35 talks about an implicit connection between
>>>>>>>>>>>> acc:AcccessContext
>>>>>>>>>>>> nodes
>>>>>>>>>>> and
>>>>>>>>>>>> acc:AccessContextList nodes.  This implicit connection
>>>>>>>>>>>> appears to
>>>>>>>>>>>> me to
>>>>>>>>>>> be
>>>>>>>>>>>> outside the scope of RDF.
>>>>>>>>>>>>
>>>>>>>>>>>> peter
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Peter,
>>>>>>>>>>> I think this implicit connection is in scope because the concept
>>>>>>>>>>> of an
>>>>>>>>>>> RDF
>>>>>>>>>>> graph is within the scope of RDF. The implicit connection
>>>>>>>>>>> between the
>>>>>>>>>>> nodes is a consequence of them being in the same RDF graph. A
>>>>>>>>>>> shape
>>>>>>>>>>> language should let me describe a constraint such as "The graph
>>>>>>>>>>> must
>>>>>>>>>>> have
>>>>>>>>>>> exactly one node of type acc:AccessContextList, and zero or
>>>>>>>>>>> nodes of
>>>>>>>>>>> type
>>>>>>>>>>> acc:AccessContext."
>>>>>>>>>>>
>>>>>>>>>>> -- Arthur
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Received on Monday, 29 December 2014 20:30:49 UTC