Re: References to "application profiles"

Hi everyone,

It seemed difficult to extract a consensus from the thread :-)
Anyway I've tried:
http://www.w3.org/2005/Incubator/lld/wiki/index.php?title=Draft_Vocabularies_Datasets_Section2&diff=6006&oldid=5906

As APs are already mentioned in this section (and I understand Tom would add them in other parts of the report) I have removed them from the debatable sentence. And I've tried to make my "gradation" more explicit, while not presenting it as a formal framework.
Btw "alignments" do indeed include ontology mappings as expressed in OWL, clearly.

Cheers,

Antoine


> Quoting "Young,Jeff (OR)" <jyoung@oclc.org>:
>
>
>> I'm uncomfortable using the term AP even for situations where a variety
>> of existing classes and properties are getting reused. An OWL ontology
>> can be created to document this situation, even if no new terms are
>> being defined there.
>
> I agree with Jeff here. It seems that AP is being used for any ontology that uses a mix of namespaces or that adopts properties from existing namespaces. This seems to me to be normal practice for ontology development. At what point does a choice of properties become an AP? In DC terms, I think that it becomes an AP only when constraints are added (mandatory, optional, repeatable or not, etc.).
>
> I commonly hear people use the term AP when someone consciously creates a personalized or modified version of a known metadata schema. So a sub-set of, say, MARC that selects out the fields needed to encode music resources but not cartographic resources would be an AP in this definition.
>
> Basically, I think we don't have a clear enough definition of AP to use the term in this report without going through a lengthy discussion that would allow us to make it clear. I'd prefer to leave it out, but think that the concept is important and definitely needs more thought.
>
> kc
>
>> Granted, you don't see much of that happening yet,
>> but presumably that's presumably because people are still trying to wrap
>> their minds around OWL in general.
>>
>>> But there are many situations in which re-using a
>>> vocabulary comes with risks/costs that could motivate coining one's
>> own
>>> "duplicate" elements. Consider what schema.org did: they just prefered
>>> to coin all the elements they need, rather than spend time shopping
>>> around for existing elements--which may be not well maintained anyway.
>>> That's maybe not the best practice around, but that will continue to
>>> happen. In such cases, establishing alignments between element sets is
>>> a lesser evil.
>>
>> As a species, I think we are still beginners in terms of modular
>> thinking. I can't think of a single existing model or set of models that
>> doesn't make me squirm and shake. "Alignments" or "mappings" give me
>> hope that we will be able to adapt regardless.
>>
>>>
>>> The "gradient" of best practice here would be: (1) own duplicate
>>> element sets with no alignment; (2) own element sets with alignment to
>>> existing vocabularies (3) "true" APs with re-use of existing
>>> vocabularies.
>>
>> I agree with these idealized gradients with a couple of caveats.
>>
>> 1) Existing vocabularies that don't conform to best practice recipes
>> suck: http://www.w3.org/TR/swbp-vocab-pub/
>> 2) Some existing vocabularies (even popular ones) can be very weird and
>> arguably would be better off being mapped
>> 3) The ability to transform domain-specific vocabularies into foreign
>> vocabularies shouldn't be that far off if the mappings exist
>>
>>>
>>> I'm not saying that it was clearly worded here, far from it :-)
>>> I can also live with this point being mentioned in another section.
>> But
>>> I wanted to warn against making this disappear, altogether.
>>
>> I suspect that all these thoughts are too controversial to used on short
>> notice, though.
>>
>> Jeff
>>
>>>
>>> Cheers,
>>>
>>> Antoine
>>>
>>> > Dear all,
>>> >
>>> > Re-reading the paragraph in [1]:
>>> >
>>> > A similar concern can be voiced regarding metadata element
>> sets.
>>> As
>>> > testified in the Linked Open Vocabularies inventory,
>>> practitioners
>>> > generally follow the good practice of re-using existing element
>>> sets or
>>> > building "application profiles" of them. And some projects,
>> such
>>> as the
>>> > Vocabulary Mapping Framework, aim at supporting that process.
>>> But the lack
>>> > of long-term support for them threatens their enduring meaning
>>> and common
>>> > understanding. Further, some reference frameworks, notably
>> FRBR,
>>> have been
>>> > implemented in different RDF vocabularies, which are not always
>>> connected
>>> > together. Such situation lowers the semantic interoperability
>> of
>>> the
>>> > datasets expressed using these RDF vocabularies. The community
>>> should
>>> > encourage the coordinated re-use of element sets for particular
>>> entity
>>> > descriptions, their extension through, e.g., application
>>> profiles, or their
>>> > alignment using, e.g., semantic relations from RDFS and OWL.
>>> Here, we hope
>>> > that better communication between the creators and maintainers
>>> of these
>>> > resources, as encouraged by our own incubator group or the LOD-
>>> LAM
>>> > initiative, will help to consolidate the conceptual connections
>>> between
>>> > them.
>>> >
>>> > ...where "a similar concern" refers to "semantic links across value
>>> vocabularies".
>>> >
>>> > Looking closer:
>>> >
>>> >> A similar concern can be voiced regarding metadata element sets. As
>>> >> testified in the Linked Open Vocabularies inventory, practitioners
>>> >> generally follow the good practice of re-using existing element
>> sets
>>> or
>>> >> building "application profiles" of them.
>>> >
>>> > If we mean Dublin-Core-style application profiles (as Singapore
>>> Framework is
>>> > cited further on in the paragraph), then we could say something
>> like:
>>> >
>>> > A similar concern can be voiced regarding metadata element
>>> sets. As
>>> > testified in the Linked Open Vocabularies inventory,
>>> practitioners
>>> > generally follow the good practice of re-using existing
>> element
>>> sets or
>>> > building "application profiles" that re-use elements from
>>> multiple sets.
>>> >
>>> > Then, I do not really understand the first part of this sentence:
>>> >
>>> >> The community should encourage the coordinated re-use of element
>>> sets for
>>> >> particular entity descriptions, their extension through, e.g.,
>>> application
>>> >> profiles, or their alignment using, e.g., semantic relations from
>>> RDFS and
>>> >> OWL.
>>> >
>>> > The phrase "encourage the coordinated re-use of element sets for
>>> > particular entity descriptions" seems to be saying something like:
>>> >
>>> > ...promote the use of common patterns of mixing vocabularies
>> for
>>> > describing particular types of things.
>>> >
>>> > However, I do not think this reference to application profiles
>> really
>>> belongs
>>> > in a section on alignment.
>>> >
>>> > Rather, I would like to propose the following:
>>> >
>>> > -- That the section "The linking issue" (vague, because the whole
>> LLD
>>> XG report is
>>> > arguably about a "linking issue") be renamed something like:
>>> >
>>> > Semantic alignment
>>> >
>>> > -- In this case, the first sentence -- "Many semantic links across
>>> value
>>> > vocabularies are already available..." -- could be preceded with
>>> a definition
>>> > along the lines of:
>>> >
>>> > "Alignments" are links between semantically equivalent,
>>> similar, or
>>> > related terms or entities across different value
>>> vocabularies, metadata
>>> > element sets, or datasets.
>>> >
>>> > -- The notion of application profiles is more appropriately
>>> referenced in the point
>>> > about re-using patterns:
>>> >
>>> > In the paragraph:
>>> >
>>> > Design patterns allow implementers to build on the experience
>> of
>>> > predecessors. Traditional cataloging practices are documented
>>> with a rich
>>> > array of patterns and examples, and best practices are starting
>>> to be
>>> > documented for the Linked Data space as a whole (e.g.,
>>> > <ref>http://linkeddatabook.com/editions/1.0/#htoc61</ref>). [*]
>>> What is needed
>>> > are design patterns specifically tailored to LLD requirements.
>>> Such design
>>> > patterns would meet the needs of people and developers who
>>> understand new
>>> > techniques through patterns and examples and will increase the
>>> coherence of
>>> > Library Linked Data overall.
>>> >
>>> > I propose inserting a sentence:
>>> >
>>> > Application profiles
>> (http://dublincore.org/documents/singapore-
>>> framework/)
>>> > provide a method for a community of practice to document and
>>> share patterns
>>> > used for describing specific types of materials.
>>> >
>>> > -- ...and application profiles are also relevant to "data design"
>>> [2]:
>>> >
>>> > Another boost for Linked Data is the growing use of OWL for
>>> purposes of
>>> > data design. Prior to OWL, domain experts could use RDFS to
>>> create metadata
>>> > element sets, but there was no way to map equivalencies across
>>> > vocabularies. Among other features, OWL includes an upgrade to
>>> RDFS to
>>> > support ontology mapping. This allows experts to describe their
>>> domain
>>> > using community idioms, while still being interoperable with
>>> related or
>>> > more common idioms. A variety of tools related to OWL can be
>>> found on the
>>> > W3C's RDF wiki and OWL wiki. Unified Modeling Language (UML)
>>> tools are also
>>> > value to help designers represent and manipulate domain models
>>> visually.
>>> > The Ontology Definition Metamodel (ODM) specification should
>>> help bridge
>>> > some of the gaps between UML and OWL. [*]
>>> >
>>> > I propose to add:
>>> >
>>> > Application profiles
>> (http://dublincore.org/documents/singapore-
>>> framework/)
>>> > provide a way to specify how a community of practice defines a
>>> > domain model and re-uses specific vocabularies in order to
>>> create metadata
>>> > conforming to a particular pattern.
>>> >
>>> > Tom
>>> >
>>> > [1]
>>>
>> http://www.w3.org/2005/Incubator/lld/wiki/DraftReportWithTransclusion#T
>>> he_linking_issue
>>> > [2]
>>>
>> http://www.w3.org/2005/Incubator/lld/wiki/DraftReportWithTransclusion#T
>>> ools_for_data_designers
>>> > [3]
>>>
>> http://www.w3.org/2005/Incubator/lld/wiki/DraftReportWithTransclusion#D
>>> evelop_and_disseminate_best-practices_design_patterns_tailored_to_LLD
>>> >
>>> >
>>>
>>>
>>
>>
>>
>>
>
>
>

Received on Sunday, 28 August 2011 14:05:47 UTC