- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Mon, 29 Dec 2014 12:22:52 -0800
- To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Monday, 29 December 2014 20:23:22 UTC