W3C home > Mailing lists > Public > public-architypes@w3.org > February 2017

Re: Discussion about previous proposal

From: Jane Stevenson <Jane.Stevenson@jisc.ac.uk>
Date: Mon, 20 Feb 2017 15:00:16 +0000
To: Richard Wallis <richard.wallis@dataliberate.com>
CC: "public-architypes@w3.org" <public-architypes@w3.org>
Message-ID: <2A4E5B7C-25A8-496D-9F61-CFD4EA397FD7@jisc.ac.uk>
Great, that works :-)

OK, we’ll try working on this a bit more now. As Owen says, creative work does have its advantages, as its well ‘embedded’.  

The discussion has been really useful. 

> In most of my engagements and interactions it is not long before I hear a sentence that begins something like “Ah! but in our data we don’t have …”.

In most of our day to day work you will hear it! Being an aggregator, that’s inevitably the wall that we hit when we try to implement anything new. 

cheers
Jane



> On 16 Feb 2017, at 11:14, Richard Wallis <richard.wallis@dataliberate.com> wrote:
> 
> Hi Jane,
> 
> Glad my last message was helpful.
> 
> What you now question is what I tend to characterise as ‘ambition hitting reality!’
> 
> In most of my engagements and interactions it is not long before I hear a sentence that begins something like “Ah! but in our data we don’t have …”.
> 
> And this is where pragmatism comes into play, and you apply the ‘do the best you can with what you have’ principle.
> 
> So where, for example, you have what you believe to be a CreativeWork but are not sure of which subtype to use, use CreativeWork.  If you have a something but you have no ideas to what type of thing it is, this would be the unusual case when you would use ArchivedItem as the only Type for an item.
> 
> ~Richard.
> 
> Richard Wallis
> Founder, Data Liberate
> http://dataliberate.com

> Linkedin: http://www.linkedin.com/in/richardwallis

> Twitter: @rjw
> 
> On 16 February 2017 at 11:04, Jane Stevenson <Jane.Stevenson@jisc.ac.uk> wrote:
> Hi Richard,
> 
> This is really helpful, and does clear up some of the confusion I was under, thanks.
> 
> However, now I think I understand it, I can see a  fundamental issue it raises for the Archives Hub…. If we want to apply schema.org markup to an ‘archiveItem’ we won’t know what the item is - whether it is a notebook, letter, series of correspondence, or an article or book (which would usually be annotated in some way in order to be in an archive in the first place).  So you say:
> 
> >       • What is the item (separate from it being in an archive)  - a Book, an Article, a Painting, a Vehicle ?
> > Choose the appropriate Schema Type and use that type’s properties to describe the item.
> 
> But we don’t know what it is because we aggregate descriptions from over 300 repositories and they very rarely put down the type in the description. I think if anyone was going to apply schema.org to already existent archive catalogue information, they would have the same problem. Especially because the unit of description below the collection is usually an aggregation anyway, not one item.
> 
> It seems to me, if I’ve got this right, that CreativeWork is more generic and you can apply various properties to it without a more specific type? Or do you have to choose a more specific type?
> 
> cheers
> Jane
> 
> 
> 
> > On 16 Feb 2017, at 10:41, Richard Wallis <richard.wallis@dataliberate.com> wrote:
> >
> > Hi Jane,
> >
> > In your first email, your example Schema.org description of an ArchiveCollection is a good start, utilising properties inherited from its super types (CreativeWork and ArchivedItem).
> >
> > Taking the points in your 2nd email:
> >
> > 1 & 2.. Should I not worry about the class being intangible? - No.   maybe I’m getting too hung up on describing something physical under the class of intangible?  - Yes.
> > So what about DateCreated, inLanguage, genre, creator, about, etc?  These are the properties I would want to use at any level when describing archives - So you should.
> >
> > These issues, often a point of early confusion for those new to using Schema.org, come under the heading of Multi-Type Entities (MTEs) - Until recently not fully recognised by Google’s testing tool, so historically not well used.  A MTE is a Thing that is described as being of more than one type.
> >
> > Applying MTEs in practice for an item in an archive, the process would flow something like this:
> >       • What is the item (separate from it being in an archive)  - a Book, an Article, a Painting, a Vehicle ?
> > Choose the appropriate Schema Type and use that type’s properties to describe the item.
> >
> >       • As the item is in an archive, also add the ArchivedItem Type, which then makes available some more properties to enable you to describe the archive related attributes of the item.
> > Practically this is achieved in the various data serialisations thus:
> >     Microdata: <span itemscope itemtype=‘http://schema.org/Painting’

> > >
> >
> >           <link itemprop=“additionalType” href="http://schema.org/ArchivedItem"/>
> >           <link itemprop=“additionalType” href="http://schema.org/ArchivedItem"/>
> >   RDFa: <body vocab=“http://schema.org” typeof='Painting ArchivedItem'
> > >
> >
> >   JSONJD: “@type”: [“Painting”,”ArchivedItem”]
> >
> > 3. ArchiveCollection is defined as being a subtype of both CreativeWork and ArchivedItem making those properties available
> >
> > It seems like you’re saying that archived item is a type, rather than a ‘thing’,
> > In terms of the Schema.org vocabulary, ArchivedItem is defined as a Type.  However in practice is use could be described more appropriately as a qualifying type.  I would expect it to be unlikely to be used in isolation.  Most ArchivedItems will also be a type of thing in its own right - a Book, Document, Product, etc.
> > You would use it to apply archived-ness to the description of items in an archive.
> >
> >
> > Hopefully the above some of the thoughts you share in the rest of the email.
> >
> > I understand that this [Schema.org] approach is a little confusing when first encountered, especially when starting at a result [proposal], and working backwards to first principles.  Normally when engaged to help projects with Schema.org understanding and application, I start at the beginning.  ;-)
> >
> > ~Richard.
> >
> > Richard Wallis
> > Founder, Data Liberate
> > http://dataliberate.com

> > Linkedin: http://www.linkedin.com/in/richardwallis

> > Twitter: @rjw
> >
> > On 15 February 2017 at 14:54, Jane Stevenson <Jane.Stevenson@jisc.ac.uk> wrote:
> > Hi all,
> >
> > I’m still not clear on the proposal.
> >
> > ArchivedItem has its own properties, which include accessAndUse, itemCondition, itemDescription, itemProvenance.  I can see these are ‘archive specific’.
> >
> > 1. Should I not worry about the class being intangible? An intangible thing doesn’t have a Location, Condition or Provenance. I do get the basic premise that it doesn’t matter too much in schema.org what things are called (e.g. the localBusiness class being used for an archive). So maybe I’m getting too hung up on describing something physical under the class of intangible? I thought first of all you were saying that this was only to describe it as ‘partOf’ something, but clearly it is also to describe its physical characteristics.
> >
> > 2. ArchivedItem also inherits ‘thing’ properties - name, description, url.
> > So what about DateCreated, inLanguage, genre, creator, about, etc?  These are the properties I would want to use at any level when describing archives - from the collection to the series to the item.
> >
> > If we take DateCreated, which is a key descriptor, the problem we have is that it is used for a creative work. But If we are going to use schema.org to help with discovery of archives through search engines, I think date created is a useful property to have.
> >
> > 3. ArchiveCollection can in theory be a single item anyway, and then you may want to use e.g. itemCondition, itemDescription.
> >
> > For the Archives Hub we tend to think in terms of an archival unit - and that can be at any level. A collection could be one item, or a collection may only be described at series level. We simply want to apply schema.org to every unit of description, and I had thought that we would be able to do this without thinking in terms of whether the unit is a collection or item. I’m also not sure where that leaves a series, sub series, file….
> >
> > - Any type of *thing* could be in an archive.so archive specific attributes cold not be expected to be added to a single Type.
> >
> > But you are adding archive attributes to the single type of ArchivedItem….?
> >
> > - Using the Schema.org practice of Multi-Typed Entities (MTEs) those
> >   archive specific properties can be attached to a qualification type -
> >   Archived Item in this case.
> >
> > But here you seem to be saying that we can add archive specific properties to ArchivedItem - so they can’t be added to a single type but they can be added to ArchivedItem, which is a type?   (clearly I’m not getting something here).
> >
> > It seems like you’re saying that archived item is a type, rather than a ‘thing', as Owen was saying. But the properties seem very much to be describing a thing.
> >
> > - *CreativeWork*, *Product*, etc. would be too specific
> >
> > But this comes back to the requirement to use the CreativeWork properties.
> >
> >
> > cheers,
> > Jane
> >
> > Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
> >
> > Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.
> >
> 
> 

Received on Monday, 20 February 2017 15:01:00 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 August 2018 13:28:59 UTC