Print

Print


Since this has moved rapidly, responding to multiple messages inline:

 One advantage of the property approach is that ex:isbn can be declared as:



ex:isbn rdfs:subPropertyOf ex:identifier .


This seems more like a characteristic than an advantage. I don't see, from
your message, why this is a *better* (rather than just a different) option
by comparison to the datatype approach.

> Exotic datatypes seem like a backwater solution.



It even creates it's own backwater...



Using a  custom datatype requires custom support and implementation. It
> requires careful definition of the lexical and value spaces, and the
> mapping from one to the other.


What, semantically or practically, is the difference between `:book ex:isbn
"9783110413014" .\n ex:isbn rdfs:subPropertyOf ex:identifier .` and `:book
ex:identifier "9783110413014"^^ex:ISBN`, in the absence of any other
statements? The former example seems less precise, arguably to the point of
being incorrect. Consider, for example, a requirement to handle ISBN
equality (where "9783110413014", "978-311-0413-014" and "978 311 0413 014"
are the same identifier) where the datatype approach seems to have the
upper hand.

It's true that this would require an implementation that is aware of the
datatype. Two counterpoints, though: first, this requirement is very soft.
In the worst case, you know this is a literal with lexical value
"9783110413014"
and datatype `ex:ISBN`. It's hard to see how this state of affairs is worse
than the `ex:isbn` example, even given range declarations (which I
understand to be discouraged in BIBFRAME). Second, most RDF implementations
come with extensible datatype systems which plug in nicely with the type
systems of host languages. As an implementer, I've found these both easy to
write and handy for native language representations of RDF data.

Rather than jumping to call datatypes "backwater", could we talk directly
about the tradeoffs? I'm not sure I'm arguing for datatypes, here, but I am
worried that (as an only occasional commenter on this list), most appeals
to the spirit of RDF/Linked Data here seem to have more to do with
arbitrary aesthetic dogmas than any tangible benefits. This is a prime
example, and I'm sure the negative language ("backwater") is unhelpful.

There is also a case to be made for encoding the isbn as a URI (resource)
> instead of as a property or datatype.


Agreed.

It turns out that MARC attaches properties to ISBNs, such as the fact that
> it's a large-print edition or a Braille edition.
>

This seems like a bad example. It's hard to imagine a useful model where
"braille edition" is a property of an ISBN. I would point to this as a nice
example of where we need to change practice as we shift to data with model
theoretic semantics.

Machines are good a dumbing down vocabulary based on rules.


Some kinds of vocabulary, based on some rules. Certain rules are provably
non-computable; others compute with impracticable complexity.In this case,
I believe we're talking about three different options that are pretty much
equivalent for the machines.

- Tom



On Sat, Jun 25, 2016 at 7:13 PM, Young,Jeff (OR) <[log in to unmask]> wrote:

> Let me put it this way: it's the humans who whine about "proliferation of
> predicates" not the machines.
>
> On Jun 25, 2016, at 10:02 PM, Young,Jeff (OR) <[log in to unmask]> wrote:
>
> Karen,
>
> Machines are good a dumbing down vocabulary based on rules. Human
> understanding doesn't scale in reverse. RDF statements aren't exactly
> sentences, but there are enough people with in-between understanding now.
> We need to start taking advantage of it.
>
> Jeff
>
> On Jun 25, 2016, at 9:54 PM, Karen Coyle <[log in to unmask]
> <[log in to unmask]>> wrote:
>
> Jeff, I absolutely agree, although one always hears complaints about the
> "proliferation of predicates." The advantage (?) of data types is that you
> have one predicate and the types can be ignored by those who just don't
> care what exact type of thing it is. Another option is to define predicates
> for the major identifiers (we know what they are) and use types (or blank
> nodes) for the remainder. I don't understand the logic that if some
> elements need extra complexity, it's a good idea to impose that complexity
> everywhere.
> kc
>
> On 6/25/16 3:49 PM, Jeff Young wrote:
>
> It could also be expressed as:
>
> X ex:isbn “9783110413014” .
>
> That wouldn't require any new data types. It would only require defining
> ex:isbn as a property, which seem more in keeping with the spirit of RDF.
>
> On Jun 25, 2016, at 6:36 PM, Karen Coyle < <[log in to unmask]>
> [log in to unmask]> wrote:
>
> [Note: resending after 2 days because it hasn't appeared on the list.]
>
>
> There appears to be no limitation on the creation of types in RDF. RDF
> incorporates the XML types as a convenience, but the specification[1] says:
>
> " Any datatype definition that conforms to this abstraction *may* be used
> in RDF, even if not defined in terms of XML Schema."
>
> "A datatype consists of a lexical space
> <https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-lexical-space>,
> a value space
> <https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-value-space> and
> a lexical-to-value mapping
> <https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-lexical-to-value-mapping>,
> and is denoted by one or more IRIs
> <https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-iri>."
>
> The document at https://www.w3.org/TR/swbp-xsch-datatypes/ describes how
> user-defined datatypes can be defined and used. Use of datatypes could
> obviate the need for blank nodes, such that this:
>
>
>       bf:identifiedBy    [  a    bf:Isbn
>
>                             rdf:value   “9783110413014”   ] .
>
> Could be expressed as
>
> X bf:identifiedBy “9783110413014” ^^ex:isbn .
>
> -kc
>
>
> [1]
> https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#section-Datatypes
>
> On 6/20/16 3:49 PM, Tom Johnson wrote:
>
> On Mon, Jun 20, 2016 at 3:01 PM, Fallgren, Nancy (NIH/NLM) [E] <
> <[log in to unmask]>[log in to unmask]> wrote:
>
>> Agreed that a string is a datatype and that it is the default when no
>> specific datatype is declared; however,  I don’t tend to think of a string
>> as a structured value or at least as something that a machine would
>> understand as a structured value (but it’s certainly possible that’s a
>> misunderstanding on my part).  For example, a machine looking at an ISBN as
>> just some string would not understand that the numeric sequence actually
>> has significance.
>>
>
> The structure, in this case, is captured by other properties of the
> resource (in existing examples, primarily the type). As a hypothetical,
> consider an ISBN node like:
>
>    :work bf:identifier [ a bf:isbn ;
>                          rdf:value    "9783110413014" ;
>                          ex:isbnEAN   "978" ;
>                          ex:isbnGrp   "31" ;
>                          ex:isbnPub   "1041" ;
>                          ex:isbnTitle "301" ;
>                          ex:isbnXdig  "4" ] .
>
> Would you agree that this is an example of structured data? This seems to
> me to be the kind of thing the RDF Primer is discussing.
>
> Of course, an actual ISBN datatype definition would obviate the need for
> any of this (arguably including the blank node bf:isbn instance). I'm not
> sure whether I would advocate defining a suite of identifier datatypes; the
> current strategy seems more flexible.
>
> With apologies if I’m being obtuse and belaboring this, but “*Use
>> rdf:value and rdfs:label as appropriate*” doesn’t help me understand how
>> they are each applied.  Perhaps the original question should be restated
>> specific to the BF 2.0 Item example –
>>
>> In the Item example below, what is the difference that causes the strings
>> “unrestricted” and “LB 2395 . . .” to be asserted as rdf:value, while
>> “available” is asserted as an rdfs:label?  All three are human readable
>> strings, one is an alphanumeric assembled from a standard with rules, the
>> other two are common terminology (from a standard vocab somewhere that is
>> not published as RDF?), none of them name a resource, all describe
>> attributes of the resource (circulation status, accessibility, and shelf
>> location) – what criteria determine whether they are rdf:value or
>> rdfs:label?  In BF 2.0, what constitutes appropriate application of
>> rdf:value and rdfs:label to this data?
>>
>>
>>
>> < <http://bibframe.example.org/item/itemZ>
>> http://bibframe.example.org/item/itemZ >
>>
>> a              bf:Item ;
>>
>> bf:heldBy            [rdfs:label “Library of Congress” ] ;
>>
>> bf:subLocation  [rdfs:label “Prints and Photographs Division” ] ;
>>
>> bf:physicalLocation [rdfs:label “Reference collection” ] ;
>>
>> bf:itemOf http://bibframe.example.org/instance/instanceY ;
>>
>> bf:shelfMarkLcc [rdf:value “LB2395.C65 1991” ] ;
>>
>> bf:usageAndAccessPolicy [
>>
>> a bf:AccessPolicy ;
>>
>> rdf:value “unrestricted” ] ;
>>
>> bf:status              [rdfs:label “available” ] ;
>>
>> bf:note                 [rdfs:label “Page 31 torn” ] .
>>
>>
>>
>> Thanks,
>>
>> Nancy
>>
>>
>>
>>
>>
>>
>>
>> *From:* Denenberg, Ray [mailto:[log in to unmask]]
>> *Sent:* Monday, June 20, 2016 4:57 PM
>>
>> *To:* [log in to unmask]
>> *Subject:* Re: [BIBFRAME] FW: [BIBFRAME] rdf:value
>>
>>
>>
>> Hi Tom –
>>
>>
>>
>> Yes, my wording regarding rdfs:literal was a bit lazy. Actually
>> rdfs:literal is defined, it is a class, the class of all literal values and
>> the value of rdf:value is a member of this class, meaning the range of
>> rdf:value is rdfs:literal (although I can’t find anywhere in the specs that
>> actually says this) so it is a class/range rather than datatype. It seemed
>> easier to just say the rdf:value datatype is rdfs:literal.  But you’re
>> right, technically that’s incorrect.
>>
>>
>>
>> On the conventions document questions.
>>
>>
>>
>> *Second point.*   What the second point tries to say is this. Nothing
>> terribly profound, but say you want to express that an instance has carrier
>> “audio disc”. Then any of the following three way is acceptable:
>>
>>
>>
>>                     bf:carrier               <
>> <http://id.loc.gov/vocabulary/carriers/sd>
>> http://id.loc.gov/vocabulary/carriers/sd>  .
>>
>>
>>
>>
>>
>>
>>
>> bf:carrier                     <
>> <http://id.loc.gov/vocabulary/carriers/sd>
>> http://id.loc.gov/vocabulary/carriers/sd>     .
>>
>>
>>
>> < <http://id.loc.gov/vocabulary/carriers/sd>
>> http://id.loc.gov/vocabulary/carriers/sd>
>>
>>                       a bf:Carrier ;
>>
>>                      rdfs:label “audio disc” .
>>
>>
>>
>>
>>
>> bf:carrier <http://id.loc.gov/vocabulary/carriers/sd>   [
>>
>>                       a bf:Carrier ;
>>
>>                      rdfs:label “audio disc” ] .
>>
>>
>>
>>
>>
>> *URI vs. Blank Node.  *Again nothing profound. Just that specifying
>> whether it is acceptable to create blank nodes vs. requiring that a URI
>> must always instead be created is outside the scope of an ontology.
>>
>>
>>
>> *Inverse property . *Yes, we meant inverse, not reciprocal.  When would
>> an inverse property be appropriate or inappropriate?  I cannot really
>> articulate a firm rule,.  In some cases it’s clear: instance and
>> instanceOf.  In some cases less clear: subject. BIBFRAME has defined a
>> number of  inverse properties and will continue to do so when a clear need
>> is indicated.  BIBFRAME’s position though is to not simply declare an
>> inverse for every property just in case it happens to be needed some day.
>>
>>
>>
>> *Datatype vs. Object Properties*.  There was much discussion of this, on
>> this listserv (quite a while back) and there was a strong consensus that
>> there be no property that could take a literal object in one statement and
>> a resource in another. Thus every property should be declared be a datatype
>> or object property and BIBFRAME has explicitly done so, via OWL.
>>
>>
>>
>> *Classes and types.*  Do we mean the same thing?  Yes and no.  This is a
>> guideline used in the development of the ontology.  Take identifier types,
>> for example.  In BF 1 The type of identifier was expressed via property
>> (e.g. bf:isbn).  In BF2 it is expressed via class (bf:Isbn).   So in BF 2,
>> yes, type is intended to mean class membership.  (There are a few
>> exceptions,  a few type properties to be used when there is no known class
>> and the type must be expressed as a string, for example note type).
>>
>>
>>
>> *Proliferation of properties*.  There were cases in BIBFRAME 1 of
>> multiple properties that have been consolidated into a single property in
>> BIBFRAME 2. For example there was classificationScheme and identiferType
>> and these have been consolidated into the single property bf:source (a
>> literal, used only when there is no known class) because it would only
>> occur within a bf:Classification or bf:Identifier resource (respectively)
>> so it would be known whether it is a classification or identifier source.
>>
>>
>>
>> *rdf:value vs. rdfs:resource.*  Which says “*Use rdf:value and
>> rdfs:label as appropriate when supplying the value of a resource*”
>> probably should be truncated to “*Use rdf:value and rdfs:label as
>> appropriate*”. Either that or elaborate as discussed in this thread,
>>
>>
>>
>> Thanks, hope that helps, and keep those questions coming!
>>
>>
>>
>> Ray
>>
>>
>>
>>
>>
>> *From:* Bibliographic Framework Transition Initiative Forum [
>> mailto:[log in to unmask] <[log in to unmask]>] *On Behalf
>> Of *Tom Johnson
>> *Sent:* Monday, June 20, 2016 3:44 PM
>> *To:* <[log in to unmask]>[log in to unmask]
>> *Subject:* Re: [BIBFRAME] FW: [BIBFRAME] rdf:value
>>
>>
>>
>> Chiming in to agree with Ray that, in general, xsd:string is an
>> appropriate datatype for an rdf:value. And that ISBNs, in particular,
>> are not xsd:integers. Their value space is not aligned with that type
>> (as defined at [0].
>>
>>
>>
>> Note that all literals have datatypes (see [1]). As a minor correction to
>> Ray's point, the default datatype for for concrete syntaxes supporting
>> "simple literals" is xsd:String, rather than rdfs:literal (which is not
>> defined).
>>
>>
>>
>> I don't think it's correct that rdf:value is an alternative to a URI.
>> Indeed, it may often be useful to assign URIs to resources with declared
>> values (e.g. to enumerate values for later use). Apart from that, I agree
>> with where the group has landed on the differences from label types: labels
>> name resources, while values express, to some extent, /what the resource
>> is/.
>>
>>
>>
>> To bring us back to the original issue: I recently read the conventions
>> document, and found that I couldn't understand many of the items there.
>> Perhaps some examples and/or motivations should be given?
>>
>>
>>
>> Specifically, I could use clarification on:
>>
>>
>>
>>   (2) What is meant by this? does it say more than simply "use RDF"? Is
>> it advising that data publishers avoid blank nodes without labels?
>>
>>   (3) What is the issue of URI vs. blank node? What does it mean to have
>> no position? The explanation of this item seems to misunderstand blank
>> nodes.
>>
>>   (5) Does this mean to say "inverse property", rather than reciprocal?
>> When might a such a property be appropriate or inappropriate?
>>
>>
>>
>> I have smaller concerns about:
>>
>>
>>
>>   (1) Can a reason for this decision be given? Is the goal to leave the
>> door open for OWL-DL?
>>
>>   (4) This one has a good explanation, but some loose use of language;
>> (e.g.  "Some advantages of representing type as class rather than
>> property"). Additionally, is "type" intended to mean something more
>> specific than class membership?
>>
>>   (7) Are there examples? I think I understand this to be avoiding
>> properties like :isPartOfWork, :isPartOfInstance, etc..., but I'm mostly
>> guessing.
>>
>>   (8) (As discussed in this thread).
>>
>>
>>
>> - Tom
>>
>>
>>
>> [0]  <https://www.w3.org/TR/xmlschema-2/#integer>
>> https://www.w3.org/TR/xmlschema-2/#integer
>>
>> [1] https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Jun 20, 2016 at 11:45 AM, Denenberg, Ray <[log in to unmask]> wrote:
>>
>> Values of rdf:value in BIBFRAME do have a datatype:  rdfs:literal.  That
>> means that unless declared otherwise, it is a string by default. Whenever
>> you want, you can refine a literal
>>
>> e.g.
>>
>> (1) rdf: value  “10”
>>
>> (2) rdf:value  “10”^^xs:int
>>
>>
>>
>> The first is a string; the second is an integer.  But there is nowhere in
>> BIBFRAME that you would refine a value of rdf:value.
>>
>>
>>
>>
>>
>> Consider for example a bf:Identifier. BIBFRAME prescribes that you assert
>> the value of the identifier by rdf:value:
>>
>>
>>
>>        bf:identifiedBy    [  a                             bf:Isbn
>>
>>                                       rdf:value
>> “9783110413014”   ] .
>>
>>
>>
>> “9783110413014”  is a string.  You could refine it and assert that it’s
>> an integer:
>>
>>
>>
>>                          rdf:value “9783110413014”^^xs:int
>>
>>
>>
>> But you don’t want to do that because it isn’t an integer, it’s just a
>> string.    And wherever rdf:value is prescribed in BIBFRAME, it is just a
>> string.
>>
>>
>>
>> Someday you may be able to assert that it has datatype “isbn”….
>>
>>
>>
>>                          rdf:value “9783110413014”^^xyz:isbn
>>
>>
>>
>> … and that may facilitate processing of the isbn string.  But there is no
>> such primitive datatype yet. However the statement “a bf:Isbn” would seem
>> to serve that purpose.
>>
>>
>>
>> My point being that wherever rdf:value occurs, though there may not be an
>> explicit primitive datatype, the actual datatype is understood by context.
>>
>>
>>
>>
>>
>> There are datatype properties in BIBFRAME where is makes sense to refine
>> the datatype.  Take bf:count or bf:date for example
>>
>> Someone might declare:
>>
>>           bf:count   “10”
>>
>> and someone else declare:
>>
>>       bf:count   “10”^^xs:int
>>
>>
>>
>> Or
>>
>>             bf:date “June 20, 2016”
>>
>> vs:      bf:date “20160620”^^xdt:date
>>
>>
>>
>> And in both cases the second form is going to be more easily processed.
>>
>>
>>
>> But neither of these is supplied via rdf:value; they are datatype
>> properties, for which rdf:value doesn’t apply.
>>
>>
>>
>> Ray
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:* Bibliographic Framework Transition Initiative Forum [mailto:
>> <[log in to unmask]>[log in to unmask]] *On Behalf Of *Joseph
>> Kiegel
>> *Sent:* Monday, June 20, 2016 1:18 PM
>>
>>
>> *To:* <[log in to unmask]>[log in to unmask]
>> *Subject:* Re: [BIBFRAME] FW: [BIBFRAME] rdf:value
>>
>>
>>
>> I agree.
>>
>>
>>
>> It seems that the object of rdf:value should have a datatype.  A good
>> basis for a list of datatypes is the table in RDF Semantics (
>> <http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#DTYPEINTERP>
>> http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#DTYPEINTERP).  These
>> types are widely understood.  Of course, local types can be established but
>> they make widespread sharing of data more difficult.
>>
>>
>>
>> Looked at from this point of view, only one case from the examples of
>> rdf:value in the BIBFRAME specifications fits an xsd datatype:  ISBNs are
>> integers.  The rest do not conform to a standard datatype.
>>
>>
>>
>>
>>
>> *From:* Bibliographic Framework Transition Initiative Forum [
>> <[log in to unmask]>mailto:[log in to unmask]
>> <[log in to unmask]>] *On Behalf Of *Fallgren, Nancy (NIH/NLM) [E]
>> *Sent:* Monday, June 20, 2016 9:24 AM
>> *To:* <[log in to unmask]>[log in to unmask]
>> *Subject:* Re: [BIBFRAME] FW: [BIBFRAME] rdf:value
>>
>>
>>
>> At NLM, we’ve been asking the same question as Joe in re use of rdf:value
>> v. rdfs:label in the BF 2.0 Item examples.  The use of rdf:value with a
>> text string or with common terminology for which there should probably be a
>> URI doesn’t make sense to us either.
>>
>>
>>
>> It’s pretty clear that W3C defines rdf:value as a ‘structured’ value
>> while rdfs:label is for a human readable label.   But the W3C definition of
>> rdf:value as an idiom with no meaning on its own, seems to indicate that it
>> needs to be used within some context.  The W3C example in the Primer
>> <https://www.w3.org/TR/2004/REC-rdf-primer-20040210/#rdfvalue>
>> https://www.w3.org/TR/2004/REC-rdf-primer-20040210/#rdfvalue implies
>> that it should have a datatype (which makes sense for a machine to
>> understand a structured value) as well as another property giving context
>> about the structured value.  So, if LC shelf mark has a structured/standard
>> datatype that can be interpreted by machines as an LC Shelf mark, then use
>> of rdf:value could make sense in that context; otherwise, it seems
>> rdfs:label would be preferable.
>>
>>
>>
>> Also, best practices for sharing LD should probably not entail local
>> interpretation of properties from another vocabulary.
>>
>>
>>
>> -Nancy
>>
>>
>>
>> Nancy J. Fallgren
>>
>> Metadata Specialist Librarian
>>
>> Cataloging and Metadata Management Section
>>
>> Technical Services Division
>>
>> National Library of Medicine
>>
>> <[log in to unmask]>[log in to unmask]
>>
>>
>>
>>
>>
>>
>>
>> *From:* Hubay Miklós [ <[log in to unmask]>mailto:[log in to unmask] <[log in to unmask]>]
>> *Sent:* Monday, June 20, 2016 11:46 AM
>> *To:* <[log in to unmask]>[log in to unmask]
>> *Subject:* Re: [BIBFRAME] FW: [BIBFRAME] rdf:value
>>
>>
>>
>> Imho, the two properties are different. One is for value-declaration, and
>> the other one is "may be used to *provide a human-readable version of a
>> resource's name*."
>>
>> <https://www.w3.org/TR/rdf-schema/>https://www.w3.org/TR/rdf-schema/
>>
>> 2016.06.20. 17:34 keltezéssel, Joseph Kiegel írta:
>>
>> Sorry, I meant rdfs:label.
>>
>>
>>
>> *From:* Joseph Kiegel
>> *Sent:* Monday, June 20, 2016 8:34 AM
>> *To:* 'Bibliographic Framework Transition Initiative Forum'
>> <[log in to unmask]> <[log in to unmask]>
>> <[log in to unmask]> <[log in to unmask]>
>> *Subject:* RE: [BIBFRAME] rdf:value
>>
>>
>>
>> So is rdfs:value.  The question is:  what is the “appropriate” difference
>> between the two?
>>
>>
>>
>>
>>
>> *From:* Bibliographic Framework Transition Initiative Forum [
>> <[log in to unmask]>mailto:[log in to unmask]
>> <[log in to unmask]>] *On Behalf Of *Robert Sanderson
>> *Sent:* Monday, June 20, 2016 8:26 AM
>> *To:* <[log in to unmask]>[log in to unmask]
>> *Subject:* Re: [BIBFRAME] rdf:value
>>
>>
>>
>> It's the value of the resource to which it's attached.
>>
>>
>>
>> On Mon, Jun 20, 2016 at 5:18 PM, Joseph Kiegel < <[log in to unmask]>
>> [log in to unmask]> wrote:
>>
>>
>>
>> bf:identifiedBy [ a bf:Isbn
>>
>> rdf:value “9783110413014” ] .
>>
>> *Example 2*
>>
>> bf:identifiedBy [ a identifier:ABC ;
>>
>> rdf:value “MX3-387” ] .
>>
>> *Example 3*
>>
>> bf:identifiedBy [ a bf:Identifier ;
>>
>> bf:source “xyz” ;
>>
>> rdf:value “1234567890” ] .
>>
>>
>>
>> There is an ISBN, and its value is 9783...
>>
>> There is an ABC identifier, and its value is MX3-387
>>
>> There is an untyped identifier from source system xyz, and it's value is
>> 123...
>>
>>
>>
>>
>>
>>
>>
>> *Notes*
>>
>> *Example 3*
>>
>> bf:baseMaterial [
>>
>> bf:code [ rdf:value “o” ;
>>
>> bf:source [rdf:value “marc007ng04” ] ] ;
>>
>> bf:note [ a bf:Note ;
>>
>> rdfs:label “Image printed on thick gold paper.” ] ] .
>>
>>
>>
>> There is an untyped resource, which one imagines is a Code, with value
>> "o".
>>
>> There is an untyped resource, which is some sort of Source, with value
>> "marc007..."
>>
>>
>>
>>
>>
>>
>>
>> *Item*
>>
>> *Example (truncated)*
>>
>> <http://bibframe.example.org/item/itemZ>
>>
>> bf:shelfMarkLcc [rdf:value “LB2395.C65 1991” ] ;
>>
>> bf:usageAndAccessPolicy [
>>
>> a bf:AccessPolicy ;
>>
>> rdf:value “unrestricted” ] .
>>
>>
>>
>> There is an LCC, and its value is LB...
>>
>> There is a Policy and its value is "unrestricted"
>>
>> Note -- this use is not very machine friendly. A better model would have
>> identifiable policies, with their own URIs.
>>
>>
>>
>> HTH,
>>
>>
>>
>> Rob
>>
>>
>>
>> --
>>
>> Rob Sanderson
>>
>> Semantic Architect
>>
>> The Getty Trust
>>
>> Los Angeles, CA 90049
>>
>>
>>
>> --
>>
>> Hubay Miklós
>>
>> tájékoztató könyvtáros, könyvtárirendszer-adminisztrátor, MTMT-adminisztrátor
>>
>> Széchenyi István Egyetem Egyetemi Könyvtár
>>
>> 9026 Győr, Egyetem tér 1.
>>
>> Tel.: 96/613-443
>>
>> email: [log in to unmask]
>>
>>
>>
>
>
> --
> Karen [log in to unmask] http://kcoyle.net
> m: +1-510-435-8234
> skype: kcoylenet/+1-510-984-3600
>
>
> --
> Karen [log in to unmask] http://kcoyle.net
> m: +1-510-435-8234
> skype: kcoylenet/+1-510-984-3600
>
>