- From: <Peter.Winstanley@scotland.gsi.gov.uk>
- Date: Mon, 22 Jun 2015 09:06:40 +0000
- To: <aisaac@few.vu.nl>, <christophe.gueret@dans.knaw.nl>
- CC: <public-dwbp-wg@w3.org>, <David.Brown2@scotland.gsi.gov.uk>, <riccardo.albertoni@ge.imati.cnr.it>
Yes Antoine, there are many similarities between SLA and the schema.org "Offer". So, there is the SLA and there is the document/s that serialise the SLA - so perhaps we can have an Offer that is expressed as a Document. David is more expert than me in the area of SLA and will be better placed to determine the goodness-of-fit with the schema.org "Offer" [and the related AggregateOffer] Peter -----Original Message----- From: Antoine Isaac [mailto:aisaac@few.vu.nl] Sent: 19 June 2015 13:32 To: Christophe Guéret; Winstanley FP (Peter) Cc: public-dwbp-wg@w3.org; Brown D (David) (ISIS); Riccardo Albertoni Subject: Re: dwbp-ISSUE-184: Is an dqv:ServiceLevelAgreement a kind of certificate, or a standard? [Quality & Granularity Vocabulary] Hi everyone, I agree with Christophe, it's really useful feedback! I'm always a bit reluctant to model things as information resources (documents) when there's a deeper social reality behind them though. For example if someone wants to extend our dqv:ServiceLevelAgreement class to represent parties and duties with very specific SLA perspective, then it may be awkward if the main starting point they have is a document. Actually my reading of Peter's message makes me think of what ODRL models as "Policies", see the diagram at https://www.w3.org/community/odrl/model/2.0/#section-21 In a less specialized approach, schema.org introduces "offers": https://schema.org/Offer Would one of these approaches be more appropriate? Cheers, Antoine On 6/16/15 1:16 PM, Christophe Guéret wrote: > Hi Peter, David, > > Thanks for the much insightful feedback! We had the impression that SLA could be tricky to model and thus decided we would have just a simple class in the vocabulary. A separate group motivated in (and more able to) diving into the complexities of the modelling could then take over making more out of this class. > > That said we do have to find something to base this class upon and also define a relation to the DCAT elements. From what you explain I take that a document, as defined in DCTERMS, would be the closest accurate enough choice. It's not a standards nor a certificate but some kind of common understanding described in a human-readable way, so just like any document. As a relation between the DCAT elements and this documents we could define a dqv:hasSLA or dqv:serviceLevelAgreement . > > Would that be a sound solution ? > > Regards, > Christophe > > On 12 June 2015 at 13:50, Peter.Winstanley@scotland.gsi.gov.uk <mailto:Peter.Winstanley@scotland.gsi.gov.uk> <Peter.Winstanley@scotland.gsi.gov.uk <mailto:Peter.Winstanley@scotland.gsi.gov.uk>> wrote: > > Hello Team > re: _http://www.w3.org/2013/dwbp/track/issues/184_ > With thanks to a helpful conversation with my colleague David Brown: > SLA is a type of customer charter. There is generally a top-level SLA which is a catalogue of services available to a customer together with the qualities available for each of those services, perhaps with the option of levels of service for a scale of charges or similar. > > So, in some respects an SLA is also and aggregation of minor SLAs, one for each service. > SLAs can be generalisable describing a spread of ‘offerings’ from an organisational unit to any of a range of other organisational units. Equally, it could be an individualised, tailored agreement between two parties. > It has some similarities to a contract – a formally negotiated agreement between parties - the key distinction being that it is not legally binding (otherwise it wouldn’t be an SLA, it would be a contract) > But sometimes the levels described in the metrics are aspirational, other times they are definitive. So sometimes an SLA is a collection of ‘promises’. > SLAs are “glued” together by OLAs [Operational Level Agreements] which tend to be between organisational units within larger organisation. E.g. within a company or government IT service delivery function there will be Desktop support, Network support, Data services etc > OLAs then refer to underpinning contracts with primary suppliers e.g. a company’s network service team might have a contract with Vodaphone or other core service supplier. > So, it’s perhaps neither a certificate nor a standard. It is perhaps closer to a promise, but one which once made has a spectrum of potential consequences for the failure to comply with the promise, none of which would be accessible to level of legal redress that would be available under a contract. > I think the key for the dqv is to have a recursive property for the entity ServiceLevelAgreement so that it can contain other SLAs, and that we should find some appropriate top level ‘thing’ to subclass SLA from. Definitions should link with ITIL v3, COBIT etc. > Peter > > ********************************************************************** > > This e-mail (and any files or other attachments transmitted with it) is intended solely for the attention of the addressee(s). Unauthorised use, disclosure, storage, copying or distribution of any part of this e-mail is not permitted. If you are not the intended recipient please destroy the email, remove any copies from your system and inform the sender immediately by return. > > Communications with the Scottish Government may be monitored or recorded in order to secure the effective operation of the system and for other lawful purposes. The views or opinions contained within this e-mail may not necessarily reflect those of the Scottish Government. > > Tha am post-d seo (agus faidhle neo ceanglan còmhla ris) dhan neach neo luchd-ainmichte a-mhàin. Chan eil e ceadaichte a chleachdadh ann an dòigh sam bith, a’ toirt a-steach còraichean, foillseachadh neo sgaoileadh, gun chead. Ma ’s e is gun d’fhuair sibh seo le gun fhiosd’, bu choir cur às dhan phost-d agus lethbhreac sam bith air an t-siostam agaibh, leig fios chun neach a sgaoil am post-d gun dàil. > > Dh’fhaodadh gum bi teachdaireachd sam bith bho Riaghaltas na h-Alba air a chlàradh neo air a sgrùdadh airson dearbhadh gu bheil an siostam ag obair gu h-èifeachdach neo airson adhbhar laghail eile. Dh’fhaodadh nach eil beachdan anns a’ phost-d seo co-ionann ri beachdan Riaghaltas na h-Alba. > > ********************************************************************** > > > The original of this email was scanned for viruses by the Government Secure Intranet virus scanning service supplied by Vodafone in partnership with Symantec. (CCTM Certificate Number 2009/09/0052.) This email has been certified virus free. > Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes. > > > > > -- > Onderzoeker > DANS, Anna van Saksenlaan 51, 2593 HW Den Haag > +31(0)6 14576494 > christophe.gueret@dans.knaw.nl <mailto:christophe.gueret@dans.knaw.nl> > > *Data Archiving and Networked Services (DANS/KNAW) > *http://dans.knaw.nl <http://dans.knaw.nl> > * > e-Humanities Group (KNAW)* > eHumanities <http://www.ehumanities.nl/> > > *World Wide Semantic Web community* > http://worldwidesemanticweb.org/ > > This email was scanned by the Government Secure Intranet anti-virus service supplied by Vodafone in partnership with Symantec. (CCTM Certificate Number 2009/09/0052.) In case of problems, please call your organisations IT Helpdesk. Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes. *********************************** ******************************** This email has been received from an external party and has been swept for the presence of computer viruses. ******************************************************************** The original of this email was scanned for viruses by the Government Secure Intranet virus scanning service supplied by Vodafone in partnership with Symantec. (CCTM Certificate Number 2009/09/0052.) This email has been certified virus free. Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes.
Received on Monday, 22 June 2015 09:07:13 UTC