On 13 Aug 2013, at 18:33, "Michael Steidl (IPTC)" <mdirector@iptc.org>
wrote:
> Hi Renato
>
> Could you tell us where we are in this discussion and how we will come to a
> conclusion? To "look at how the single namespace looks in the first draft of
> the ODRL Ontology Spec" may not be sufficient - and do we have timeline for
> looking at it?
Current in-progress work is here:
http://ptah.bencrannich.net/2013/UNSTABLE/odrl/2/
(should perform conneg for LODE-generated HTML, Turtle, RDF/XML, ntriples; others can be added easily)
https://dvcs.w3.org/hg/odrl is the source repository
>>> First, using different namespaces for the basic structure and for each
>>> set of vocabulary terms eases the process of managing these terms.
>>
>> Yes and No ;-) Given the nature of rdf/owl ontologies, loading a single
>> namespace or
>> multiple namespaces into common editors (like Protege, TopBraid
>> Composer, etc) makes no
>> difference to the editing/managing the terms etc
>
> A note from having a deeper look at the schema.org vocabulary -
> http://schema.org/docs/full.html
> - it has a hierarchical structure (yes, in know: classes and sub-classes)
> which provides wrappers, e.g. Action has AchieveAction ... UpdateAction as
> children - this is essential for finding out which terms in the schema.org
> namespace represent an action
schema.org uses paths to indicate subclasses, which sort-of works for schema.org's simplified model of the world, but has caused problems and confusion.
> - and in addition for some of the wrappers all its child terms inherit the
> wrapper term, see Action above, see also MedicalEntity.
> - to my feeling this clearly indicates that a flat list of terms as the
> current ODRL vocabulary would not work properly for the not-expert users.
In which situation would the terms be listed in a 'flat' form, even if they appear in a machine-readable file in that way?
>> This still holds true with a single namespace, as all terms would be
>> subclasses/subproperties of a parent term.
>> (or in our case, individuals of the same class)
>> Hence, an editor can see all the relevant terms based on the expression in
>> the ontology.
>
> This implicitly requires that one MUST use an ontology editor/viewer to
> understand the structure of classes in a namespace, accessing only the URL
> would not help - as the URL of an IPTC vocabulary, e.g.
> http://cv.iptc.org/newscodes/scene/, delivers all members.
Yes, it delivers all members; splitting them up into a single resource per described entity gets horrible quickly.
There's a more fundamental point, though: that whatever you're pointing at the URI is able to meaningfully interpret one of the formats that the descriptive resource is served as. That might be XML schema, that might be Turtle, or ? if you're human ? it's probably HTML.
>>
>>> Finally, the use of ODRL should not get more complicated when using
>>> different namespaces. Instead, different namespaces can even help the
>>> process of creating ODRL policies. A policy editing tool could easily
>>> distinguish between actions, constraints, and other terms based on their
>>> namespaces.
>>
>> See above comment.
>
> See my above comment, to filter out all Actions from the generic ODRL
> namespace needs to use an ontology viewer.
It needs *anything* which can understand *any* of the formats the schema is published in.
> (Btw: currently I try to build a ODRL policy builder using JavaScript - a
> vocabulary-specific namespace would help there.)
Can you provide some more detail of what you're trying to do, and how you're trying to do it? It's not especially clear why a vocabulary-specific namespace would assist in any way.
There are two ways of handling it. Either you could do as LODE does and identify the instances of the Actions class:
http://ptah.bencrannich.net/2013/UNSTABLE/odrl/2/#d4e1148
Alternatively, the following definition in the current Turtle may help?
:actions
a skos:ConceptScheme ;
rdfs:label "ODRL Actions vocabulary"@en ;
skos:hasTopConcept :acceptTracking, :adHocShare, :aggregate, :annotate,
:anonymize, :append, :archive, :attachPolicy, :attachSource,
:attribute, :commercialize, :concurrentUse, :copy, :delete,
:derive, :display, :distribute, :ensureExclusivity, :execute,
:export, :extract, :give, :include, :index, :inform,
:install, :lease, :lend, :license, :modify, :move, :nextPolicy,
:obtainConsent, :pay, :play, :present, :preview, :print, :read,
:reproduce, :reviewPolicy, :secondaryUse, :sell, :share,
:shareAlike, :textToSpeech, :transform, :translate, :uninstall,
:watermark, :write .
M.
--
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.
-----------------------------