- From: Michael Steidl \(IPTC\) <mdirector@iptc.org>
- Date: Fri, 19 Jul 2013 19:09:34 +0200
- To: "'Mo McRoberts'" <Mo.McRoberts@bbc.co.uk>, <public-odrl@w3.org>
I'm fine with the approach to make the vocabularies SKOS schemes and making odrl:Action a subclass of skos:Concept - but then I propose considering to make it a full SKOS Concept Scheme. This is what our IPTC Controlled Vocabulary server delivers - as excerpt: @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix skos: <http://www.w3.org/2004/02/skos/core#>. @prefix scn: <http://cv.iptc.org/newscodes/scene/>. <http://cv.iptc.org/newscodes/scene/> rdf:type skos:ConceptScheme; skos:HasTopConcept scn:010100; skos:HasTopConcept scn:010200; skos:HasTopConcept scn:010300; ........... skos:HasTopConcept scn:012400. scn:010100 rdf:type skos:Concept; skos:prefLabel "Portrait"@de; skos:prefLabel "headshot"@en-GB; skos:definition "Ansicht nur des Kopfes einer oder mehrerer Personen oder von einem oder mehreren Tieren."@de; skos:definition "A head only view of a person (or animal/s) or persons as in a montage."@en-GB; skos:inScheme <http://cv.iptc.org/newscodes/scene/>. scn:010200 rdf:type skos:Concept; skos:prefLabel "Halbfigur"@de; skos:prefLabel "half-length"@en-GB; skos:definition "Ansicht des Oberkörpers einer oder mehrerer Personen"@de; skos:definition "A torso and head view of a person or persons."@en-GB; skos:inScheme <http://cv.iptc.org/newscodes/scene/>. (To get this you have to apply the URL and set the http Accept header to text/turtle) Michael > -----Original Message----- > From: Mo McRoberts [mailto:Mo.McRoberts@bbc.co.uk] > Sent: Friday, July 19, 2013 12:51 PM > To: public-odrl@w3.org Group > Subject: Re: Namespace of ODRL > > Hi all, > > I've collected together the actions and moved them out into a separate > document, using the new (proposed) namespaces: > > http://ptah.bencrannich.net/2013/UNSTABLE/actions.ttl > > My question at this point is this: > > Should this be a SKOS Concept Scheme (and consequentially, should > odrl:Action, the parent class of all of these, be a subclass of skos:Concept)? > > The various actions themselves *are* concepts, and this is a controlled > vocabulary of terms -- on that basis I'd be inclined to say 'yes', but I'd like to > gauge views first. > > M. > > > On 2013-Jul-19, at 09:37, Mo McRoberts <mo.mcroberts@bbc.co.uk> wrote: > > > Okay, it seems like we're close to (if not have) consensus on this one — > does anybody have any objections before I make the changes? > > > > M. > > > > On 2013-Jul-17, at 14:14, Stefan Becker <stefanbecker@uni-koblenz.de> > wrote: > > > >> We used a similar approach in our draft ontology and would strongly > support multiple namespaces. > >> Other ontologies, e.g. KAoS []1 also use seperate namespaces. > >> Regards, > >> > >> Stefan Becker, Benjamin Hück, Katharina Naujokat, Andreas Kasten and > Arne F. Schmeiser > >> > >> > >> [1] http://ontology.ihmc.us/ontology.html > >> > >> > >> Am 17.07.2013 14:55, schrieb Michael Steidl (IPTC): > >>>> -----Original Message----- > >>>> From: Mo McRoberts [ > >>>> mailto:Mo.McRoberts@bbc.co.uk > >>>> ] > >>>> Sent: Wednesday, July 17, 2013 12:16 AM > >>>> To: Michael Steidl (IPTC) > >>>> Cc: Renato Iannella; > >>>> <public-odrl@w3.org> > >>>> > >>>> Subject: Re: Namespace of ODRL > >>>> > >>>> > >>>> On 16 Jul 2013, at 11:49, Michael Steidl (IPTC) > >>>> <mdirector@iptc.org> > >>> wrote: > >>> > >>>>> Renato, I think it is an agreement that "2" is used as the major version > >>>>> number. > >>>>> > >>>>> All: > >>>>> Coming back to only one or more namespaces: a user of terms from > this > >>>>> namespace would like to know what a specific term is for - as Ray > >>>>> > >>>> expressed > >>>> > >>>>> this by the pan and ingredients distinction. If ODRL has a machine > >>>>> > >>> readable > >>> > >>>>> definition of all these terms then it must be considered how to > express > >>>>> > >>>> such > >>>> > >>>>> a distinction. > >>>>> Even in the current Vocabulary is no qualifier if a term should be used > >>>>> > >>> with > >>> > >>>>> Policy Type, Actions, Constraints, Party and Role, or Asset and > >>>>> > >>> Relation, > >>> > >>>>> such a distinction is currently only made by the tables in the human > >>>>> readable HTML presentation. > >>>>> > >>>> So I'm inclined to agree, and certainly RDF has the means to express > that. > >>>> > >>>> As an alternative to the 'one namespace or two' question, here's an > >>>> alternative proposal: > >>>> > >>>> Split the vocabulary into (preferred prefix in parens): > >>>> > >>>> - A namespace for the model ( > >>>> http://www.w3.org/ns/odrl/2/ > >>>> ...) > >>>> > >>>> - A namespace for ODRL-defined actions > >>>> ( > >>>> http://www.w3.org/ns/odrl/2/actions/ > >>>> ...) > >>>> > >>>> - A namespace for ODRL-defined constraints > >>>> ( > >>>> http://www.w3.org/ns/odrl/2/constraints/ > >>>> ...) > >>>> > >>>> - A namespace for ODRL-defined functions > >>>> ( > >>>> http://www.w3.org/ns/odrl/2/functions/ > >>>> ...) > >>>> > >>>> - A namespace for ODRL-defined policy types > >>>> ( > >>>> http://www.w3.org/ns/odrl/2/policies/ > >>>> ...) > >>>> > >>>> - A namespace for ODRL-defined relation types > >>>> ( > >>>> http://www.w3.org/ns/odrl/2/relations/ > >>>> ...) > >>>> > >>>> - A namespace for ODRL-defined scopes > >>>> ( > >>>> http://www.w3.org/ns/odrl/2/scopes/ > >>>> ...) > >>>> > >>>> The remainder - which includes the "base" classes such as v:Scope, as > well > >>>> as the operators, conflict terms and undefined terms - would be > moved > >>>> into the model (because re-defining those as an extensibility > mechanism > >>>> > >>> isn't > >>> > >>>> particularly useful). > >>>> > >>>> While this is certainly a little more complex, it does mean that there's a > >>>> > >>> very > >>> > >>>> clear split between things which constitute the *mechanics* of ODRL > versus > >>>> the various instances/subclasses/subproperties which make up the > >>>> vocabularies, with each controlled vocabulary inhabiting its own > namespace > >>>> to make the distinction clear. > >>>> > >>>> This would mean that, for example, v:Action would become odrl:Action > >>>> > >>>> <http://www.w3.org/ns/odrl/2/Action> > >>>> , while v:acceptTracking would > >>>> become act:acceptTracking > >>>> > >>>> <http://www.w3.org/ns/odrl/2/actions/acceptTracking> > >>>> . > >>>> > >>>> Each of the schema documents at > >>>> {actions,constraints,functions,policies,relations,scopes} would > reference > >>>> > >>> the > >>> > >>>> model, but the reverse would not be true (i.e., the model is completely > >>>> agnostic to the actual terms used, provided they are correctly- > formulated, > >>>> not only conceptually, but implementation-wise too). > >>>> > >>>> How does this sound to people? > >>>> > >>> I fully agree, this split up is very close to what IPTC has done for its > >>> news exchange formats: a namespace for the basic structure and for > each > >>> value vocabulary a specific namespace. Also the split up of the ODRL > >>> vocabulary is ok, moving the operators to the basic structure namespace > >>> makes a lot of sense. > >>> > >>> Michael > >>> > >>> > >>> > >>> > >>> > >> > > > > > > -- > > Mo McRoberts - Analyst - BBC Archive Development, > > Zone 1.08, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA, > > MC3 D6, Media Centre, 201 Wood Lane, London W12 7TQ, > > 0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E > > > > > -- > Mo McRoberts - Analyst - BBC Archive Development, > Zone 1.08, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA, > MC3 D6, Media Centre, 201 Wood Lane, London W12 7TQ, > 0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E > > > > ----------------------------- > http://www.bbc.co.uk > This e-mail (and any attachments) is confidential and > may contain personal views which are not the views of the BBC unless > specifically stated. > If you have received it in > error, please delete it from your system. > Do not use, copy or disclose the > information in any way nor act in reliance on it and notify the sender > immediately. > Please note that the BBC monitors e-mails > sent or received. > Further communication will signify your consent to > this. > -----------------------------
Received on Friday, 19 July 2013 17:10:09 UTC