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 10:51:50 UTC